Hi, uClibc-ng 1.0.13 doesn't seem to have atexit function:
[root@unknown root]$ cat hello.c #include <stdio.h> #include <stdlib.h> void blah(void) { printf("Hello world 2\n"); } int main(int argc, char* argv[]) { printf("Hello world\n"); atexit(blah); exit(0); } [root@unknown root]$ gcc hello.c -o hello /tmp/ccO5Ibuw.o: In function `main': hello.c:(.text+0x9c): undefined reference to `atexit' hello.c:(.text+0xa4): undefined reference to `atexit' collect2: error: ld returned 1 exit status
If, as a dirty hack, I compile it with '-Datexit=__cxa_atexit', it works:
[root@unknown root]$ gcc hello.c -o hello -Datexit=__cxa_atexit [root@unknown root]$ ./hello Hello world Hello world 2
Here're my ATEXIT config lines:
UCLIBC_DYNAMIC_ATEXIT=y COMPAT_ATEXIT=y
See full config attached. Is there something I'm missing, or this is a bug? Thanks, Alex
Hi Alex, Alex Potapenko wrote,
Hi,
uClibc-ng 1.0.13 doesn't seem to have atexit function:
Hmm. Are you compiling natively on a ARM uclibc-ng system? gcc -v gcc -v hello.c -o hello
[root@unknown root]$ gcc hello.c -o hello /tmp/ccO5Ibuw.o: In function `main': hello.c:(.text+0x9c): undefined reference to `atexit' hello.c:(.text+0xa4): undefined reference to `atexit' collect2: error: ld returned 1 exit status
Is there something I'm missing, or this is a bug?
When I cross-compile your test program for ARM and then run it on qemu-system-arm, everything is fine. So what do you do exactly? best regards Waldemar
Hi Waldemar, Ср, 18 трав. 2016 о 21:45 Waldemar Brodkorb <wbx@uclibc-ng.org> пише:
Hmm. Are you compiling natively on a ARM uclibc-ng system? gcc -v gcc -v hello.c -o hello
Yes, I'm compiling natively. Optware-ng provides gcc for native compilation. /opt/bin/gcc is a wrapper around /opt/bin/gcc.real -- the actual compiler: root@unknown:/tmp/home/root# cat /opt/bin/gcc
#!/bin/sh /opt/bin/gcc.real -Wl,--dynamic-linker=/opt/lib/ld-uClibc.so.1 -pipe "$@" -I/opt/include -L/opt/lib -Wl,-rpath,/opt/lib -Wl,-rpath-link,/opt/lib root@unknown:/tmp/home/root# gcc.real -v Using built-in specs. COLLECT_GCC=gcc.real
COLLECT_LTO_WRAPPER=/opt/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/5.3.0/lto-wrapper Target: arm-buildroot-linux-uclibcgnueabi Configured with: ../gcc-5.3.0/configure --build=x86_64-pc-linux-gnu --host=arm-buildroot-linux-uclibcgnueabi --target=arm-buildroot-linux-uclibcgnueabi --prefix=/opt --disable-nls --disable-static --with-as=/home/jenkins/Optware-ng/buildroot-armeabi-ng/toolchain/buildroot-arm-linux-2.6.36-uclibc-ng-5.3.0/bin/arm-buildroot-linux-uclibcgnueabi-as --with-ld=/home/jenkins/Optware-ng/buildroot-armeabi-ng/toolchain/buildroot-arm-linux-2.6.36-uclibc-ng-5.3.0/bin/arm-buildroot-linux-uclibcgnueabi-ld --enable-languages=c,c++ --disable-multilib --with-gxx-include-dir=/opt/include/c++/5.3.0 --disable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-libsanitizer --enable-tls --disable-libmudflap --enable-threads --without-isl --without-cloog --with-float=soft --disable-decimal-float --with-abi=aapcs-linux --with-cpu=cortex-a9 --with-mode=arm --enable-shared --disable-libgomp --with-gmp=/home/jenkins/Optware-ng/buildroot-armeabi-ng/staging/opt --with-mpfr=/home/jenkins/Optware-ng/buildroot-armeabi-ng/staging/opt --with-mpc=/home/jenkins/Optware-ng/buildroot-armeabi-ng/staging/opt --with-default-libstdcxx-abi=gcc4-compatible --with-system-zlib Thread model: posix gcc version 5.3.0 (GCC) root@unknown:/tmp/home/root# gcc -v hello.c -o hello Using built-in specs. COLLECT_GCC=/opt/bin/gcc.real
COLLECT_LTO_WRAPPER=/opt/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/5.3.0/lto-wrapper Target: arm-buildroot-linux-uclibcgnueabi Configured with: ../gcc-5.3.0/configure --build=x86_64-pc-linux-gnu --host=arm-buildroot-linux-uclibcgnueabi --target=arm-buildroot-linux-uclibcgnueabi --prefix=/opt --disable-nls --disable-static --with-as=/home/jenkins/Optware-ng/buildroot-armeabi-ng/toolchain/buildroot-arm-linux-2.6.36-uclibc-ng-5.3.0/bin/arm-buildroot-linux-uclibcgnueabi-as --with-ld=/home/jenkins/Optware-ng/buildroot-armeabi-ng/toolchain/buildroot-arm-linux-2.6.36-uclibc-ng-5.3.0/bin/arm-buildroot-linux-uclibcgnueabi-ld --enable-languages=c,c++ --disable-multilib --with-gxx-include-dir=/opt/include/c++/5.3.0 --disable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-libsanitizer --enable-tls --disable-libmudflap --enable-threads --without-isl --without-cloog --with-float=soft --disable-decimal-float --with-abi=aapcs-linux --with-cpu=cortex-a9 --with-mode=arm --enable-shared --disable-libgomp --with-gmp=/home/jenkins/Optware-ng/buildroot-armeabi-ng/staging/opt --with-mpfr=/home/jenkins/Optware-ng/buildroot-armeabi-ng/staging/opt --with-mpc=/home/jenkins/Optware-ng/buildroot-armeabi-ng/staging/opt --with-default-libstdcxx-abi=gcc4-compatible --with-system-zlib Thread model: posix gcc version 5.3.0 (GCC) COLLECT_GCC_OPTIONS='-pipe' '-v' '-o' 'hello' '-I' '/opt/include' '-L/opt/lib' '-mcpu=cortex-a9' '-mfloat-abi=soft' '-mabi=aapcs-linux' '-marm' '-mtls-dialect=gnu' /opt/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/5.3.0/cc1 -quiet -v -I /opt/include -imultilib . -imultiarch arm-linux-gnueabi hello.c -quiet -dumpbase hello.c -mcpu=cortex-a9 -mfloat-abi=soft -mabi=aapcs-linux -marm -mtls-dialect=gnu -auxbase hello -version -o - | /opt/lib/gcc/arm-buildroot-linux-uclibcgnueabi/5.3.0/../../../../arm-buildroot-linux-uclibcgnueabi/bin/as -v -I /opt/include -mcpu=cortex-a9 -mfloat-abi=soft -meabi=5 -o /tmp/ccS2W9jB.o GNU assembler version 2.25.1 (arm-buildroot-linux-uclibcgnueabi) using BFD version (GNU Binutils) 2.25.1 GNU C11 (GCC) version 5.3.0 (arm-buildroot-linux-uclibcgnueabi) compiled by GNU C version 5.3.0, GMP version 6.0.0, MPFR version 3.1.3, MPC version 1.0.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory "/usr/local/include/arm-linux-gnueabi" ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/opt/lib/gcc/arm-buildroot-linux-uclibcgnueabi/5.3.0/../../../../arm-buildroot-linux-uclibcgnueabi/include" ignoring nonexistent directory "/usr/include/arm-linux-gnueabi" ignoring nonexistent directory "/usr/include" ignoring duplicate directory "/opt/include" as it is a non-system directory that duplicates a system directory #include "..." search starts here: #include <...> search starts here: /opt/lib/gcc/arm-buildroot-linux-uclibcgnueabi/5.3.0/include /opt/include /opt/lib/gcc/arm-buildroot-linux-uclibcgnueabi/5.3.0/include-fixed End of search list. GNU C11 (GCC) version 5.3.0 (arm-buildroot-linux-uclibcgnueabi) compiled by GNU C version 5.3.0, GMP version 6.0.0, MPFR version 3.1.3, MPC version 1.0.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: c08c84285b122b419bc5a2ddcee6c301
COMPILER_PATH=/opt/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/5.3.0/:/opt/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/5.3.0/:/opt/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/:/opt/lib/gcc/arm-buildroot-linux-uclibcgnueabi/5.3.0/:/opt/lib/gcc/arm-buildroot-linux-uclibcgnueabi/:/opt/lib/gcc/arm-buildroot-linux-uclibcgnueabi/5.3.0/../../../../arm-buildroot-linux-uclibcgnueabi/bin/
LIBRARY_PATH=/opt/lib/gcc/arm-buildroot-linux-uclibcgnueabi/5.3.0/:/opt/lib/gcc/arm-buildroot-linux-uclibcgnueabi/5.3.0/../../../../arm-buildroot-linux-uclibcgnueabi/lib/:/opt/lib/gcc/arm-buildroot-linux-uclibcgnueabi/5.3.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-pipe' '-v' '-o' 'hello' '-I' '/opt/include' '-L/opt/lib' '-mcpu=cortex-a9' '-mfloat-abi=soft' '-mabi=aapcs-linux' '-marm' '-mtls-dialect=gnu' /opt/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/5.3.0/collect2 -plugin /opt/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/5.3.0/liblto_plugin.so -plugin-opt=/opt/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/5.3.0/lto-wrapper -plugin-opt=-fresolution=/tmp/ccKYWI8O.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --eh-frame-hdr -dynamic-linker /lib/ld-uClibc.so.0 -X -m armelf_linux_eabi -o hello /opt/lib/gcc/arm-buildroot-linux-uclibcgnueabi/5.3.0/../../../../arm-buildroot-linux-uclibcgnueabi/lib/crt1.o /opt/lib/gcc/arm-buildroot-linux-uclibcgnueabi/5.3.0/../../../../arm-buildroot-linux-uclibcgnueabi/lib/crti.o /opt/lib/gcc/arm-buildroot-linux-uclibcgnueabi/5.3.0/crtbegin.o -L/opt/lib -L/opt/lib/gcc/arm-buildroot-linux-uclibcgnueabi/5.3.0 -L/opt/lib/gcc/arm-buildroot-linux-uclibcgnueabi/5.3.0/../../../../arm-buildroot-linux-uclibcgnueabi/lib -L/opt/lib/gcc/arm-buildroot-linux-uclibcgnueabi/5.3.0/../../.. --dynamic-linker=/opt/lib/ld-uClibc.so.1 /tmp/ccS2W9jB.o -rpath /opt/lib -rpath-link /opt/lib -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /opt/lib/gcc/arm-buildroot-linux-uclibcgnueabi/5.3.0/crtend.o /opt/lib/gcc/arm-buildroot-linux-uclibcgnueabi/5.3.0/../../../../arm-buildroot-linux-uclibcgnueabi/lib/crtn.o /tmp/ccS2W9jB.o: In function `main': hello.c:(.text+0x44): undefined reference to `atexit' collect2: error: ld returned 1 exit status
When I cross-compile your test program for ARM and then run it on qemu-system-arm, everything is fine.
I confirm, it works when cross-compiled! Is there something wrong with my native gcc? The libs and the headers are the same. Here's cross gcc config, it looks to be compatible with the native one: jenkins@u0:/tmp$
/home/jenkins/Optware-ng/buildroot-armeabi-ng/toolchain/buildroot-arm-linux-2.6.36-uclibc-ng-5.3.0/bin/arm-buildroot-linux-uclibcgnueabi-gcc -v Using built-in specs.
COLLECT_GCC=/home/jenkins/Optware-ng/buildroot-armeabi-ng/toolchain/buildroot-arm-linux-2.6.36-uclibc-ng-5.3.0/bin/arm-buildroot-linux-uclibcgnueabi-gcc.br_real
COLLECT_LTO_WRAPPER=/home/jenkins/Optware-ng/buildroot-armeabi-ng/toolchain/buildroot-arm-linux-2.6.36-uclibc-ng-5.3.0/bin/../libexec/gcc/arm-buildroot-linux-uclibcgnueabi/5.3.0/lto-wrapper Target: arm-buildroot-linux-uclibcgnueabi Configured with: ./configure --prefix=/home/jenkins/Optware-ng/buildroot-armeabi-ng/toolchain/buildroot-2016.02/output/host/usr --sysconfdir=/home/jenkins/Optware-ng/buildroot-armeabi-ng/toolchain/buildroot-2016.02/output/host/etc --enable-static --target=arm-buildroot-linux-uclibcgnueabi --with-sysroot=/home/jenkins/Optware-ng/buildroot-armeabi-ng/toolchain/buildroot-arm-linux-2.6.36-uclibc-ng-5.3.0/arm-buildroot-linux-uclibcgnueabi/sysroot --disable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib --with-gmp=/home/jenkins/Optware-ng/buildroot-armeabi-ng/toolchain/buildroot-2016.02/output/host/usr --with-mpfr=/home/jenkins/Optware-ng/buildroot-armeabi-ng/toolchain/buildroot-2016.02/output/host/usr --with-pkgversion='Buildroot 2016.02-g5068547' --with-bugurl= http://bugs.buildroot.net/ --disable-libsanitizer --enable-tls --disable-libmudflap --enable-threads --with-mpc=/home/jenkins/Optware-ng/buildroot-armeabi-ng/toolchain/buildroot-2016.02/output/host/usr --without-isl --without-cloog --with-float=soft --disable-decimal-float --with-abi=aapcs-linux --with-cpu=cortex-a9 --with-float=soft --with-mode=arm --enable-languages=c,c++ --with-build-time-tools=/home/jenkins/Optware-ng/buildroot-armeabi-ng/toolchain/buildroot-2016.02/output/host/usr/arm-buildroot-linux-uclibcgnueabi/bin --enable-shared --disable-libgomp --with-default-libstdcxx-abi=gcc4-compatible Thread model: posix gcc version 5.3.0 (Buildroot 2016.02-g5068547)
Any ideas what may be wrong here (though this probably isn't a uClibc-ng issue)? Thanks!
On 5/18/2016 1:29 PM, Alex Potapenko wrote:
Yes, I'm compiling natively. Optware-ng provides gcc for native compilation. /opt/bin/gcc is a wrapper around /opt/bin/gcc.real -- the actual compiler:
I believe this is an issue with binutils rather than with uclibc-ng itself. To fix this, binutils needs to be compiled with "--sysroot=/opt" (not there) . Using --prefix is not enough in this case, binutils needs to know the location of the shared files it should be linking against. /opt is a non-standard location after all for a system root. Without sysroot, it attempts to reference the libraries provided by your device's firmware in /lib, which it definitely should not be doing. uclibc provided by the router probably doesn't have atexit, and thus the error. Some things may still compile, and they *will* use the libraries in /opt, since the wrapper script (feels dirty to me) provides the dynamic linker and rpath arguments, but you'll be limited to symbols that the router's libraries have. I came upon similar issues in my project Tomatoware. And now to shamelessly promote you my project Tomatoware. (despite it's name, it also runs on dd-wrt and rmerlin as well as tomato) Entware-ng/Optware-ng are firstly and primarily package repos, with gcc and a handful of dev tools thrown in as an afterthought. Tomatoware on the other hand is designed with the sole purpose of providing a development environment on mipsel/arm routers. It also allows static linking which I find absolutely essential for binary re-share-ability. Entware-ng/Optware-ng only allow dynamic linking, so your binary is tethered to Entware-ng/Optware-ng being installed. Tomatoware deploys to /mmc, so you can still use Entware-ng/Optware-ng for installing packages. http://www.linksysinfo.org/index.php?threads/tomatoware.69742/ Cheers, Lance
Hi Lance, Thank you for your reply! I agree that native compilation lies beyond the main purpose of Optware-ng. However, sometimes Optware-ng users would want to go off compiling packages themselves, using the pre-compiled Optware-ng libraries -- that's when Optware-ng dev tools may come handy. This feature is poorly tested, and I don't actually use it myself, but gcc seems to work, more or less. I also agree that the wrapper script feels dirty, and if you know of a better way to avoid having to add all those flags manually each time, please let me know. On Wed, May 18, 2016 at 11:59 PM, Lance Fredrickson <lancethepants@gmail.com> wrote:
I believe this is an issue with binutils rather than with uclibc-ng itself. To fix this, binutils needs to be compiled with "--sysroot=/opt" (not there) . Using --prefix is not enough in this case, binutils needs to know the location of the shared files it should be linking against. /opt is a non-standard location after all for a system root. Without sysroot, it attempts to reference the libraries provided by your device's firmware in /lib, which it definitely should not be doing. uclibc provided by the router probably doesn't have atexit, and thus the error. Some things may still compile, and they *will* use the libraries in /opt, since the wrapper script (feels dirty to me) provides the dynamic linker and rpath arguments, but you'll be limited to symbols that the router's libraries have. I came upon similar issues in my project Tomatoware.
Unfortunately, this doesn't seem to be the case. First of all, binutils 2.25.1 I'm using doesn't accept '--sysroot' switch:
jenkins@u0:~/Optware-ng/buildroot-armeabihf/builds/binutils-2.25.1$ ./configure --help|grep sysroot --with-build-sysroot=SYSROOT use sysroot as the system root during the build
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
so, even if I add -L/lib flag before -L/opt/lib, firmware uClibc libs will never be used during linking.
And now to shamelessly promote you my project Tomatoware. (despite it's name, it also runs on dd-wrt and rmerlin as well as tomato)
Entware-ng/Optware-ng are firstly and primarily package repos, with gcc and a handful of dev tools thrown in as an afterthought. Tomatoware on the other hand is designed with the sole purpose of providing a development environment on mipsel/arm routers. It also allows static linking which I find absolutely essential for binary re-share-ability. Entware-ng/Optware-ng only allow dynamic linking, so your binary is tethered to Entware-ng/Optware-ng being installed. Tomatoware deploys to /mmc, so you can still use Entware-ng/Optware-ng for installing packages.
http://www.linksysinfo.org/index.php?threads/tomatoware.69742/
I totally agree that Optware-ng isn't fit for serious native development. Apart from what you mentioned already, you may also discover that after a certain library upgrade your compiled binary stops working due to ABI changes. However, in case you want to compile a binary with numerous dependencies, that are available pre-compiled in Optware-ng feeds, you can save yourself a *lot* of time, especially on mipsel routers. Not to mention that Optware-ng has other archs, not supported by Tomwatoware. That all being said, I still see no reason or fix for the atexit issue, so any suggestions are welcomed. Thank you, Alex
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
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.
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
participants (3)
-
Alex Potapenko -
Lance Fredrickson -
Waldemar Brodkorb