libstdc++.so/la
Tyrrr opened this issue · 8 comments
How does nox link against libstdc++.so and how does it find it? Because currently it tries to link against the /usr/lib version and gets an error. It should link against the /usr/lib64 version. As a temporary fix I made a symbolic link from /usr/lib/libstdc++.so to /usr/lib64/libstdc++.so.6 but that's no permament solution.
I think gcc chooses it. What does the following command tell you?
g++ -print-file-name=libstdc++.so
/usr/bin/../lib64/gcc/powerpc64-unknown-linux-gnu/4.5.3/../../../../lib64/libstdc++.so, which looks rather weird but is correct.
The terminal output of make:
/bin/sh ../../libtool --tag=CXX --mode=link g++ -fno-omit-frame-pointer -fno-strict-aliasing -Wall -Wno-sign-compare -Winit-self -Wformat-nonliteral -Wformat-security -g -O2 -std=gnu++0x -R/usr/local/bin/lib -export-dynamic -L/usr/lib -L/usr/lib -rdynamic -version-info 1:0:0 -o libnoxcore.la -rpath /usr/local/lib command-line.lo connection.lo errno_exception.lo fault.lo network_iarchive.lo network_oarchive.lo sigset.lo string.lo timeval.lo vlog.lo dhparams.lo -lboost_filesystem -lboost_system -lboost_serialization -lboost_thread -lssl -lcrypto
libtool: link: g++ -fPIC -DPIC -shared -nostdlib /usr/bin/../lib64/gcc/powerpc64-unknown-linux-gnu/4.5.3/../../../../lib64/crti.o /usr/bin/../lib64/gcc/powerpc64-unknown-linux-gnu/4.5.3/crtbeginS.o .libs/command-line.o .libs/connection.o .libs/errno_exception.o .libs/fault.o .libs/network_iarchive.o .libs/network_oarchive.o .libs/sigset.o .libs/string.o .libs/timeval.o .libs/vlog.o .libs/dhparams.o -Wl,-rpath -Wl,/usr/lib64/../lib -Wl,-rpath -Wl,/usr/lib64/../lib -Wl,-rpath -Wl,/usr/local/bin/lib -L/usr/lib -lboost_filesystem -lboost_system -lboost_serialization -lboost_thread -lssl -lcrypto -L/usr/bin/../lib64/gcc/powerpc64-unknown-linux-gnu/4.5.3 -L/usr/bin/../lib64/gcc -L/usr/bin/../lib64/gcc/powerpc64-unknown-linux-gnu/4.5.3/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/bin/../lib64/gcc/powerpc64-unknown-linux-gnu/4.5.3/../../../../powerpc64-unknown-linux-gnu/lib -L/usr/bin/../lib64/gcc/powerpc64-unknown-linux-gnu/4.5.3/../../.. /usr/lib64/../lib/libstdc++.so -lm -lc -lgcc_s /usr/bin/../lib64/gcc/powerpc64-unknown-linux-gnu/4.5.3/crtendS.o /usr/bin/../lib64/gcc/powerpc64-unknown-linux-gnu/4.5.3/../../../../lib64/crtn.o -O2 -Wl,-soname -Wl,libnoxcore.so.1 -o .libs/libnoxcore.so.1.0.0
/usr/lib64/../lib/libstdc++.so: could not read symbols: File in wrong format
-L/usr/bin/../lib64/gcc/powerpc64-unknown-linux-gnu/4.5.3/../../../../lib64 is in this whole mess but rather at the end. I think the problem is that -L/usr/lib gets added first and gcc finds the wrong libstdc++ there.
By looking at the Makefile /usr/lib gets added by BOOST_LDFLAGS in AM_LDFLAGS = -R$(pkglibdir) $(am__append_4) $(BOOST_LDFLAGS)
Indeed, if I change that to AM_LDFLAGS = -R$(pkglibdir) $(am__append_4) -L/usr/lib64 $(BOOST_LDFLAGS) libnoxcore.so compiles just fine, but I'd have to change it for the other components as well.
AM_LDFLAGS gets added to nox_core_LDFLAGS in
nox_core_LDFLAGS = \ $(AM__LDFLAGS) -dlopen force
and nox_core_LDFLAGS gets added to nox_core_LINK in
nox_core_LINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) \ $(LIBTOOLFLAGS) --mode=link $(CXXLD) $(AM_CXXFLAGS) \ $(CXXFLAGS) $(nox_core_LDFLAGS) $(LDFLAGS) -o $@
LDFLAGS seems to be empty but it is added after nox_core_LDFLAGS either way. I don't really understand when the other libdirs get added but I guess libtool handles that.
So any idea how this could be fixed?
P.S. how do I disable automatic substitution of smileys in Github?
Awesome! Could you send me both your config.log and the output of "gcc --print-search-dirs"?
config.log: http://pastebin.com/mT8iKNUQ
gcc --print-search-dirs
install: /usr/bin/../lib64/gcc/powerpc64-unknown-linux-gnu/4.5.3/
programs: =/usr/bin/../libexec/gcc/powerpc64-unknown-linux-gnu/4.5.3/:/usr/bin/../libexec/gcc/:/usr/bin/../lib64/gcc/powerpc64-unknown-linux-gnu/4.5.3/../../../../powerpc64-unknown-linux-gnu/bin/powerpc64-unknown-linux-gnu/4.5.3/:/usr/bin/../lib64/gcc/powerpc64-unknown-linux-gnu/4.5.3/../../../../powerpc64-unknown-linux-gnu/bin/
libraries: =/usr/bin/../lib64/gcc/powerpc64-unknown-linux-gnu/4.5.3/:/usr/bin/../lib64/gcc/:/usr/bin/../lib64/gcc/powerpc64-unknown-linux-gnu/4.5.3/../../../../powerpc64-unknown-linux-gnu/lib/powerpc64-unknown-linux-gnu/4.5.3/:/usr/bin/../lib64/gcc/powerpc64-unknown-linux-gnu/4.5.3/../../../../powerpc64-unknown-linux-gnu/lib/../lib64/:/usr/bin/../lib64/gcc/powerpc64-unknown-linux-gnu/4.5.3/../../../powerpc64-unknown-linux-gnu/4.5.3/:/usr/bin/../lib64/gcc/powerpc64-unknown-linux-gnu/4.5.3/../../../../lib64/:/lib/powerpc64-unknown-linux-gnu/4.5.3/:/lib/../lib64/:/usr/lib/powerpc64-unknown-linux-gnu/4.5.3/:/usr/lib/../lib64/:/usr/bin/../lib64/gcc/powerpc64-unknown-linux-gnu/4.5.3/../../../../powerpc64-unknown-linux-gnu/lib/:/usr/bin/../lib64/gcc/powerpc64-unknown-linux-gnu/4.5.3/../../../:/lib/:/usr/lib/
Seems that both OpenSSL and Boost m4 scripts set "-L/usr/lib". Could you edit src/Make.vars and replace "AM_LDFLAGS = -R$(pkglibdir)" with "AM_LDFLAGS = -L/usr/lib64 -R$(pkglibdir)"? Then rerun boot.sh, configure, and make.
Are the boost and openssl libraries installed in /usr/lib?
Yes, both boost and openssl are installed in /usr/lib.
Adding -L/usr/lib64 to AM_LDFLAGS works.
I'm not sure if it's related to this or if it's a different issue. Starting nox_core with the switch module works, but when a switch connects, nox_core crashes:
/home/hartmann/nox/build/src/.libs/lt-nox_core: symbol lookup error: coreapps/switch/.libs/switch.so.1: undefined symbol: _ZN3tbb8internal23allocate_via_handler_v3Em
So I thought maybe I did something wrong compiling tbb but looking at the library, it seems that the function is included.
nm /usr/lib/libtbb.so.2 | grep -E 'internal23alloc'
0000000000056d10 d _ZN3tbb8internal23allocate_via_handler_v3Em
Could it have something to do with the change of AM_LDFLAGS? How can this(practically a linker error) even happen at runtime?
I looked at the library on another machine and that should be T and not d (local static variable). So never mind, something went really wrong at compilation of my tbb library.