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.
Related
Context: I'm using Qt 5.9.3 on Windows, building for MinGW 32-bit. The Qt part is a side issue though - the problem seems to be with MinGW. The version of MinGW is 4.3.0, supplied prebuilt as part of the Qt installation.
I'm building a library which talks to a USB device over HID. Everything compiles fine, but it fails at the link stage with
./..\..\object\debug\usb_hid_device.o: In function `ZN8MyApp3USB5Win3213getDevicePathB5cxx11Ell':
<MYPATH>/../../source/win32/usb_hid_device.cpp:99: undefined reference to `HidD_GetAttributes(void*, _HIDD_ATTRIBUTES*)#8'
./..\..\object\debug\usb_hid_device.o: In function `ZN8MyApp3USB5Win3214CHIDDeviceImplC2EllRNS_15LogPerComponentE':
<MYPATH>/../../source/win32/usb_hid_device.cpp:200: undefined reference to `HidD_FlushQueue(void*)#4'
The linker command is
g++ -shared -mthreads -Wl,-subsystem,windows -Wl,--out-implib,<MYPATH>\bin\debug\libusb_hid_comms.a -o <MYPATH>\bin\debug\usb_hid_comms.dll object_script.usb_hid_comms.Debug -lhid -lsetupapi -LC:\Qt\Qt5.9.3\5.9.3\mingw53_32\lib C:\Qt\Qt5.9.3\5.9.3\mingw53_32\lib\libQt5Guid.a C:\Qt\Qt5.9.3\5.9.3\mingw53_32\lib\libQt5Cored.a
If I omit -lhid I get the same errors. I also get the same errors if I remove -lhid and explicitly set the path and filename to libhid.a. If I deliberately mistype the path and filename, it comes up with an error, so I know the command-line is getting parsed correctly. But for whatever reason, MinGW appears to not be linking with one of its own library files.
I've also tried removing -lsetupapi and I get the linker errors I'd expect for the functions defined in there. Likewise the Qt library files. But it seems that specifically for libhid.a, MinGW can see the library file but just isn't going to link with it.
Has anyone else seen this? Or can anyone else with the same (or similar) version of MinGW confirm or deny that they can link with libhid.a? Or is there something obviously wrong with what I'm doing?
I've just found the answer. I'm posting an answer myself so that other people know in future, because I think this is still a valid question which people might want to know about.
The problem is the include file hidsdi.h. The majority of other header files which pull in Win32 API calls have extern "C" around the function declarations. However this one doesn't! The result is that we end up with C++ name mangling for linker symbols, instead of the C-style "_" in front of the linker symbols.
The solution is to use
extern "C"
{
#include <hidsdi.h>
}
and then everything works fine.
The version of hidsdi.h with the older version of MinGW (which I'm porting from) did have that protection around the function declarations. However it looks like it's gone in the newer version.
I'm trying to build headless blackcoin from source on Windows 8 with mingw 6.3
and I got the following error: .../src/leveldb/libleveldb.a(env_win.o):env_win.cc:(.text+0xaff): undefined reference to '_imp__PathFileExistsW#4'
This function is mentioned here https://msdn.microsoft.com/en-us/library/windows/desktop/bb773584(v=vs.85).aspx
I would appreciate if someone can help me.
P.S. I linked the appropriate library.
Finally I was able to build it. Probably it is obvious for thoose guys who down voted the question. I simply answer since it might save time to somebody.
I relied on the Makefile which is a part of the project source code. Required library (shlwapi) present in the file so I was confused when it failed to build. Everything went well when I placed the library at the end of the linked files.
It was something like this
g++ ... -o -lshlwapi... /src/leveldb/libleveldb.a /src/leveldb/libmemenv.a
And became this
g++ ... -o /src/leveldb/libleveldb.a /src/leveldb/libmemenv.a -lshlwapi
I was trying to compile exprtk.hpp file (https://exprtk.codeplex.com/) with mingw32(491_32) on Qt (win7).
During compilation, I give this error message:
debug\main.o:-1: error: too many sections (35325)
I've been noticed that the exprtk.hpp file is huge (>32000 lines).
I've been trying optimization flags on compiler but It didn't help eighter.
I'll be appreciated if somebody help me...
Regards,
You can by adding the compilation flags -flto -Wl,-allow-multiple-definition and you can add -fuse-linker-plugin
-Wa,-mbig-obj do not work on x86/32bits architecture (only x64)
Such huge header-only code is already bad design, i'd rather recommend to use another library, like muParser.
Your problem was already discussed in other threads, like this.
As you've already noticed, passing /bigobj to Microsoft's compiler
causes it to output a munged COFF format with up to 2^31 sections,
which "should be enough for anybody."
I've tested this new option with MinGW-w64 and it works. You need to
pass -Wa,-mbig-obj to gcc to opt-in to big objects (-Wa means pass
this option to the assembler). – Francis Gagné
I've been having some difficulty compiling a piece of C++ code for the physics engine Bullet Physics, and was hoping to get some advice.
This is my first time using gcc as a compiler, and including directories for compiling in general, so I'm going to give my whole process of problem-solving because I'm not sure where I went wrong or what the pertinent information is.
When I first tried to compile the code I got a fatal error about "No such error or directory", so I decided to add the directory with the -I option (1). It fixed the first error, but another popped up. Again, I was able to make the error go away with a -I option to the directory needed(2).
Then I got a whole long list of errors like the following:
main.cpp:(.text+0x33): undefined reference to 'RagdollDemo::initPhysics()'
main.cpp:(.text+0x84): undefined reference to 'glutmain(int, char**, int, int, char const*, DemoApplication*)'
/tmp/cc4MqhHm.o: In function '__static_initialization_and_destruction_0(int, int)':
main.cpp:(.text+0xe7): undefined reference to `std::ios_base::Init::Init()'
I tried a few different things, but the solution ended up using my home bullet folder (or usr/local/include/bullet/) with the --sysroot option (3).
This created a lot of errors for the C++ header files, and then I linked to a few more directories with -I (4-5), but at after one of the added directories the same set of errors that I thought I solved with the --sysroot addition popped up again (6).
I can't tell what to do now. I would guess that declaring the bullet folder as my root makes it impossible for the compiler to find the required C++ files in my actual root directories, but I don't what to do about that... and when I tried including the C++ files I needed, the compiler seemingly forgot I told it to use bullet as my root.
Final compilation I tried before I gave up and realized asking for help might be better than spending 3 hours looking at documentation without any idea of what the exact problem is. Numbers correspond to the steps above.
gcc
(3)--sysroot=/home/josh/bullet-2.82-r2704/
(1)-isystem/home/josh/bullet-2.82-r2704/Demos/OpenGL/
(2)-isystem/home/josh/bullet-2.82-r2704/src/
(4)-I/usr/include/
(5)-I/usr/include/c++/4.8
(6)-I/usr/include/x86_64-linux-gnu/c++/4.8/
./main.cpp
I'm using Ubuntu 14.04 LTS and my OS and emacs 24.3.1 as my IDE.
Any help would be greatly appreciated.
Best,
Josh
What you are seeing is not include issue. Linker is failing to link with symbols. You need to link with proper library, for example lglut
I have been running into trouble recently trying to symbolicate a crash log of an iOS app. For some reason the UUID of the dSYM was not indexed in Spotlight. After some manual search and a healthy dose of command line incantations, I managed to symbolicate partially the crash log.
At first I thought the dSYM might be incomplete or something like that, but then I realized that the method calls missing were the ones occurring in C++ code: this project is an Objective-C app that calls into C++ libraries (via Objective-C++) which call back to Objective-C code (again, via Objective-C++ code). The calls that I'm missing are, specifically, the ones that happen in C++ land.
So, my question is: is there some way that the symbolication process can resolve the function calls of C++ code? Which special options do I need to set, if any?
One useful program that comes with the apple sdk is atos (address to symbol). Basically, here's what you want to do:
atos -o myExecutable -arch armv7 0x(address here)
It should print out the name of the symbol at that address.
I'm not well versed in Objective-C, but I'd make sure that the C++ code is being compiled with symbols. Particularly, did you make sure to include -rdynamic and/or -g when compiling the C++ code?
try
dwarfdump --lookup=0xYOUR_ADRESS YOUR_DSYM_FILE
you will have to look up each adress manually ( or write a script to do this ) but if the symbols are ok ( your dSym file is bigger than say 20MB) this will do the job .