Re: libicu48 on armhf not working for me
On Tue, Dec 27, 2011, Anthony L. Awtrey wrote:
> I've got a little Trim-Slice running the current, unstable armhf dist.
> I'm trying to get some of my code running on it and am having problems
> with the "icu" packages. I discovered that certain programs that linked
> libicu48 were dying silently when I ran them. When I started poking
> around, I found that I got no results when using ldd on my executables.
> So I tried to run ldd on the provided icu executables and saw the same
> thing.
>
> For example, when I run ldd on *armel* /usr/bin/derp (included in
> libicu-dev):
>
> $ ldd /usr/bin/derb
> libicutu.so.48 => /usr/lib/libicutu.so.48 (0x402d6000)
> libicui18n.so.48 => /usr/lib/libicui18n.so.48 (0x4033b000)
> libicuuc.so.48 => /usr/lib/libicuuc.so.48 (0x4055b000)
> libicudata.so.48 => /usr/lib/libicudata.so.48 (0x4071d000)
> libdl.so.2 => /lib/arm-linux-gnueabi/libdl.so.2 (0x4007d000)
> libstdc++.so.6 => /usr/lib/arm-linux-gnueabi/libstdc++.so.6 (0x40117000)
> libm.so.6 => /lib/arm-linux-gnueabi/libm.so.6 (0x40207000)
> libgcc_s.so.1 => /lib/arm-linux-gnueabi/libgcc_s.so.1 (0x400cf000)
> libc.so.6 => /lib/arm-linux-gnueabi/libc.so.6 (0x41894000)
> /lib/ld-linux.so.3 (0x4004c000)
>
> When I run the exact same command on *armhf*, I get no output and a
> return status of 1. Running the derb command fails the same way as
> running my programs that link libicu48.
There is a series of patches for eglibc that were developed by
Steve McIntyre (and perhaps by others too) to help the runtime linking
code and ldconfig distinguish armel and armhf binaries. ldd and ld.so
will search the /etc/ld.so.cache first (which is generated by
ldconfig). I don't know how complete the patches are in Debian
unstable.
What you'd want to do is confirm that /usr/bin/derb is indeed a
hard-float binary (I don't know how to do this, this the heuristics
that Steve implemened in eglibc), check that it has the relevant NEEDED
entries for the SONAMEs of libicutu.so.48 and other libs, then check
that these libraries are indeed on the system, then check the contents
of ld.so.cache (ldconfig -p | grep libicutu), then check that the
binary references the right ld.so (readelf -a /usr/bin/derb | grep
ld-linux), it should be in the multiarch location and if not that it
should point to a symlink to it. If all of that fails, strace.
> I tried to rebuild the icu package on my armhf box and it fails during
> the dpkg-buildpackage:
>
> /bin/bash ../../mkinstalldirs uconvmsg
> mkdir uconvmsg
> LD_LIBRARY_PATH=../../lib:../../stubdata:../../tools/ctestfw:$LD_LIBRARY_PATH
> ../../bin/genrb -e UTF-8 -s resources -d uconvmsg root.txt
> make[3]: *** [uconvmsg/root.res] Error 1
That's a bit short and will require investigation.
Of course you should file a bug for this, in particular if it's the
only package misbehaving in this way.
--
Loïc Minier
Reply to: