Don't ask why, but is there any way to suppress a failed linking error?
Such as:
undefined reference to BLANK
This is in GCC 3.4.6
No, because they are errors and not warnings. By definition this means that the function was referenced someplace but not defined... that's not something you can just ignore.
The only way of supressing the link errors would be not linking (or not having errors in the first place). As mentioned by SoapBox, errors cannot be silently ignored.
If you post some code you could get to a solution to the problem that is better than trying to close your eyes and wait for the problem to go away (they don't usually).
It's not the compiler, but the linker. The best way to "suppress" this would be to pass in the library name with the compile command:
gcc try.cc -lstdc++
or
g++ try.cc -lfltk
for instance.
Related
I'm trying to compile and link some C++ code using CLang, with the following command line:
clang.exe -nostdinc -MD -fno-use-cxa-atexit -fno-rtti -fno-exceptions -fsigned-char -fno-stack-protector -fPIC -m64 -Wall -Werror -Wno-unused-function -Wno-unused-label -Wno-ignored-attributes
(I left out the output, includes, defines, etc. These are fine)
The issue I'm having is that during linking, I get the error
error: L0039: reference to undefined symbol `atexit'
I've spent quite some time on this issue already, but can't for the life of me seem to figure out how to properly resolve this.
My research so far has shown that atexit is defined in stdlib.h, but I can not use the standard library in this situation (this isn't my decision either, and is completely mandatory for this particular project).
As far as I can tell this issue is only now arising due to the fact that we now suddenly have static objects in our code which is compiled this way, which leads the compiler trying to register con/destructors to be executed for these objects, which requires a call to __cxa_atexit (which we've disabled because it was also giving undefined reference errors because of the same reason) or atexit.
I've also tried defining an arbitrary atexit function in my code, but apparently the linker doesn't want to have anything to do with this (which does seem rather strange to me).
So the question I have is: How can I get the linker to not whine about atexit, while not having to include the standard library?
Thanks a bunch in advance!
For future visitors, user damvac was able to help out!
Here's my comment about the issue being resolved:
It seems I forgot to add extern "C" to the definition of atexit (I only added it to the declaration), this seems to have resolved the issue! Thanks everyone who replied, and thank you davmac for providing the solution!
atexit (and the whole concept of "exiting" in general) do not exist in a freestanding environment, so you can't call it in your code.
To get the compiler to not generate support code that calls it, you need to compile all your source files with -ffreestanding to specify that you are using/generating freestanding code.
After switching default compiler in qt to gcc 4.6.2 I'm getting following error:
c:\ndk_buildrepos\qt-desktop\src\winmain\qtmain_win.cpp:93: error: undefined reference to `_Unwind_Resume'
With the compiler switch I also did two more things - I overwrote mingw32make with make from gcc 4.6.2. I did the same for the clean step.
Is there a way to fix it?
_unwind_resume is part of the compiler runtime library - it deals with unwinding the stack when handling an exception.
This post http://www.linuxquestions.org/questions/linux-newbie-8/undefined-symbol-_unwind_resume-192813/ suggests linking with the library gcc_s ( -lgcc_s )
Here's a similar solution: http://www.pgroup.com/userforum/viewtopic.php?t=1636&sid=a1f1e9e649686d97a21ba367284ea3ce
Here's someone with the same problem using QT: http://www.qtcentre.org/threads/33394-Link-errors-undefined-reference-to-_Unwind_Resume-and-__gxx_personality_v0 . They say "Running C:\Qt\2010.04\bin\qtenv.bat fixes the problem."
I'm trying to build a simple unit test executable, using cpputest. I've built the cpputest framework into a static library, and am now trying to link that into an executable. However, I'm tied into a fairly complicated Makefile setup, because of the related code.
This is my command line:
/usr/bin/qcc -V4.2.4,gcc_ntoarmle_acpp-ne -lang-c++ -O2 -g -g -o Application/UnitTests/Tests/symbols/UnitTestExe -Wl,--start-group Application/UnitTests/Tests/../.objs/main.o Application/UnitTests/lib/libcpputest.a -Wl,--end-group -lm
I'm getting many errors like the following:
Application/UnitTests/lib/libcpputest.a(CommandLineTestRunner.o): In function `CommandLineTestRunner::parseArguments(TestPlugin*)':
Application/UnitTests/cpputest/src/CppUTest/.objs/../CommandLineTestRunner.cpp:114: undefined reference to `operator new(unsigned int, char const*, int)'
I can't figure out what's causing this. Don't I get operator new for free with C++?
You probably need to link with the C++ support runtime library. This happens automatically when you invoke g++. On Linux, this is achieved by adding the -lstdc++ flag to the linker. You have to figure out how to do the same on your platform.
Maybe you're calling gcc, the C compiler instead of g++, which is the C++ compiler.
There's very little information in your question to work from, but it looks like some code uses some form of placement new, and while that special operator new is declared (the compiler finds it and compiles the code using it), the linker can't find its definition.
(Since this old answer of mine seems to still get attention: See here for an extensive discussion on declaration vs. definition.)
You need to rebuild your code from scratch, including the library. I got this error because I inadvertently copied object files compiled on another machine (with the rest of the source) to my machine. Most likely this disturbs the linking step since there are now two types of object files, native (for modified source files) and non-native (all others). I am guessing here, but the operator 'new' means slightly different things on different architectures and that's why you are getting this error.
p.s. I know this is way too late for a useful answer but I'm still posting this for the record.
For QNX 6.5.0 I have specified flag -lang-c++ for qcc (gcc) to avoid the error.
Like the original post, in my case this error happened while trying to link a software using CppUTest framework.
In my case, the source of the problem seems to be related to the fact I disabled the MEMORY_LEAK_DETECTION compile option of CppUTest. I enabled it again, which solved the problem.
Sometimes adding -lstdc++ is not enough. You should add it to the right place. For example I had list like this, not working:
target_link_libraries(cfr2 pthread m stdc++ "${CMAKE_SOURCE_DIR}/compressor/libcompressor.a" )
But this one works fine:
target_link_libraries(cfr2 pthread m "${CMAKE_SOURCE_DIR}/compressor/libcompressor.a" stdc++)
It'd be great if someone explained it in the comment section.
I have a problem linking an application for an embedded target. I'm developing on a windows box using Min-GW for an ARM9 target that runs under Linux.
Actually I'm switching from static linking to dynamic linking with .so-libraries to save memory space.
I get the error message
libT3Printer.so: undefined reference to `__ASSERT'
I checked all the sources for the lib and I have no idea where this function could be called. Is there any possibility to find out, who (which source file or function) could be the caller of the missing function?
The reference is probably being hidden by a macro. If you run the compiler with the -E option to generate predecessor output you might have a better chance of tracking it down.
Try to add definition NDEBUG.
In C, compiling with NDEBUG defined:
gcc -DNDEBUG foo.c
disables all calls to assert(), and this behavior is identical in C++:
g++ -DNDEBUG foo.cpp
I'm getting these errors while linking, both messages have to do with the same object file.
CALL16 reloc at 0x5f8 not against global symbol
and
could not read symbols: Bad value
The 2nd message seems to be the reason I'm getting the CALL16 error, but the file compiles just fine.
Any tips on fixing this?
FYI, I'm cross compiling for a MIPS target and using gcc 4.1.2
EDIT: No luck so far:
Here are my flags used:
-fPIC,-Wl,-rpath,-Wl,-O1
I've also tried the following without success:
-mno-explicit-relocs
-mexplicit-relocs
-mlong-calls
-mno-long-calls
-mxgot
-mno-xgot
Meanwhile, I'll go back to the source at this point and investigate more.
Aha!
Thanks to a colleague of mine, we found the issue.
Here was the issue:
There was a forward declaration/prototype of a function.
void FooBarIsBest(void);
Later on in the file the function was defined.
static void FooBarIsBest(void)
{
// do the best
}
The issue here was that in the prototype the keyword static was left out. So it was like a whole new function was being defined.
The CALL16 reference is used by gcc for relocatable code. The assembly code of the file showed that CALL16 was being used on this function... Which is wrong, as this function is local.
Interestingly, this code used to compile & link just fine with an older version of gcc (3.2.2).
Another lessoned learned. :)
Try -mlong-calls flag to the compiler.
Also see the manual for more specific MIPS options.