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.
Related
I have a simple test program for OpenCV:
#include "opencv2/opencv.hpp"
#include "opencv2/core/core.hpp"
#include "opencv2/highgui/highgui.hpp"
#include "opencv2/imgcodecs/imgcodecs.hpp"
#include <iostream>
int main(int argc, char **argv){
std::cout << "HELLO" << std::endl;
cv::Mat im=cv::imread((argc==2)? argv[1]: "testing.jpg",cv::IMREAD_COLOR);
if (im.empty()){
std::cout << "Cannot open image." << std::endl;
} else {
cv::namedWindow("DisplayWindow",cv::WINDOW_AUTOSIZE);
cv::imshow("DisplayWindow",im);
cv::waitKey(0);
}
return 0;
}
However, when run the program does nothing. Hello is not printed to the console, and it does not output an error.
./main
#Nothing.......
It is worth noting that the program terminates, but not in the proper way. (The return value is non-zero) I do not think that this is a linking error, as those would actually output an error.
Any ideas on what is happening and/or how to fix it? I am using a Windows computer if that changes anything.
Turns out the windows cmd prompt actually has some use. (VERY surprising, I gave up on it a long time ago)
I ran the test program from the windows cmd line and it said the following libraries were missing.
libstdc++-6.dll
libgcc_s_dw2-1.dll
libwinpthread-1.dll
To fix the standard C++ and C libraries I just statically linked them using the below command. (This is apparently a common practice on Windows due to issues with version control):
g++ -static-libgcc -static-libstdc++ ...rest of compile/link cmd...
To fix the winpthread dll I just copied the dll to the bin folder of my program and everything worked!
not particularly good with this kind of stuff I have managed to install the Boost C++ library and this basic program works with the g++ compiler and linking to the right .dylib files.
#include <iostream>
#include <boost/filesystem.hpp>
using namespace boost;
int main()
{
filesystem::path path1("/Users/username/Documents/testfile.txt");
filesystem::remove(path1);
std::cout << "It worked" << std::endl;
return 0;
}
Now I would like to do the same, just using Xcode to build and run the program, but it doesn't work. I have done everything in this tutorial:
http://buddypanda.com/?p=10
i.e. include header and library search paths, as well as linked the .dylib files of filesystem and system under the 'Build Phases' tab.
The Build succeeds but then the program crashed with an error of EXC_BAD_ACCESS.
I can maybe provide more specifics on what goes wrong if you tell me where to look.
Thanks!
EDIT1: I am using g++-4.9 and Boost-1.58 and Xcode 6.4
I have 3 computers, two of which use Windows 8. Using the latest version of MinGW's g++ (4.8.1-4) my hello world program freezes whenever I compile and run on the Windows 8 computers but not in Windows 7.
#include <iostream>
int main()
{
std::cout << "Hello, World!" <<std::endl;
return 0;
}
This compiles just fine in g++ but running a.exe will display "Hello, World!" then a window will pop up and say "a.exe has stopped working, Windows can check online for a solution to the program...." etc.
Has anybody seen this problem.
Also, I tried "std::cout << "Hello, World!\n" << std::flush;" and this has the same problem. It seems that every function that flushes the buffer causes a crash.
Following Eric's advice, I recompiled the program and ran it in gdb and got the following output:
Program received signal SIGILL, Illegal instruction.
0x00405065 in _Jv_RegisterClasses ()
In the second instance, the '\n' should cause an output flush in any case, although in Windows I believe console output is immediate (or perhaps automatic after a short timeout) in any case without an explicit flush.
I suggest the following experiments:
1) See if it is specific to the C++ library by using the C library (in MinGW Microsoft's C runtime is used rather than glibc):
#include <stdio.h>
int main()
{
printf( "Hello, World!\n" ) ;
return 0;
}
2) Eliminate the exit code by:
int main()
{
return 0;
}
3) No newline at all:
#include <iostream>
int main()
{
std::cout << "Hello, World! ;
return 0;
}
4) Try different compiler options such as optimisation levels, or -fno-builtin for example, or as suggested here: -static-libgcc -static-libstdc++ (although I doubt ``-static-libgcc` will itself have any effect since MinGW uses Microsoft's C runtime DLL and the static library is only available with Microsoft's tools).
I had the same issue and found after a long painful search that I had multiple versions of the mingw provided libstdc++-6.dll on my computer. One was part of the mingw installation the others were part of other installation packages (gnuplot and GIMP). As I had gnuplot in my PATH the compiled mingw exe it would use an older, incompatible version of this dll and crash with the described symptoms. I can, therefore, confirm Dietmar Kühl's suspicion. As suggested above linking the library statically obviously helps in this case as the library functions are included in the exe at compile time.
I am building a Makefile project in Eclipse Juno, and I have it set up so it compiles and debugs (it's using CMake, so I'm not using the internal tools). However, Eclipse obviously hasn't been informed of the right headers, as in the following code:
#include <iostream>
using namespace std;
int main ()
{
cout << "Hello world << endl;
return 0;
}
the include "iostream" and symbols "std", "cout" and "endl" are all unresolved.
How should I make Eclipse aware of these so it will stop underlining everything in red and spamming with errors?
This can be resolved by specifying the following environmental variables in Project->Properties->C++ Build->Environment.
LANG=en_US
LC_ALL=en_US
Apparently they are needed for the auto-discovery tools to work out where the includes live.
Answer gleaned from this Eclipse forum thread.
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.