Date: Fri, 2 Mar 2012 12:16:47 -0500 From: David Schultz <das@FreeBSD.ORG> To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= <des@des.no> Cc: arch@FreeBSD.ORG, Garrett Wollman <wollman@hergotha.csail.mit.edu> Subject: Re: bsd/citrus iconv Message-ID: <20120302171647.GA29850@zim.MIT.EDU> In-Reply-To: <86d3958cqi.fsf@ds4.des.no> References: <4F3C2D2D.5000402@FreeBSD.org> <4F3E78BA.4060203@FreeBSD.org> <864nupcuvl.fsf@ds4.des.no> <4F3E7B5A.20103@FreeBSD.org> <86zkchbff6.fsf@ds4.des.no> <4F3EADB5.7060008@FreeBSD.org> <20120223170918.GA79013@zim.MIT.EDU> <201202231822.q1NIMQOd020804@hergotha.csail.mit.edu> <201202231926.q1NJQPFa021654@hergotha.csail.mit.edu> <86d3958cqi.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 23, 2012, Dag-Erling Sm?rgrav wrote: > Garrett Wollman <wollman@hergotha.csail.mit.edu> writes: > > You missed the bit on the next page: > > > > It is unspecified whether the libraries libc.a, libm.a, > > librt.a, libpthread.a, libl.a, liby.a, or libxnet exist as > > regular files. The implementation may accept as -l operands > > names of objects that do not exist as regular files. > > That's entirely academic unless you want to modify gcc and clang to > automatically pull in libiconv. The point is that if the iconv > extension is implemented, it must be available without requiring > additional -l options. If the linker included libiconv automatically, would it be possible to switch iconv implementations without recompiling, by using libmap.conf? Or is the ABI (e.g., type of iconv_t) incompatible? If the ABI is different, then we might as well stick iconv in libc using weak symbols. > It all boils down to this: do we aspire to SUS conformance? I think it actually boils down to what the practical benefit is. Does it create a compatibility nightmare for apps to have to use the -liconv flag? Do other platforms require it? IIRC, we've been patching ports to include the flag for years.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120302171647.GA29850>