Libguestfs - Jun 2012 - [hivex] OS X, Fedora 17: iconv autotool inconsistency

Hello all,

I've been testing hivexml in OS X, and came across an inconsistency in
building.

Some while back, I hit a snag with iconv in OS X, where basically this
would happen when a hive of any sophistication (greater than
hivex/images/small) was processed:
>$ xml/hivexml images/large >test.xml
>dyld: lazy symbol binding failed: Symbol not found: _iconv_open
>  Referenced from: /[snip]/hivex/lib/.libs/libhivex.0.dylib
>  Expected in: flat namespace
>
>dyld: Symbol not found: _iconv_open
>  Referenced from: /[snip]/hivex/lib/.libs/libhivex.0.dylib
>  Expected in: flat namespace
>
>Trace/BPT trap
This is pretty easily resolved in OS X by adding $(LTLIBICONV) to
libhivex_la_LDFLAGS in lib/Makefile.am.

Unfortunately, bringing that same change to Fedora (17) raises this error
in `make`:
>/bin/ld: cannot find -liconv
>collect2: error: ld returned 1 exit status
LIBICONV and LTLIBICONV are both set to '-liconv' in config.log; but
there
is no check for how to link in config.log. That is, these lines do not
appear (in part or in whole) in Fedora's config.log:
>checking for iconv... yes
>checking for working iconv... yes
>checking how to link with libiconv... -liconv
The Fedora negative results came from the latest master, 1.3.6.  The OS X
tests were on an effectively an older version of the code [1], but I think
this is an autotools issue in common to both version.

So...any ideas?  I thought this linking error was the kind of thing the
autotools were supposed to catch.

--Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://listman.redhat.com/archives/libguestfs/attachments/20120625/18fa3d8a/attachment.htm>

On Mon, Jun 25, 2012 at 07:42:56PM -0400, Alexander Nelson
wrote:
> Hello all,
> 
> I've been testing hivexml in OS X, and came across an inconsistency in
> building.
> 
> Some while back, I hit a snag with iconv in OS X, where basically this
> would happen when a hive of any sophistication (greater than
> hivex/images/small) was processed:
> 
> >$ xml/hivexml images/large >test.xml
> >dyld: lazy symbol binding failed: Symbol not found: _iconv_open
> >  Referenced from: /[snip]/hivex/lib/.libs/libhivex.0.dylib
> >  Expected in: flat namespace
> >
> >dyld: Symbol not found: _iconv_open
> >  Referenced from: /[snip]/hivex/lib/.libs/libhivex.0.dylib
> >  Expected in: flat namespace
> >
> >Trace/BPT trap
> 
> This is pretty easily resolved in OS X by adding $(LTLIBICONV) to
> libhivex_la_LDFLAGS in lib/Makefile.am.
> 
> Unfortunately, bringing that same change to Fedora (17) raises this error
> in `make`:
> >/bin/ld: cannot find -liconv
> >collect2: error: ld returned 1 exit status
> 
> LIBICONV and LTLIBICONV are both set to '-liconv' in config.log;
but there
> is no check for how to link in config.log. That is, these lines do not
> appear (in part or in whole) in Fedora's config.log:
> 
> >checking for iconv... yes
> >checking for working iconv... yes
> >checking how to link with libiconv... -liconv
> 
> The Fedora negative results came from the latest master, 1.3.6.  The OS X
> tests were on an effectively an older version of the code [1], but I think
> this is an autotools issue in common to both version.
> 
> So...any ideas?  I thought this linking error was the kind of thing the
> autotools were supposed to catch.
I've no idea.  I only know that iconv functions are included directly
in glibc.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top