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.
I am a very new to programming and have a very basic question that may be answered in other threads however I think they are far too advanced for me to understand how. I have actually found many answers so far on this site but this is the first problem that forced me to create an account and ask.
Anyway i am running a very basic example program on linux mint 18.3. Now I have seen this exact code work on a machine with windows 8 I believe so I was wondering if that could be the problem. I have created a class and when i plug in my object then build and run I get:
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crt1.o||In function _start':|
(.text+0x20)||undefined reference tomain'|
This is the entire code:
#include <iostream>
#include "Gladius.h"
using namespace std;
int main()
{
Gladius io;
return 0;
}
Thats it very basic. here is the .h
#ifndef GLADIUS_H
#define GLADIUS_H
class Gladius
{
public:
Gladius();
};
#endif // GLADIUS_H
and the .cpp for the class.
#include "Gladius.h"
#include <iostream>
using namespace std;
Gladius::Gladius()
{
cout << "The Gladius is a short sword" << endl;
}
I know this seems extremely simple but I am just learning to code and i have been looking all over for an explanation why this isn't working yet I see it work on another pc exactly as is. Anyway any explanation would be greatly appreciated.
Here is what i found in command line If this answers your questions about what was in the cmd.
g++ -Wall -fexceptions -g -std=c++11 -Wall -I -c /home/gator/Documents/Spartan1/Gladius.cpp -o obj/Debug/Gladius.o
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crt1.o: In function _start':
(.text+0x20): undefined reference tomain'
collect2: error: ld returned 1 exit status
Know the compiler options(gcc/g++ compiler):
-c : Compile and assemble, but do not link
-o file : Place the output into file
So when you run
g++ filename.cpp -o executable_name
, you generate an application which can be executed.
The problem is you are compiling, assembling as well as linking when you are trying to compile "Gladius.cpp" and compiler is trying to search for main() definition.
So in your case, the compilation steps would be:
First compile "Gladius.cpp" and generate object file "Gladius.o":
g++ -Wall -fexceptions -g -std=c++11 -c Gladius.cpp
Next compile "main.cpp" and generate object file "main.o":
g++ -Wall -fexceptions -g -std=c++11 -c main.cpp
Generate executable by linking "main.o" and "Gladius.o"
g++ -Wall -fexceptions -g -std=c++11 -o main main.o Gladius.o
Now you can run "main":
./main
Your compiler's command line contains -I -c sequence.
This -I option "swallows" your -c option. -I requires an additional argument, which is an include directory name. You failed to supply that argument, which is why -I assumes that -c that follows it is the directory name. So that -I consumes that -c.
The compiler never sees that -c. Without -c it assumes that you want to compile and link your program. Since Gladius.cpp does not have main in it, you get the error at linking stage.
Here 's a simple demo of the same problem: http://coliru.stacked-crooked.com/a/8a37cd3e90a443e2
You need to figure out why you have an orphaned -I in your command line.
If you are compiling this code using a command line like:
g++ -Wall -Wextra -Werror -O gladius.cpp -o output.exe
then make sure that you include all the .cpp files (not .h files) that contain code that your program needs.
g++ -Wall -Wextra -Werror -O gladius.cpp main.cpp -o output.exe
I explain this to beginners all the time as each .cpp being a bag of Lego's in a kit. You need all the bags that came with the box in order to build the kit. If you omitted main.cpp (or the file that contains main) then you will get the linker error that you are currently getting.
What command are you using to compile, link, and then execute? It should look something like
$ g++ main.cpp gladius.cpp -odemo
$ ./demo
check your command line for linking step.. You may forgot file with main as input, or you had forgot output file name after -o (and masked main.o in result)
I had this very kind of problem myself, and though it may not be the conventional, "proper" solution, I simply renamed the ".c" file to ".cpp", and it all worked.
After all, I was compiling both c and c++ together with a c++ compiler (recommended by the library), and the c code already had the proper c++ #extern flags (see here for more on that).
Also related:
C++ Error: undefined reference to `main'
Including C Code in C++
Why do you need an explicit `-lm` compiler option
Compilation on Linux - In function '_start': (.text+0x20): undefined reference to 'main'
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 ).