Re: [Xen-devel] [PATCH 3 of 5] blktap2: fix vhd compilation under uclibc

[Roger Pau Monnà <roger.pau@xxxxxxxxxxxxx>]

2011/12/21 Ian Campbell <Ian.Campbell@xxxxxxxxxx>:
> On Tue, 2011-12-20 at 17:55 +0000, Roger Pau Monnà wrote:
>> Hello,
>>
>> I've added -liconv to blktap2/vhd/lib, and succesfully compiled and
>> linked the library. The output from ldd libvhd.so shows:
>>
>> checking sub-depends for '/lib/libuuid.so.1'
>> checking sub-depends for '/usr/lib/libiconv.so.2'
>> checking sub-depends for '/lib/libc.so.0.9.32'
>> checking sub-depends for '/lib/ld64-uClibc.so.0.9.32'
>> Â Â Â libuuid.so.1 => /lib/libuuid.so.1 (0x00000000)
>> Â Â Â libiconv.so.2 => /usr/lib/libiconv.so.2 (0x00000000)
>> Â Â Â libc.so.0.9.32 => /lib/libc.so.0.9.32 (0x00000000)
>> Â Â Â ld64-uClibc.so.0.9.32 => /lib/ld64-uClibc.so.0.9.32 (0x00000000)
>> Â Â Â not a dynamic executable
>>
>> Then I've compiled and linked vhd tools (vhd-util and vhd-update)
>> without -liconv, since vhd tools doesn't use any iconv functions. They
>> compile fine, but when I try to execute them I get the following
>> error:
>>
>> vhd-util: symbol 'libiconv_open': can't resolve symbol
>>
>> If I do a ldd of vhd-util:
>>
>> Â Â Â libvhd.so.1.0 => /usr/lib/libvhd.so.1.0 (0x7699efaf4000)
>> Â Â Â libc.so.0.9.32 => /lib/libc.so.0.9.32 (0x7699ef88c000)
>> Â Â Â libuuid.so.1 => /lib/libuuid.so.1 (0x7699ef689000)
>> Â Â Â ld64-uClibc.so.0.9.32 => /lib/ld64-uClibc.so.0.9.32 (0x7699efd10000)
>>
>> How come libiconv is not linked to the application if libvhd is?
>
> Can you post the complete link line for each stage?
>
> Are you sure that /usr/lib/libvhd.so.1.0 is the same one you just built
> and linked against? Is there a chance you have linked against something
> in the build directory which did not get properly installed?

Sorry, I'm just stupid, today I've realized what the problem was. It
was linked against and old /usr/lib/libvhd.so which was not compiled
with -liconv.

> Running
> Â Â Â Âobjdump -p <object> | egrep NEEDED\|SONAME
> for the library (both build dir and installed copies) and binary would
> be interesting.
>
> It seems like either this is a bug in uClibc's dynamic linker or my
> expectation of how these sorts of transitive library dependencies work
> has been set too high by glibc...
>
>> ÂAnd
>> what's most strange, why is the link to libuuid keep, but not the one
>> to libiconv?
>
> Yes, that is strange.

I still don't get the libuuid thing, but it works just fine now.

> Ian.
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel