On Mon, 2013-12-16 at 10:02 +0100, Filippo Arcidiacono wrote: > This is very strange. The libstdc++.so doesn't have any RPATH set. > Morover the libgcc_s.so > should be found in the standard search path, then the dynamic linker > doesn't need any info > to find it. Could you build the shared library loader with debugging > support (SUPPORT_LD_DEBUG=y) > to see where the dynamic linker search the libraries.
libgcc_s.so isn't in the standard system location. I am building a cross toolchain in a directory like /path/crosstools and installing GCC (including libgcc_s.so and libstdc++) under that path. The cross root filesystem (based on either glibc or uclibc) are then in /path/crosstools/sysroot. When I build GCC and glibc (and uclibc) I use the --sysroot=/path/crosstools/sysroot option on the configure. With that setup a glibc dynamic linker finds all my shared libraries and the uclibc dynamic linker doesn't. I think the glibc dynamic linker is using the sysroot setting to find the dynamic libraries in their locations under /path/crosstools/sysroot. > Some time ago I raised a similar issue, see > "Use executable's RPATH in looking up library searching path." thread in > http://lists.uclibc.org/pipermail/uclibc/2011-September/thread.html I put the dynamic linker patch from this thread in my sources and things seemed to work with that change. I think this is because when we use the executables paths for searching those paths include the sysroot prefix. When we were just looking in the 'standard locations' we didn't take sysroot into account and so we didn't find any libraries. It doesn't look to me like uclibc does anything special when configured/built with the --sysroot configure option. Is that correct? Steve Ellcey [email protected] _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
