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