19 May
2016
19 May
'16
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