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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
