I am trying to link some RISC-V code and I am getting the following error.
ld.lld-13: error: undefined hidden symbol: __math_oflowf
>>> referenced by sf_expm1.c
>>> lib_a-sf_expm1.o:(expm1f) in archive /home/fabian/fp/tools/rv32gcv/riscv32-unknown-elf/lib/libm.a
>>> did you mean: __math_oflow
>>> defined in: /home/fabian/fp/tools/rv32gcv/riscv32-unknown-elf/lib/libm.a
I am using a GCC rv32gcv toolchain with --gcc-toolchain and --sysroot for the lib/inc. Does anybody have any idea what might be going on here? I can`t find anything online sadly. Thanks in advance!
I had the same issue. I found out that it was due to a bug in an older version of the newlib library which the toolchain depends on. If you update the GCC toolchain to the latest release, it should be fixed.
Related
I am able to build my code successfully but getting following error while trying to run it. I am on AIX7.1 using GCC4.8.5.
0509-130 Symbol resolution failed for libadobelinguistic.a because:
0509-136 Symbol _ZNSt5__padIcSt11char_traitsIcEE6_S_padERSt8ios_basecPcPKcllb (number 94) is not exported from
dependent module /user/unicore/rs6000aix/compiler/gcc4.8.5/aix6.1/lib/libstdc++.a(libstdc++.so.6).
0509-022 Cannot load module .
0509-026 System error: Cannot run a file that does not have a valid format.
0509-192 Examine .loader section symbols with the
'dump -Tv' command."}
As suggested at few places I used -Wl,--no-undefined flag to fail the project at compilation time. but compilation is not failing.
demangled function:
std::__pad<char, std::char_traits<char> >::_S_pad(std::ios_base&, char, char*, char const*, long, long, bool)
I am unable to find reference to this function.
Moreover as suggested at few places In case of such errors you need to set LIBPATH variable in case of AIX. I have libpath variable set to
LIBPATH=/user/unicore/rs6000aix/compiler/gcc4.8.5/aix6.1/lib:/opt/freeware/lib:/user/unicore/rs6000aix/compiler/gcc4.8.5/aix6.1/lib/gcc/powerpc-ibm-aix6.1.0.0/4.8.5:/opt/freeware/lib/pthread/ppc64
still it is not working.
I found a reference to it https://sourceforge.net/p/slo/feature-requests/4/. but it is not helpful.
Edit: seems like libstdc++ is causing issue on the AIX7.1. we have system libstdc++ and libstdc++ of gcc4.8.5. when I link to system libstdc++ gdb runs successfully but my program fails but when i set path to libstdc++ in gcc4.8.5. GDB doesn't run but my executable runs. seems like system libstdc++ and gcc4.8.5 libstdc++ are not compatible.
Issue was with libstdc++. By default LIBPATH was set to opt/freeware/lib where libstdc++ was available. While compiling my source was getting linked to libstdc++ available at the 'opt/freeware/lib' location. where as at run time it was looking for 'libstdc++' available in the gcc4.8.5. causing the issue.
setting LIBPATH to gcc lib directory solved the issue.
I am building an application which makes use of a third party library which requires libstdc++.so.5. Until recently I was compiling my application with libstdc++.so.6 which worked fine, however it had some portability issues.
Therefore I decided installing g++ version 3.3.4 in order to be capable of compiling my application with libstdc++.so.5. However now I cannot compile my application at all. Neither with my old g++ nor with the 3.3.4 Version of it... Building the application reports the following error message:
/opt/ExPansion/lib/libexpansion.so: undefined reference to `std::basic_istream<char, std::char_traits<char> >::basic_istream(std::basic_streambuf<char, std::char_traits<char> >*)#GLIBCPP_3.2'
EDIT:
Interesting might also be the output of the following commands:
$ strings /usr/lib/libstdc++.so.5 | grep 'LIB'
GLIBCPP_3.2
GLIBCPP_3.2.1
GLIBCPP_3.2.2
GLIBCPP_3.2.3
GLIBCPP_3.2.4
GLIBC_2.0
GLIBC_2.3
GLIBC_2.1.3
GLIBC_2.1
GLIBC_2.2
GLIBCPP_FORCE_NEW
The only thing that makes me wonder is the following:
$ nm /usr/lib/libstdc++.so.5
nm: /usr/lib/libstdc++.so.5: no symbols
Is that "normal"? Is it possible that my lib is not containing the needed symbols? I downloaded this lib through:
yum install compat-libstdc++-33
..so it shouldn't be causing any problems..
From my understanding #GLIBCPP_3.2 is provided by my libstdc++.so.5. So what could be going wrong here?
I have no idea what causes my linker not finding the lib on its own...
The following question helped me however find a "workaround" to my problem: how to force linker to use shared library instead of static library?
Simply forcing my linker to link against the library helped..
gcc -o app app.o {other libs} /usr/lib/libstdc++.so.5
My problem is rather specific, but bear with me.
This in the end is kinda reverse engineering, but this problem in particular seems to fit more this board.
So, I have a shared object compiled for MIPS written in C++. I don't have the source code of the lib. The lib is compiled using GCC 4.3.3. I want to use functions present in this shared object in my amd64 computer running elementary OS. To do this, I used the sourcery cross compiler to cross compile some C++ code to MIPS, that would use this object.
So far I managed this except for this one compile error, which I cannot figure out. The lib is called libdvl.so, and uses as dependency libc.so.0 (and both are in the same folder as the cpp code).
mips-linux-gnu-g++ -g -L/path/to/lib -Wl,-rpath,/path/to/lib -o verifier verifier.cpp -ldvl
which gives me
(...)/mgc/embedded/codebench/bin/../lib/gcc/mips-linux-gnu/4.9.1/../../../../mips-linux-gnu/bin/ld: warning: libc.so.0, needed by /path/to/lib/libdvl.so, may conflict with libc.so.6
(...)/mgc/embedded/codebench/bin/../lib/gcc/mips-linux-gnu/4.9.1/../../../../mips-linux-gnu/bin/ld: errno##GLIBC_PRIVATE: TLS definition in (...)/mgc/embedded/codebench/bin/../mips-linux-gnu/libc/lib/libc.so.6 section .tbss mismatches non-TLS definition in /path/to/lib/libc.so.0 section .bss
/path/to/lib/libc.so.0: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
So I added "-l:libc.so.0" and got this
(...)/mgc/embedded/codebench/bin/../lib/gcc/mips-linux-gnu/4.9.1/../../../../mips-linux-gnu/bin/ld: errno: TLS definition in (...)/mgc/embedded/codebench/bin/../mips-linux-gnu/libc/lib/libc.so.6 section .tbss mismatches non-TLS definition in libc.so.0 section .bss
(...)/mgc/embedded/codebench/bin/../mips-linux-gnu/libc/lib/libc.so.6: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Any idea how to solve this? I know I am using GCC 4.9.1, but I already downloaded the older code sourcery version which uses GCC 4.3.154 and got the exact same error.
EDIT 1: Exactly as Lol4t0 said, filtered using c++filt it gives an actual function name from stdc++. Using
mips-linux-gnu-g++ -g -L/path/to/lib -Wl,-rpath,/path/to/lib -I/path/to/lib -o verifier verifier.cpp -ldvl -l:libuClibc++.so.0 -l:libutil.so.0 -l:libc.so.0 -l:ld-uClibc.so.0 -nodefaultlibs
to give to libdvl its depencies (as I will not rewrite stdc++ :p), I get the following compile error:
(...)/mgc/embedded/codebench/bin/../lib/gcc/mips-linux-gnu/4.9.1/../../../../mips-linux-gnu/bin/ld: /tmp/cc66DLda.o: undefined reference to symbol '_Unwind_Resume##GCC_3.0'
(...)/mgc/embedded/codebench/bin/../mips-linux-gnu/libc/lib/libgcc_s.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
I already confirmed lib dependencies and the order in which they appear.
Any thoughts on this?
Thanks for all the help.
Using -nodefaultlibs solves the first problem though.
You are linking against GLIBC (libc.so.6) and some other libc (libc.so.0).
That could never work: you have to have everything compiled and linked against a single, consistent libc.
Since your libdvl.so uses as dependency libc.so.0, and assuming you can't rebuild libdvl.so, you have to use crosscompiler that targets libc.so.0 (which is possibly dietlibc, or uClibc), and compile and link everything else using that toolchain. Your crosscompiler on the other hand appears to target GLIBC, and will not do you any good.
After a lot of trial and error, you may be able to link the final binary using inconsistent builds, and your binary may even get to main (that is very unlikely). But chances of such binary actually working correctly are minuscule.
Linking with gmock(1.4+svn281) libs generated on a Linux machine "A", having GCC 3.4.6 using libstdc++.so.6.0.13 gives me the following linking error:
libgmock.so: undefined reference to `std::basic_ostream >& std::__ostream_insert >(std::basic_ostream >&, char const*, long)#GLIBCXX_3.4.9'
...
I tried also with the latest gmock release version and also got the undefined reference to... #GLIBCXX_3.4.9 errors (this time with other symbols).
Building gmock using the same build procedure, however on another machine "B" (retired machine now, but previously used to generate the older binaries) I was able to link successfully. The machine uses GCC 3.4.6, with a different libstdc++ version: libstdc++.so.6.0.3.
Grepping on libstdc++.so.6.0.13 for GLIBCXX_3.4.9 shows that it contains such symbol patterns:
_ZNSt13basic_ostreamIwSt1##GLIBCXX_3.4.9 (referencing GLIBCXX_3.4.9, hence the error). I verified that this is not the case for libstdc++.so.6.0.3
To understand the linking error and what are my options, I read about libstdc++ and glibcxx to get some perspective, but couldn't conclude the relation between the libs: Does libstdc++ need glibcxx or is it the other way around (the error message makes it seem that the problem is: at glibcxx there is an undefined reference to a symbol in libstdc++)?
Does libstdc++ implicitly link with glibcxx (knowing that libstdc++ can reference multiple glibcxx versions at a time)?
I don't want to go back to the old machine to build gmock whenever I want to update the libs, am I constrained to building gmock with specific libstdc++ versions that work?
Appreciate any help on the issue
EDIT:
I built gmock libs on machine "A" and specified the version of libstdc++: libstdc++.so.6.0.3 and got the same errors as before, but this time without the #GLIBCXX_3.4.9 appended at the end of the symbol:
libgmock.so: undefined reference to `std::basic_ostream >& std::__ostream_insert >(std::basic_ostream >&, char const*, long)'
...
I also verified that libstdc++.so.6.0.3 was actually taken, by launching the command: "readelf -a libgmock.so" and verifying that GLIBCXX_3.4.9 was not referenced.
To understand the linking error and what are my options, I read about libstdc++ and glibcxx to get some perspective, but couldn't conclude the relation between the libs: Does libstdc++ need glibcxx
There is no such thing as glibcxx library. The libstdc++.so uses GNU symbol versioning, and uses GLIBCXX symbol prefix. The whole GLIBCXX is implementation detail of libstdc++ itself.
Your actual problem, and possible solutions, is explained here.
Effectively, you can not expect a binary linked on a newer Linux system to work on an older one.
Trying to use the RHEL5.3 GCC 4.3.2 compiler to build my software on that platform. I get the following error no matter what I try when compiling with -O2, but it builds fine without optimization. Any ideas?
/usr/bin/ld: myapp: hidden symbol `void std::__ostream_fill<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, long)' isn't defined
/usr/bin/ld: final link failed: Nonrepresentable section on output
In RHEL5.3, I am using /usr/bin/g++43 for compilation and linking. The correct libstdc++.so is found here:
/usr/lib/gcc/i386-redhat-linux6E/4.3.2/libstdc++.so
which is a text file containing INPUT ( -lstdc++_nonshared /usr/lib/libstdc++.so.6 ).
Wouldn't that mismatch the system stdlibc++ 4.1 version?
It turns out to be a GCC bug in RHEL 5.3 :-/. https://bugzilla.redhat.com/show_bug.cgi?id=493929. I sent an email to the maintainer, Jakub Jelinek, who said that RHEL 5.4 (which is due out soon) will have a fix and also will bump to GCC 4.4.
A workaround is to use -fno-inline, but this has some obvious drawbacks.
You seem to be running into visibility issues -- can we see your full command line?
For example, what -fvisibility-inlines-hidden does may change at different optimization levels because GCC decides to inline different things.
It only happens with optimization. Does that give a clue?