On Thu, May 19, 2016 at 5:50 PM, Lance Fredrickson lancethepants@gmail.com wrote:
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...
Ah, so it's '--with-sysroot' -- not '--sysroot', as you wrote originally. I tried the latter before writing my previous post, and configure failed with something like 'unrecognized configure option'. I added '--with-sysroot' flag, but, unfortunately, this doesn't seem to help:
Package binutils (2.25.1-3) installed in /opt/ is up to date. root@unknown:/tmp/home/root# gcc hello.c -o hello /tmp/ccZBrHBi.o: In function `main': hello.c:(.text+0x44): undefined reference to `atexit' collect2: error: ld returned 1 exit status root@unknown:/tmp/home/root# gcc hello.c -o hello /tmp/cckerRfx.o: In function `main': hello.c:(.text+0x44): undefined reference to `atexit' collect2: error: ld returned 1 exit status
(https://github.com/Optware/Optware-ng/commit/ee14f85dc6f49a010264e4228cc4615...)
Manually adding '--sysroot=' flag to gcc doesn't work either:
root@unknown:/tmp/home/root# gcc hello.c -o hello --sysroot=/opt /tmp/ccXcwIg7.o: In function `main': hello.c:(.text+0x44): undefined reference to `atexit' collect2: error: ld returned 1 exit status
On Thu, May 19, 2016 at 5:50 PM, Lance Fredrickson lancethepants@gmail.com wrote:
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.
I knew that, more or less, but I though that "all the libraries" were 'lib*.so' files.
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.
Sure, that's right, I never said it was supposed to be uclibc.so :-)
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.
I'm indeed interested in your patch: I think I'll borrow it, thanks.
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.
I'm still not 100% sure this isn't somehow relevant to uClibc-ng: not a bug maybe, but something wrong in the way I configure build tools against it, perhaps. glibc Optware-ng targets don't suffer from this issue.
On Thu, May 19, 2016 at 7:13 PM, Lance Fredrickson lancethepants@gmail.com wrote:
I also see that gcc is compiled with flag --disable-__cxa_atexit. I'm unfamiliar with atexit, but I don't include that flag in my gcc compilation.
This is irrelevant: it disables the use of __cxa_atexit() function in C++ static destructors. Buildroot has this option for some reason, I merely copied it.
Thanks, Alex