19 May
2016
19 May
'16
2:50 p.m.
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-pas…
http://www.linuxfromscratch.org/lfs/view/development/chapter05/binutils-pas…
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