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.
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 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.
When I make a use of Qwebview in my application. and then build it I get an error of
:: error: collect2: ld returned 1 exit status
:: error: [debug\Browseweb.exe] Error 1
so it does not run I have seached Quit But didn't got the solution So what should I do to solve this error. if You have a Solution kindly help me.
That error is coming from the linker ld and, based on error: [debug\Browseweb.exe] Error 1, my first thought is that it's a problem creating the executable file.
If that error 1 matches what's in errno.h, then it's an EPERM error which is related to permissions. You should check whether the debug directory exists and, if it does, check to make sure you can create files in there.
However, given that you seem to be on a Windows platform (due to the backslash path separator and an exe extension), I'm not sure that's the actual case.
One other thing that may be causing the problem is if your executable is running when you try to rebuild it.
I've seen this problem before under Windows since the OS locks the executable while it's running.