bsd/citrus iconv

[David Schultz]

On Thu, Feb 23, 2012, Dag-Erling Sm?rgrav wrote:
> Garrett Wollman <wollman at 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.