[bug-gnu-libiconv] Re: libiconv help

[Bruno Haible]

Hello,

Bill Eccles writes:
> As the most knowledgeable libiconv person in the world, can you please  
> help me, a *nix newbie, with a question that has been plaguing the  
> MacOS X community for years now?
>
> If you Google the following, you'll see what we seem to be up against:
> 
>    Symbol not found _iconv_open
>
> It seems to happen with nmbd quite often for us, and others seem to  
> have the same problem in other programs as well.

You are not providing a specific recipe for reproducing the error.
So my answer can only be unspecific as well. Namely: Usually this
error is generated by using an <iconv.h> and a libiconv.dylib that
don't fit together. For example, the <iconv.h> from the system (in
/usr/include), combined with a libiconv.2.dylib that you have build
from the GNU libiconv distribution.

The autoconf macro AM_ICONV, part of gnulib and of gettext, and
documented at
  http://www.gnu.org/software/hello/manual/gettext/AM_005fICONV.html,
will avoid this kind of error.

> For me, the problem occurs with libiconv 1.12, which builds libiconv. 
> 2.4.0.dylib. Truly, "nm" on libiconv.2.4.0.dylib yields no symbol with  
> the name "_iconv_open."

Sure. At assembly level, this symbol is called '_libiconv_open'. You are
supposed to #include <iconv.h> before using the iconv_open() function.

> So I wandered back to libiconv 1.11 and built   
> it, yielding libiconv.2.2.0.dylib.

That must have been libiconv 1.9.2, because in 1.11 the resulting file
is also called libiconv.2.4.0.dylib, and in 1.10 it's called
libiconv.2.3.0.dylib.

> In both cases, I did the standard configure/make/install, with no  
> options specified. But here's where things get interesting. "nm" on  
> libiconv.2.2.0.dylib yields a short list of symbols in several  
> sections, which looks like this:
> 
> shr-g5:lib admin$ nm libiconv.2.2.0.dylib
> 
> libiconv.2.2.0.dylib(dylib1.o):
>           u __mh_dylib_header
> 92a15680 t dyld_stub_binding_helper
> 
> libiconv.2.2.0.dylib(iconv.o):

A file composed of multiple .o files? That does not look like a shared library,
but rather like a static library that happens to be named libiconv.2.2.0.dylib.
Forget about it, it's nonsense to install static libraries under such file names
(except on AIX).

> Doing the same on libiconv.2.4.0.dylib yields a monolithic list headed  
> by
> 
> libiconv.2.4.0.dylib(single module):
> 
> 
> and a long, long list of symbols, and _iconv_open nowhere to be found  
> among them.

_libiconv_open is among them, and this is what matters.

> Finally the question, then: What causes the difference in builds here?
> I.e., why are the dylibs so different in structure, and is there a way  
> to make 2.4.0 look like 2.2.0 in structure

You know better than me how you created this silly file libiconv.2.2.0.dylib.
When I install libiconv 1.9.2 on MacOS X 10.5, the file of this name that gets
created is a shared library.

> dyld: Library not loaded: /usr/lib/libiconv.2.dylib,   Referenced  
> from: /bin/sh,   Reason: Incompatible library version: sh requires  
> version 7.0.0 or later,  but libiconv.2.dylib provides version 5.0.0

Now this error is about /usr/lib/libiconv.2.dylib, which comes from Apple.
It's a modified version of GNU libiconv. Source is on the Apple site.
Bug reports should go to Apple.

Bruno