I'm building an application that results in the following error:
hidden symbol `__popcountdi2' in /usr/lib/gcc/x86_64-redhat-linux/4.8.3/libgcc.a(_popcountsi2.o) is referenced by DSO
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
This can be fixed with '-shared-libgcc' linked option, but I would like to understand the issue and what is causing it. Also it appears that others don't observe the issue, although we all run the same Linux distribution (Fedora 20), the same tools and libraries (gcc-4.8.3-7.fc20.x86_64, libgcc-4.8.3-7.fc20.x86_64 and binutils-2.23.88.0.1-13.fc20.x86_64), so I suspect there's something wrong with my platform, may be some libs are missing etc.
I would appreciate if someone could give hints to understand what is going on. Thanks.
Related
I have recently started using the OpenCascade defeaturing operation and found issues compiling with gcc and link time optimization. When including "#include <BRepAlgoAPI_Defeaturing.hxx>" and using flag "-flto" I get the error:
`_ZThn80_N23BRepAlgoAPI_DefeaturingD1Ev' referenced in section `.rdata$_ZTV23BRepAlgoAPI_Defeaturing[_ZTV23BRepAlgoAPI_Defeaturing]'
of /opt/opencascade/lib/libTKBO.a(BRepAlgoAPI_Defeaturing.cxx.o):
defined in discarded section `.gnu.linkonce.t._ZN23BRepAlgoAPI_DefeaturingD1Ev[_ZThn80_N23BRepAlgoAPI_DefeaturingD1Ev]'
of obj/occt_ops.o (symbol from plugin)
collect2: error: ld returned 1 exit status
make: *** [Makefile:147: occt-test] Error 1
If I understand correctly the defeaturing symbol has been discarded, and is therefore not found. No other changes have been made and it compiles without the -flto flag, so I wonder how can I assure that the symbol will not be discarded? Or what could potentially be in the defeaturing code that causes this, as this issue has never come up before?
I've built my code on a machine with gcc 6.3 before. I'm building the same code on another machine with gcc 5.3. I tried using the working oed library from a different location. But still the error persists. I went through suggestions in other questions similar to this on Stackoverflow, but they suggest that the library must be already linked. This is not the case though.
Oed is a fortran library and the code is in C and C++.
I'm at a loss to think how to figure out this problem. Any help is welcome.
/usr/bin/ld: oed__gener_nai_batch.o: access beyond end of merged section (380)
/usr/bin/ld: oed__gener_nai_batch.o: access beyond end of merged section (586)
/usr/bin/ld: oed__gener_nai_batch.o: access beyond end of merged section (580)
/usr/bin/ld: /home/umunipala/gamess/gamess-kris-simgms/simgms/oed/liboed.a(oed__gener_nai_batch.o)(.debug_info+0x203): reloc against `.debug_str': error 2
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
Well, there are two solutions I think.
recompile the .c file with your current library settings.
export a corresponded version LD library.
The problem is basically caused by the disagreement between .o file and your gcc(compiler).
I came across this error when I tried to compile a project that used xerces-c library(binaries). Since this is a binary it does not come with ./configure and hence I skipped doing the same(./configure). I am providing the xerces-c files as include and library to my xml reading program as anyone would normally do. The only error left is as below...
--Error output ---
Building target: MyXmlProject.exe
Invoking: Cygwin C++ Linker
g++ -L"C:\cppLib\xerces-c-3.1.1-x86_64-linux-gcc-3.4\lib" -o "MyXmlProject.exe" ./xmldom/XmlDomDocument.o ./xmldom/main.o -lxerces-c
collect2: error: ld terminated with signal 11 [Segmentation fault], core dumped
/usr/lib/gcc/x86_64-pc-cygwin/4.9.3/../../../../x86_64-pc-cygwin/bin/ld: BFD (GNU Binutils) 2.25 assertion fail /cygdrive/i/szsz/tmpp/cygwin64/binutils/binutils-2.25-1.x86_64/src/binutils-gdb/bfd/cofflink.c:264
makefile:48: recipe for target 'MyXmlProject.exe' failed
make: *** [MyXmlProject.exe] Error 1
I had downloaded the binaries from http://archive.apache.org/dist/xerces/c/3/binaries/ I have tried with a. xerces-c-3.1.1-x86_64-linux-gcc-3.4 and b. xerces-c-3.1.1-x86-linux-gcc-3.4 both the files but both result in same error.
Seems that the above two binaries are compiled for different platform and do not work on windows. The environment I am using is eclipse, cygwin64 on windows8.1. Can someone tell me which binary should I take so that the error is resolved?
The other options are tedious and wanted to avoid those. People who wants to know how I came across this error and other options please refer to How to resolve "relocation truncated to fit: R_X86_64_PC32 against undefined symbol `xercesc_3_1::AbstractDOMParser::adoptDocument()'"
I'm trying to build a native client application using SDL, and a link error had me stumped. This is the simplest command line that reproduces the error. Has anyone seen this before?
\# nacl_sdk/pepper_25/toolchain/linux_x86_glibc/bin/i686-nacl-gcc -m64 nacl_glue.cc -lSDL -lppapi_cpp
/home/rob/nacl_sdk/pepper_25/toolchain/linux_x86_glibc/bin/../lib/gcc/x86_64-nacl/4.4.3/../../../../x86_64-nacl/bin/ld: /home/rob/nacl_sdk/pepper_25/toolchain/linux_x86_glibc/bin/../x86_64-nacl/lib/libstdc++.so.6: invalid DSO for symbol `std::_List_node_base::hook(std::_List_node_base*)##GLIBCXX_3.4' definition
/home/rob/nacl_sdk/pepper_25/toolchain/linux_x86_glibc/bin/../x86_64-nacl/lib/libstdc++.so.6: could not read symbols: Bad value
collect2: ld returned 1 exit status
I need to use i686-nacl-g++ instead of i686-nacl-gcc.
Digging around a little online, it looks like GCC shouldn't link in the c++ standard library, but my error message looks a little more like it IS linking in the c++ standard library, but is not understanding the symbols it is finding. Weird, but whatever.
My previous code was compiling fine but a recent upgrade messed up something and when I run make I get the following error on a simple example.
make
/usr/bin/ld: final link failed: Numerical result out of range
collect2: ld returned 1 exit status
make: *** [SimpleExample] Error 1
The example code basically does nothing, it just prints "hello".
Anyone aware of this issue?? Thank you.
I have encountered this issue a few times. Every single time it had something to do with the build happening on an NTFS or network filesystem. Moving the build directory to a proper Unix FS (e.g. ext3/4) fixed the issue.
We cannot help you more, unless you provide additional information, such as your platform, programming language and perhaps some sample code that reproduces this issue on your system.