I'm trying to link jsoncpp (lib_json) with a c++ project using cmake. It works perfectly fine on one computer, but on another one (with pretty much the same config) i get an error when i execute my app :
dyld: Library not loaded: buildscons/linux-gcc-4.2.1/src/lib_json/libjson_linux-gcc-4.2.1_libmt.dylib
Referenced from: path to executable
Reason: image not found
Any idea what might be causing this ? I don't even understand why it tries to look # buildscons/linux-gcc-4.2.1/src/lib_json/libjson_linux-gcc-4.2.1_libmt.dylib since i put jsoncpp in usr/lib/ and changed the name to libjsoncpp and cmake find the correct path/library.
I also built jsoncpp the exact same way on both computers.
I had the same problem. If you run tool -L libjson_linux-gcc-4.2.1_libmt.dylib you can see some weird relative address to your libjson.... I guess if you replicated this directory structure it would work but that's a bad solution.
What I did instead is that I used .a (libjson_linux-gcc-4.2.1_libmt.a) and linked it staticaly with my binary. In XCode simply under Build Settings -> Linking -> Other Linker Flags I added absolute path to my .a. For me it was /Users/martin/Downloads/jsoncpp-src-0.5.0/libs/linux-gcc-4.2.1/libjson_linux-gcc-4.2.1_libmt.a and that's all.
Of course, I don't know your use case, maybe you really need to link it dynamically.
EDIT: I see now, you mean libjson, and not libjsoncpp (they're different!)
In your titel you talk about jsoncpp, and that's what this answer is for.
But maybe it's useful for people who got confused by the titel too.
You can 'amalgamate' jsoncpp.
From jsoncpp source dir run python amalgamate.py which creates:
dist/jsoncpp.cpp
dist/json/json.h
dist/json/json-forwards.h
Now you have to compile jsoncpp.cpp once and just link against the resulting jsoncpp.o:
g++ -o jsoncpp.o -c jsoncpp.cpp (only once)
g++ -o executable jsoncpp.o main.cpp (every time)
If you get errors, you might have to #define JSON_IS_AMALGAMATION before including json/json.h, but ...
... I tried it and it worked for me. (without #define JSON_IS_AMALGAMATION, that is)
Used code:
#include "json/json.h"
#include "json/json-forwards.h"
int main(int argc, char *argv[])
{
Json::Reader reader;
Json::Value value;
if (!reader.parse("{\"hello\":\"world\"}", value, false))
{
std::cerr << "ERROR: Couldn't parse Json: " << reader.getFormattedErrorMessages() << std::endl;
return -1;
}
std::cout << value.toStyledString() << std::endl;
return 0;
}
Related
So I spent 2 hours trying to narrow down the cause of my code not working and I think it might just be something weird. Here's the exact example code I have and I can't minimize it further (yes, bar does literally nothing) :
// thread example
#include <iostream> // std::cout
#include <thread> // std::thread
void bar()
{
// do stuff...
}
int main()
{
std::cout << "please run" << std::endl;
std::thread t(bar);
t.join();
std::cout << "completed.\n";
return 0;
}
Here's how I build it :
g++ -std=c++0x -o test test.cpp -pthread
When all of this is done in a blank directory, it works perfectly, but if I put test.cpp in my project directory, compile it here and run it, it crashes before even entering main. Here's the crash report but I translated it from French so it's not the exact text:
"The entry point of the procedure std::thread::_M_start_thread(std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State> >, void (*)()) cannot be found in the library of dynamic links [project directory]\test.exe"
Note that this message did not appear in the console command but in a separate window pop-up from where I can't copy-paste.
Here's what's the project directory is (not quite exactly because script files were updated but it's the same structure and libraries) : https://github.com/Leroymilo/RTX_Cpp
It has SFML and jsonCpp in it if it changes anything.
Also I am on Windows10 and I'm using VScode if it makes any difference.
I did what's advised in this post : Segmentation Fault while creating thread using #include<thread> but it does not change the result.
The issue was the presence of a file called "libstdc++-6.dll" in my project directory. I have no memories of why it's here because I copied all libraries from another project but if anyone does the same mistake, here's your solution.
Edit : I found out about why I had this in my files : it's because my build wasn't static and launching the built executable on another computer showed a pop-up asking for these. I fixed my static build issue with the answers provided in this post : Issues with libgcc_s_dw2-1.dll and libstdc++-6.dll on build .
I'm trying to run a helloworld program which uses boost filesystem.
I'm on Windows with MinGW 8.1 and boost 1.70.
The problem is that, although everything compiles, the program doesn't run. I mean, it runs but doesn't print anything, which means the main function is not even executed:
#include <boost/filesystem.hpp>
#include <iostream>
using namespace std;
using namespace std::string_literals;
namespace fs = boost::filesystem;
int main()
{
cout << "Hello Boost!" << endl;
fs::path abHome{"C:/Users/Me"s};
fs::path jsonFile = abHome / "jsonFile.json"s;
if (!fs::exists(jsonFile)) {
cout << "Creating json file from scratch." << endl;
}
}
"Hello Boost" isn't ever printed to the console.
I've compiled with both CMake and g++ from command line to try to better understand what's going on:
g++ main.cpp -o main -L"C:/Code/boost_1_70_0/stage/lib" -lboost_filesystem-mgw81-mt-x64-1_70 -lboost_system-mgw81-mt-x64-1_70 -I"C:/Code/boost_1_70_0"
I've compiled boost for MinGW by following the guide and everything went well, in the output folder I see many different versions of each library based on the default targets (I haven't really picked them, just went with the defaults).
How can I debug the launch of main.exe to see what's causing the crash? It's been many years since I wrote C++ so I need help to get back on track! :)
The problem was, as #kenba pointed out, that the dynamic linking of the boost dlls was failing.
I erroneously thought I had linked the static version of the boost libraries.
To actually achieve that I should have used this command:
g++ main.cpp -o main -L"C:/Code/boost_1_70_0/stage/lib" -l:"libboost_filesystem-mgw81-mt-x64-1_70.a" -l:"libboost_system-mgw81-mt-x64-1_70.a" -I"C:/Code/boost_1_70_0"
instead of the one I posted in the OP.
main.cpp
#include <iostream>
#include <string>
using namespace std;
void echo(string);
int main()
{
echo("hello");
cout << "Hello world!" << endl;
return 0;
}
print.cpp
#include <iostream>
#include <string>
void echo(string code){
cout << code;
}
After compiling the code in code blocks 12.11, it gives me that error:
undefined reference to `echo(std::string)
I use windows 7 x64.
I have added the directory; Project>build options > search directories and added the current working directory.
All the files are in one console project in code blocks
I believe you should read up a bit more on namespaces usage. You are missing std in print.cpp.
Generally, while starting to learn cpp or getting a grip of the language you should always try writing full names of the classes along with the namespaces. Eventually with practice and some oversights (like now) you will learn why you really need them. In a nutshell namespaces are great:
When you are writing code over multiple files
Compartmentalize your code into separate blocks.
Also, using namespace std; should be used within cpp files mostly (otherwise headers get mangled up.
Anyways, try changing your code to this:
#include <iostream>
#include <string>
void echo(std::string code){
std::cout << code;
}
Then your results will look like this:
> g++ main.cpp print.cpp -o a.out
> ./a.out
helloHello world!
You should get more than that linker error, since you use string without any namespace in your print.cpp file. And if that source file doesn't compile it can't be linked with, and you will get the linker error you have.
Change to e.g.
void echo(std::string code) { ... }
And you do try to link with the object file created from print.cpp ?
I know this is old, but for anyone looking to solve this issue, the following may be a solution for you. If you have g++ follow c++ 11 under project->build options (check your options anyway) then you must check that box for all files you make in the project for the error to be cleared up. I had that annoying undefined reference thing too but now it is gone!
Try "Project/Properties/Build Targets tab". There you should find "Build target files" field. In that filed find "print.cpp" and click the checkbox (now the compiler will build print.cpp).
Some usefull information on Project management in CB
http://www.codeblocks.org/docs/main_codeblocks_en.html
When dealing with strings in C++ its best to sue std::string and your code seems to be wrong with a changes like using std::cout instead of plain cout another thing you need to be careful is linking your files especially files in different directories you need to tell code blocks were to find this print.cpp by going to build option and go for the search tab directory and point to where print.cpp is other wise the other approach is to just build a project which will have the main.cpp and and then add print.cpp class to current project I hope this will be of some help
I just compiled zlib and libzip with Cygwin to use them with Code::Blocks in Windows.
My code is that:
#include <iostream>
#include <zip.h>
int main()
{
//Open the ZIP archive
int err = 0;
zip *z = zip_open("main.zip", 0, &err);
zip_close(z);
std::cout << "Hello world!" << std::endl;
return 0;
}
When I build my code, it works well, no errors and warnings.
When I launch my program, it says that I don't have cygzip-2.dll. Okay, I search it and put it in my executable folder. Then, it says that I don't have cygwin1.dll. Okay, I put it too. The same for cygz.dll and cyggcc_s-1.dll.
Oh, it works! But then, my program stops with always the same status: -1073741819.
It doesn't even tell me hello :(
I compiled it with MinGW (it did the same error on Cygwin), and I linked libz.a, libzip.a and libzip.dll.a. Where does the problem could come from?
Thanks!
EDIT: When I try to compile my program IN Cygwin, it says 'undefined reference to '_zip_open'' and 'undefined reference to '_zip_close''. Probably something is missing, but what?
Eventually, I succeeded to use my 2 libraries! I had already tried to use CMake, but failed miserably.
So today, I decided to retry it with the GUI. Firstly, I compiled zlib. I chose the zlib folder, and put the build folder in it. I configured with the option for Code::Blocks and MinGW Makefiles, and native compilers. Then, I opened the .cbp (Code::Blocks Project) in my 'build' folder, and built it.
For libzip, I did the steps except that I specified 2 variables:
ZLIB_INCLUDE_DIR = the root of zlib folder (where there are all the .h and .c) and ZLIB_LIBRARY = [the path to your build folder from zlib]\libzlib.dll
I built it from the .cbp too. And I linked all my files to my project, and it was done!
I am new to LEDA and I am working on LEDA6.3 Free Edition on OpenSuse 12.1.
As a start I tried to write a simple code "Hello LEDA world" as in the manual http://www.leda-tutorial.org/en/official/ch01s02.html.
#include <LEDA/string.h>
#include <iostream>
using leda::string;
using std::cout;
int main()
{
string msg = "Hello LEDA world!";
cout << msg << "\n";
}
The compilation phase works fine and I generated the .o file.
But they mentioned that this file needs to be linked to the LEDA library and the only library available in the Free edition is the libleda.a and libleda.so
I am trying to link using the following command:
g++ -o welcome welcome.o -L$LEDAROOT -llibleda
What I get is:
/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/bin/ld: cannot find -llibleda
I was wondering if someone could help me with how to link my file with the leda library ? so I can get it to run.
Thanks all.
It is unlikely that the library file is called liblibleda.a or liblibleda.so: when the linker sees a an option of the form -l<name> it will search for a library file named lib<name>.so (for shared libraries) or lib<name>.a (for static libraries). You probably just want to use the option -lleda (unless the LEDA developers did something clever and called the library something like libeda.a so you'd use -leda).
Whether this works will also depend on the compiler options being consistent between the installation and your build.