On 5/19/2016 1:00 AM, Alex Potapenko wrote:
Unfortunately, this doesn't seem to be the case. First of all, binutils 2.25.1 I'm using doesn't accept '--sysroot' switch:
It doesn't list it as a configure option, but that's not the same as not accepting it. LFS for example makes use of it. http://www.linuxfromscratch.org/lfs/view/development/chapter05/binutils-pass... http://www.linuxfromscratch.org/lfs/view/development/chapter05/binutils-pass...
Second, the -L/opt/lib makes sure that libs in /opt/lib are used during linking. And, finally, there're simply no "*.so" uClibc symlinks in /lib on my firmware:
root@unknown:/tmp/home/root# ls /lib ld-uClibc.so.0 libcrypt.so.0 libgcc_s.so.1 libnsl.so.0 librt.so.0 modules libc.so.0 libdl.so.0 libm.so.0 libpthread.so.0 libutil.so.0 openvpn_plugin_auth_nvram.so
You're correct in that IF you get the application to compile, yes it will use the libraries in /opt, because the resulting binaries get hard-coded with the dynamic linker and rpath in the wrapper script. However, at final linking the linker does a role call of the needed symbols the application requires. It's at this moment that it takes a peak in all the libraries and see if they have the symbols that your header files claimed them to have. Without the sysroot option ld looks first at /lib... and might fail depending on the symbols (or lack thereof), or possibly as well because of abi changes since uclibc guarantees no stability. Of course you won't find uclibc.so in /lib, that's simply not posix standard. You're dynamic linker tells me your firmware is uclibc based, so libc.so.0 is the uclibc c-library.
I discovered this because none of my applications were compiling with threading support when running configure scripts. It would check and fail to find PTHREAD_CREATE, despite me knowing I had enabled threading in my toolchain. Know what doesn't have threading? The toolchain and libraries supplied by broadcom to router manufacturers. I use sysroot in binutils and voila, works. I also use a patch for gcc I borrowed from LFS that you might be interested in as well.
Plainly stated, if the application cross-compiles fine with the Optware-ng toolchain, but does not compile natively because of supposed missing symbols, then uclibc is not at fault. A simple test to carry out, and then we can stop spamming their mailing list.
Cheers, Lance