18 May
2016
18 May
'16
2:56 p.m.
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
18 May
18 May
6:45 p.m.
Hi Alex,
Alex Potapenko wrote,
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,
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?
7:29 p.m.
Hi Waldemar,
Ср, 18 трав. 2016 о 21:45 Waldemar Brodkorb <wbx(a)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!
8:59 p.m.
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
19 May
19 May
7 a.m.
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(a)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
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
4:13 p.m.
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.
4:59 p.m.
On Thu, May 19, 2016 at 5:50 PM, Lance Fredrickson
<lancethepants(a)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-pas…
http://www.linuxfromscratch.org/lfs/view/development/chapter05/binutils-pas…
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/ee14f85dc6f49a010264e4228cc461…)
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(a)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(a)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
3109
days inactive
3110
days old
7 comments
3 participants
participants (3)
-
Alex Potapenko -
Lance Fredrickson -
Waldemar Brodkorb