+++ This bug was initially created as a clone of Bug #207851 +++ The new way of setting up the local linker scripts doesn't work with --sysroot style cross-compilers: echo "GROUP ( /usr/$(get_libdir)/libcom_err.a )" > lib/libcom_err.a echo "GROUP ( /usr/$(get_libdir)/libcom_err.so )" > lib/libcom_err.so echo "GROUP ( /usr/$(get_libdir)/libss.a )" > lib/libss.a echo "GROUP ( /usr/$(get_libdir)/libss.so )" > lib/libss.so The problem here is that toolchain programs with --sysroot support will normally resolve linker script GROUP values to be relative to the value of sysroot. However, they only do this if the file containing the linker script is within the sysroot. Otherwise it uses an absolute path which ends up picking up system libraries when cross-compiling. I.e. this happens: CC prof_err.c LD e2fsck /usr/libexec/gcc/mips64el-gentoo-linux-gnu/ld: cannot find /usr/lib32/libcom_err.so collect2: ld returned 1 exit status
so what you're saying is that your sysroot does not have the com_err and ss libraries installed ? if that's the case, then install them into your sysroot
It DOES have them installed. The problem is that GROUP only gets resolved relative to the sysroot if the file containing the GROUP macro is also within the sysroot. So what's happening in my case is that it's trying to link against /usr/lib32/libcom_err.so instead of <sysroot>/usr/lib32/libcom_err.so
got ya ... the full paths arent actually needed, so try dropping the leading /usr/lib/ part
then again, that wont work as the linker will just keep searching the same path over and over in an infinite loop (finding the linker script) i'd say just put the libraries into your sysroot like normal
*** Bug 228525 has been marked as a duplicate of this bug. ***
