I'm trying to use the JsonCpp library. I'm on Windows, using MinGW and CodeBlocks.
When I include anything from the json headers, my linker implodes and gives out this two errors. I've started to look around and I found these two other questions which basically describe my problem:
problem with g++ and "undefined reference to `__gxx_personality_v0'"
What is __gxx_personality_v0 for?
And if I declare the two missing variables as void pointers, like below, the problem goes away:
void * __gxx_personality_v0=0;
void * _Unwind_Resume =0;
However, I don't understand why this error happens. CodeBlocks is set up so that it uses migw32-g++ for cpp files, and also adding the -lstdc++ option does not fix the problem. Neither does the option -fno-exception ( I want exceptions, mind you, I was just trying ).
I'm also including a boost library in the same file and that does not cause any problems.
EDIT:
The error output is exactly what I said in my title: I get a total of 22 undefined references to _Unwind_Resume and __gxx_personality_v0 during the linking. My code is:
#include <boost/algorithm/string.hpp>
#include <include/json/value.h>
//void * __gxx_personality_v0=0;
//void * _Unwind_Resume =0;
int main () {
std::string str1("Hello world!");
boost::to_upper(str1);
Json::Value k;
return 0;
}
The error is there only when I include/use the JsonCPP library. Uncommenting the commented lines fixes the problem.
The command line output is this:
mingw32-g++.exe -Wall -fexceptions -g -DSFML_DYNAMIC -IC:\Users\Svalorzen\Documents\Projects\boost_1_49 -IC:\Users\Svalorzen\Documents\Projects\jsoncpp-src-0.5.0 -IC:\Users\Svalorzen\Documents\Projects\SFML-1.6\include -IC:\Users\Svalorzen\Documents\Projects\hge181\include -c C:\Users\Svalorzen\Documents\Projects\test\main.cpp -o obj\Debug\main.o
mingw32-g++.exe -LC:\Users\Svalorzen\Documents\Projects\jsoncpp-src-0.5.0 -LC:\Users\Svalorzen\Documents\Projects\SFML-1.6\lib -LC:\Users\Svalorzen\Documents\Projects\hge181\lib -o bin\Debug\test.exe obj\Debug\main.o -fno-exceptions -lsfml-graphics -lsfml-window -lsfml-system C:\Users\Svalorzen\Documents\Projects\jsoncpp-src-0.5.0\libs\mingw\libjson_mingw_libmt.a C:\Users\Svalorzen\Documents\Projects\hge181\lib\gcc\libhge.a C:\Users\Svalorzen\Documents\Projects\hge181\lib\gcc\libhelp.a
Output size is 1.22 MB
Process terminated with status 0 (0 minutes, 3 seconds)
0 errors, 0 warnings
SECOND EDIT:
I'm adding the command lines I use to compile the library:
g++ -o buildscons\mingw\src\lib_json\json_reader.o -c -DWIN32 -DNDEBUG -D_MT -Iinclude src\lib_json\json_reader.cpp
g++ -o buildscons\mingw\src\lib_json\json_value.o -c -DWIN32 -DNDEBUG -D_MT -Iinclude src\lib_json\json_value.cpp
g++ -o buildscons\mingw\src\lib_json\json_writer.o -c -DWIN32 -DNDEBUG -D_MT -Iinclude src\lib_json\json_writer.cpp
ar rc buildscons\mingw\src\lib_json\libjson_mingw_libmt.a buildscons\mingw\src\lib_json\json_reader.o buildscons\mingw\src\lib_json\json_value.o buildscons\mingw\src\lib_json\json_writer.o
ranlib buildscons\mingw\src\lib_json\libjson_mingw_libmt.a
For those coming to this from google (like i did), the real cause of the undefined references to _Unwind_Resume and __gxx_personality_v0 is "using a gcc that uses a different stack unwinding method than dwarf2" [1]
In my case it was attempting to link code compiled with GCC 4.9 upwards with a library compiled with GCC 4.8 or below. The solution is to recompile the library with the same compiler you're building with.
I encountered that same problem attempting to use g++ -g -std=c++17 ... . I removed that option and, once I had removed use of a C++17 feature, it compiled, linked and ran.
I finally fixed this by importing into Code::Blocks the source code of JsonCpp and creating the library myself. I am still baffled though as to why the library created with Scons didn't work, since it was using the same compiler that Code::Blocks uses, but at the same time it was not ( or the error wouldn't have been there ).
Related
I'm trying to use the JsonCpp library. I'm on Windows, using MinGW and CodeBlocks.
When I include anything from the json headers, my linker implodes and gives out this two errors. I've started to look around and I found these two other questions which basically describe my problem:
problem with g++ and "undefined reference to `__gxx_personality_v0'"
What is __gxx_personality_v0 for?
And if I declare the two missing variables as void pointers, like below, the problem goes away:
void * __gxx_personality_v0=0;
void * _Unwind_Resume =0;
However, I don't understand why this error happens. CodeBlocks is set up so that it uses migw32-g++ for cpp files, and also adding the -lstdc++ option does not fix the problem. Neither does the option -fno-exception ( I want exceptions, mind you, I was just trying ).
I'm also including a boost library in the same file and that does not cause any problems.
EDIT:
The error output is exactly what I said in my title: I get a total of 22 undefined references to _Unwind_Resume and __gxx_personality_v0 during the linking. My code is:
#include <boost/algorithm/string.hpp>
#include <include/json/value.h>
//void * __gxx_personality_v0=0;
//void * _Unwind_Resume =0;
int main () {
std::string str1("Hello world!");
boost::to_upper(str1);
Json::Value k;
return 0;
}
The error is there only when I include/use the JsonCPP library. Uncommenting the commented lines fixes the problem.
The command line output is this:
mingw32-g++.exe -Wall -fexceptions -g -DSFML_DYNAMIC -IC:\Users\Svalorzen\Documents\Projects\boost_1_49 -IC:\Users\Svalorzen\Documents\Projects\jsoncpp-src-0.5.0 -IC:\Users\Svalorzen\Documents\Projects\SFML-1.6\include -IC:\Users\Svalorzen\Documents\Projects\hge181\include -c C:\Users\Svalorzen\Documents\Projects\test\main.cpp -o obj\Debug\main.o
mingw32-g++.exe -LC:\Users\Svalorzen\Documents\Projects\jsoncpp-src-0.5.0 -LC:\Users\Svalorzen\Documents\Projects\SFML-1.6\lib -LC:\Users\Svalorzen\Documents\Projects\hge181\lib -o bin\Debug\test.exe obj\Debug\main.o -fno-exceptions -lsfml-graphics -lsfml-window -lsfml-system C:\Users\Svalorzen\Documents\Projects\jsoncpp-src-0.5.0\libs\mingw\libjson_mingw_libmt.a C:\Users\Svalorzen\Documents\Projects\hge181\lib\gcc\libhge.a C:\Users\Svalorzen\Documents\Projects\hge181\lib\gcc\libhelp.a
Output size is 1.22 MB
Process terminated with status 0 (0 minutes, 3 seconds)
0 errors, 0 warnings
SECOND EDIT:
I'm adding the command lines I use to compile the library:
g++ -o buildscons\mingw\src\lib_json\json_reader.o -c -DWIN32 -DNDEBUG -D_MT -Iinclude src\lib_json\json_reader.cpp
g++ -o buildscons\mingw\src\lib_json\json_value.o -c -DWIN32 -DNDEBUG -D_MT -Iinclude src\lib_json\json_value.cpp
g++ -o buildscons\mingw\src\lib_json\json_writer.o -c -DWIN32 -DNDEBUG -D_MT -Iinclude src\lib_json\json_writer.cpp
ar rc buildscons\mingw\src\lib_json\libjson_mingw_libmt.a buildscons\mingw\src\lib_json\json_reader.o buildscons\mingw\src\lib_json\json_value.o buildscons\mingw\src\lib_json\json_writer.o
ranlib buildscons\mingw\src\lib_json\libjson_mingw_libmt.a
For those coming to this from google (like i did), the real cause of the undefined references to _Unwind_Resume and __gxx_personality_v0 is "using a gcc that uses a different stack unwinding method than dwarf2" [1]
In my case it was attempting to link code compiled with GCC 4.9 upwards with a library compiled with GCC 4.8 or below. The solution is to recompile the library with the same compiler you're building with.
I encountered that same problem attempting to use g++ -g -std=c++17 ... . I removed that option and, once I had removed use of a C++17 feature, it compiled, linked and ran.
I finally fixed this by importing into Code::Blocks the source code of JsonCpp and creating the library myself. I am still baffled though as to why the library created with Scons didn't work, since it was using the same compiler that Code::Blocks uses, but at the same time it was not ( or the error wouldn't have been there ).
There are similar questions but their answers did not work for my issue.
I have a c++ program with #include <boost/test/unit_test.hpp> on top (among other includes).
To compile correctly, if I understood, I should do the command:
g++ -g -L/path_to_boost_lib -lboost_lib myprog.cpp -o myprog.exe
If i do a locate, I get /usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so.
Hence I edited my call to g++ by doing:
g++ -g -L/usr/lib/x86_64-linux-gnu -lboost_unit_test_framework myprog.cpp -o myprog.exe
But I still get errors of the type undefined reference to boost::unit_test.
I also tried the option -I/usr/include/ which contains the boost folder, without success.
It's because of the order. The GCC linker goes through the artifacts left-to-right, and every unknown symbol it encounters in an object file must be resolved by an artifact occurring afterwards.
The right command is thus:
g++ -g myprog.cpp -L/usr/lib/x86_64-linux-gnu -lboost_unit_test_framework -o myprog.exe
See this answer for a more thorough explanation.
I suggest using a build tool like CMake that takes care of such low-level details for you.
This question already has answers here:
Why does the order in which libraries are linked sometimes cause errors in GCC?
(9 answers)
Closed 5 years ago.
There are linker errors to Symbols defined by SFML, but i cannot see how they occur despite that I linked the lib.
I'm using make, which I currently learn and I want to build a minimalistic dev-environment with it.
Give a holler if you need anymore information than the following. I'd just like to minimize the questions size.
XXX#XXX ~/Documents/dev/cpp/proj/beep $ make clean
rm -f build/*.o build/release/*.o build/debug/*.o build/test/*.o
XXX#XXX ~/Documents/dev/cpp/proj/beep $ make tests
//test obj first
g++ -std=c++14 -Wall -pthread -Iinclude -c test/Packager.ut.cpp -o build/test/Packager.ut.o -g3
//now the src obj
g++ -std=c++14 -Wall -pthread -Iinclude -c src/ClientAddress.cpp -o build/debug/ClientAddress.o -g3
g++ -std=c++14 -Wall -pthread -Iinclude -c src/Packager.cpp -o build/debug/Packager.o -g3
g++ -std=c++14 -Wall -pthread -Iinclude -c src/Package.cpp -o build/debug/Package.o -g3
Built debug object files.
//now the first test itself
g++ -std=c++14 -Wall -pthread -Iinclude -lsfml-network build/test/Packager.ut.o build/debug/ClientAddress.o build/debug/Packager.o build/debug/Package.o -g3 -o bin/test/Packager.ut
build/test/Packager.ut.o: In function `main':
/home/XXX/Documents/dev/cpp/proj/beep/test/Packager.ut.cpp:69: undefined reference to `sf::IpAddress::IpAddress(char const*)'
build/debug/ClientAddress.o: In function `nw::udp::ClientAddress::ClientAddress()':
/home/XXX/Documents/dev/cpp/proj/beep/src/ClientAddress.cpp:21: undefined reference to `sf::IpAddress::IpAddress(char const*)'
build/debug/ClientAddress.o: In function `nw::udp::operator==(nw::udp::ClientAddress const&, nw::udp::ClientAddress const&)':
/home/XXX/Documents/dev/cpp/proj/beep/src/ClientAddress.cpp:33: undefined reference to `sf::operator==(sf::IpAddress const&, sf::IpAddress const&)'
...
and so on ... every mentionings of sf:: inside the files are quoted
I get the same error pattern if I try to compile the other tests (for ClientAddress for example)
Of course i now want to know what i linked wrong how there. As you can see the lib is linked with -lsfml-network. I also checked the SMFL installation, so it is at least less likely a lib file gone missing from standard directory.
I guess there is an error in my usage of g++ , compiling and linking orders or smth.
My project tree:
>bin
----mainexec
--->test
----.ut
>build
--->debug
----.o
--->release
----.o
--->test
----.ut.o
>src
---- .cpp
>include
---- .h
>test
---- .ut.cpp
As a second part of the question, I'd like to ask if there is a better way to build tests, because I simply link every src-obj with my test-obj, even if there are way more src-obj linked than it actually needs. It should work and I do not have to maintain my test dependencies all the time, which later would be very cumbersome. What is common ?
sfml-network has a dependency on sfml-system. Try add -lsfml-system before -lsfml-network in your linker command in your makefile
I'm trying to use the JsonCpp library. I'm on Windows, using MinGW and CodeBlocks.
When I include anything from the json headers, my linker implodes and gives out this two errors. I've started to look around and I found these two other questions which basically describe my problem:
problem with g++ and "undefined reference to `__gxx_personality_v0'"
What is __gxx_personality_v0 for?
And if I declare the two missing variables as void pointers, like below, the problem goes away:
void * __gxx_personality_v0=0;
void * _Unwind_Resume =0;
However, I don't understand why this error happens. CodeBlocks is set up so that it uses migw32-g++ for cpp files, and also adding the -lstdc++ option does not fix the problem. Neither does the option -fno-exception ( I want exceptions, mind you, I was just trying ).
I'm also including a boost library in the same file and that does not cause any problems.
EDIT:
The error output is exactly what I said in my title: I get a total of 22 undefined references to _Unwind_Resume and __gxx_personality_v0 during the linking. My code is:
#include <boost/algorithm/string.hpp>
#include <include/json/value.h>
//void * __gxx_personality_v0=0;
//void * _Unwind_Resume =0;
int main () {
std::string str1("Hello world!");
boost::to_upper(str1);
Json::Value k;
return 0;
}
The error is there only when I include/use the JsonCPP library. Uncommenting the commented lines fixes the problem.
The command line output is this:
mingw32-g++.exe -Wall -fexceptions -g -DSFML_DYNAMIC -IC:\Users\Svalorzen\Documents\Projects\boost_1_49 -IC:\Users\Svalorzen\Documents\Projects\jsoncpp-src-0.5.0 -IC:\Users\Svalorzen\Documents\Projects\SFML-1.6\include -IC:\Users\Svalorzen\Documents\Projects\hge181\include -c C:\Users\Svalorzen\Documents\Projects\test\main.cpp -o obj\Debug\main.o
mingw32-g++.exe -LC:\Users\Svalorzen\Documents\Projects\jsoncpp-src-0.5.0 -LC:\Users\Svalorzen\Documents\Projects\SFML-1.6\lib -LC:\Users\Svalorzen\Documents\Projects\hge181\lib -o bin\Debug\test.exe obj\Debug\main.o -fno-exceptions -lsfml-graphics -lsfml-window -lsfml-system C:\Users\Svalorzen\Documents\Projects\jsoncpp-src-0.5.0\libs\mingw\libjson_mingw_libmt.a C:\Users\Svalorzen\Documents\Projects\hge181\lib\gcc\libhge.a C:\Users\Svalorzen\Documents\Projects\hge181\lib\gcc\libhelp.a
Output size is 1.22 MB
Process terminated with status 0 (0 minutes, 3 seconds)
0 errors, 0 warnings
SECOND EDIT:
I'm adding the command lines I use to compile the library:
g++ -o buildscons\mingw\src\lib_json\json_reader.o -c -DWIN32 -DNDEBUG -D_MT -Iinclude src\lib_json\json_reader.cpp
g++ -o buildscons\mingw\src\lib_json\json_value.o -c -DWIN32 -DNDEBUG -D_MT -Iinclude src\lib_json\json_value.cpp
g++ -o buildscons\mingw\src\lib_json\json_writer.o -c -DWIN32 -DNDEBUG -D_MT -Iinclude src\lib_json\json_writer.cpp
ar rc buildscons\mingw\src\lib_json\libjson_mingw_libmt.a buildscons\mingw\src\lib_json\json_reader.o buildscons\mingw\src\lib_json\json_value.o buildscons\mingw\src\lib_json\json_writer.o
ranlib buildscons\mingw\src\lib_json\libjson_mingw_libmt.a
For those coming to this from google (like i did), the real cause of the undefined references to _Unwind_Resume and __gxx_personality_v0 is "using a gcc that uses a different stack unwinding method than dwarf2" [1]
In my case it was attempting to link code compiled with GCC 4.9 upwards with a library compiled with GCC 4.8 or below. The solution is to recompile the library with the same compiler you're building with.
I encountered that same problem attempting to use g++ -g -std=c++17 ... . I removed that option and, once I had removed use of a C++17 feature, it compiled, linked and ran.
I finally fixed this by importing into Code::Blocks the source code of JsonCpp and creating the library myself. I am still baffled though as to why the library created with Scons didn't work, since it was using the same compiler that Code::Blocks uses, but at the same time it was not ( or the error wouldn't have been there ).
I have been writing a c++ program in Ubuntu and window8 using armadillo. Under Windows8 the program compiles without problems.
The program is just using the linear systems solver.
Under Ubuntu the compiler says
"reference to `wrapper_dgels_' not defined"
The compiler line I use is:
mpic++ -O2 -std=c++11 -Wall -fexceptions -O2 -larmadillo -llapack -lblas program.o
However, right before the error I see:
g++ module_of_the_error.o
Which is something I haven't set.
I am using code blocks in Ubuntu, and I compiled armadillo with all the libraries that cmake asked. (BLAS< LAPACK, OpenBLAS, HDF5, ARPACK, etc)
I have no clue what might be causing the problem, since the exact same code compiles in visual studio.I have tried the compiler line modifications suggested but it does not seem to work.
Any help is appreciated.
This is one trap I fell into myself one time. You will not like the likely cause of your error.
The order of the arguments to the linker matters.
Instead of
mpic++ -O2 -std=c++11 -Wall -fexceptions -O2 -larmadillo -llapack -lblas program.o
try:
mpic++ -O2 -std=c++11 -Wall -fexceptions -O2 program.o -larmadillo -llapack -lblas
I.e., put the object files to be linked into the executable before the libraries.
By the way, at this stage you are only linking files that have already been compiled. It is not necessary to repeat command line options that are only relevant for compiling. So this will be equivalent:
mpic++ program.o -larmadillo -llapack -lblas
Moreover, depending on how you installed Armadillo, you are adding either one or two superfluous libraries in that line. One of the following should be enough:
mpic++ program.o -larmadillo
or
mpic++ program.o -llapack -lblas
EDIT: as the answer by rerx states, the problem is probably just a simple ordering of the switches/arguments supplied to g++. All the -l switches need to be after the -o switch. Or in other words, put the -o switch before any -l switches. For example:
g++ prog.cpp -o prog -O3 -larmadillo
original answer:
Looks like your compiler can't find the Armadillo run-time library. The proper solution is to specify the path for armadillo run-time library using the -L switch. For example, g++ -O2 blah.cpp -o blah -L /usr/local/lib/ -larmadillo
Another possible solution is to define ARMA_DONT_USE_WRAPPER before including the armadillo header, and then directly link with LAPACK and BLAS. For example:
#define ARMA_DONT_USE_WRAPPER
#include <armadillo>
More details are available at the Armadillo frequently asked questions page.