The code below runs on windows ok and the trace but after transferring and building it on linux nothing comes out on the window. Here is the program (I've literally commented everything out after the trace output now):
int main(int argc, char const* const argv[])
{
std::cerr << "Hello" << std::endl;
return 0;
}
I kick the program off and nothing comes out. It builds without error on linux (and windows). The trace comes out in windows but I get nothing in linux.
This is a makefile issue. If I compile the program using g++ it works. If I use the makefile it doesn't work although it says it has built and linked without error.
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!
When I use string variables in Eclipse CDT (MinGW compiler) and I run the program, it doesn't show me anything. Here's my code:
#include <iostream>
using namespace std;
int main() {
string hw = "Hello, world!";
cout << hw << endl;
return 0;
}
So that doesn't show anything, but when I just do cout << "Hello, world!" << endl; it does work.
I also tried including <string>, <string.h>, "string" and "string.h" but still no success. The same code does work in VC++ and Codeblocks though.
I can reproduce this problem on my machine. The output does not appear. But it is not an output problem, but actually two problems before you get to main:
The program is failing to launch. If you try double-clicking on it in Windows Explorer, you will get an error message like this:
The program can't start because libgcc_s_dw2-1.dll is missing from
your computer. Try reinstalling the program to fix this problem.
Screenshot of above:
When launched from within Eclipse, this error message is silently swallowed, so how are you supposed to know!
Solutions/Workarounds
You need to get the environment correctly set up to launch the MinGW program because its DLLs are not installed on Windows PATH or other standard places DLLs are searched for.
Add C:\MinGW\bin to your PATH
Launch Eclipse from within a MinGW shell (has basically same effect as 1)
Run the program in debug mode, this causes the program to be launched as a child of GCC and that sets up
Other options (not tried by me) may include statically linking the offending library, see The program can't start because libgcc_s_dw2-1.dll is missing
File a CDT bug about the error message being hidden.
Extra info
If your program compiles, as I am sure it does based on your comments, changing the includes is probably irrelevant.
By adding an infinite loop around the couts I could immediately identify something more than simply an output not being shown was going on. Try the same thing on your machine, and also try running the program from within MinGW shell and from outside it.
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 have downloaded plenty of different versions of code blocks, and none of them compiles quite right. My hello world runs within code blocks just fine. However, when I run the executable outside of codeblocks, it says "Hello.exe has stopped working". There isn't anything wrong with my code (I don't think.) and my mingw compiles fine outside of codeblocks. What does codeblocks do to my executable? Is there some option to fix this? I am on windows 7 64 bit, and my current code blocks version is 10.05. My program:
#include <iostream>
using namespace std;
int main()
{
cout << "Hello world!" << endl;
cin.ignore();
return 0;
}
I solved the problem. I had a broken compiler (or something like that). My suggestion for other people with this problem is to experiment with different versions of the minGW compiler. Also, change the version of code blocks you are using, or even uninstall everything and restart. The problem with mine was I downloaded a bad compiler. [The truth is, codeblocks isn't the best ide.]
I have installed the newest MinGW suite. My project still compiles without any error but the produced executable is not working. Starting it results in the well known windows xp error message. Paradoxically source code like
#include <stdio.h>
int main()
{
printf("test\n");
return 0;
}
produces a working executable while
#include <iostream>
int main()
{
std::cout << "test\n" << std::endl;
return 0;
}
compiles fine but the executable is broken as described above.
Before i made the update everything worked. So what goes wrong here?
Do you have the libstdc++-*.dll in the path? It may be shared in newer MinGW versions, and std::cout uses it.
A tool like Process Monitor will probably tell you what is actually going wrong in more detail, and possibly even tell you what you need to fix to make it work.