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.
Related
I have a program that is written in C & C++ and I'm rewriting some parts to improve it. This program has to work with files, but I am not able to check if a file exists on Windows with a cross-compiled exe.
To check if my code was the problem, I have created this simple example:
#include <fstream>
#include <iostream>
int main(){
std::fstream in_file("test.noexists", std::ios::in|std::ios::binary);
if (in_file) {
std::cout << "File exists" << std::endl;
}
else {
std::cout << "File doesn't exists" << std::endl;
}
}
Compiling this code using "x86_64-w64-mingw32-g++", version 8.3-win32 on Debian 10, I'm unable to check if a file exists because it always returns "true". To verify it I have compiled the same program on Linux using g++, and on Windows using mingw64, and both were working so looks like a problem building the project on Debian 10 mingw32.
I don't know if my problem is a bug on Debian version or I am doing something wrong. Anyone knows anything about it?
The only difference I have seen between both, is the version (8.1 on Windows vs 8.3 on Debian), and of course the SO.
Thanks!.
EDIT:
I have upgraded to Debian 11 which has the x86_64-w64-mingw32-g++ v10 and same behavior. I forgot to say that I am using Debian 11 on WSL, not a real Debian distribution. I don't think it matters.
EDIT2:
I have already seen the suggested thread, but the problem is that I want to use streams to manage the files and the only option in that thread also fails. Using any of the other three ways will be like a hack that will not help too much. I think that is not the best way to check the file presence with another example, and then reopen the file later to work with it.
Is supposed that the fstream class have boolean conversion as I have read in several threads and that is why I'm using this example. The Linux version works perfectly, so the function is working as expected. The problem is the Windows version compiled in Linux (cross compiled EXE).
I have tested in_file.good(), in_file.is_open(), in_file.bad(), just in_file... all of them returns like the file was open correctly. Also I have tried ifstream, but same behaviour.
Rest a bit always helps... I have found a workaround to my problem just reading 0 bytes.
#include <fstream>
#include <iostream>
int main(){
std::fstream in_file("test.noexists", std::ios::in|std::ios::binary);
char dummy;
if (in_file.read(&dummy, 0)) {
std::cout << "File exists " << in_file.tellg() << std::endl;
}
else {
std::cout << "File doesn't exists" << std::endl;
}
}
With this, even the cross compiled EXE works without problems.
I still thinking why only fails with the cross compiled EXE, but I was not able to find any info about it and how to fix it. At least this solution is working.
Best regards.
I got an issue after installing Eclipse Kepler on my Windows 7 32bit machine. I installed the CDT and the MinGW-compiler. I configured the installation by adding MinGW to the PATH and tested my configuration with a "Hello world"-program, which worked.
The strange thing is, that if I instantiate an object, nothing is outputted. It doesn't matter if it's a std::string or a custom made class. If I instantiate it, nothing is outputted, even if it should be outputted before the instantiation. The exact same code works fine, if I compile it with cygwin gcc from command line. If I change the toolchain to cygwin gcc nothing changes (I've rebuild the program with "build all").
There is no error displayed and no problem listed.
Here's the minimal working example:
#include <iostream>
#include <string>
using namespace std;
class SayWorld{
public:
SayWorld(){
cout << "World!" << endl;
}
};
int main() {
//Only gets outputted, if the lines, that don't work are commented out:
cout << "Hello ";
// Works:
cout << "World!" << endl;
// Doesn't work:
// SayWorld sw;
// Also doesn't work:
// string str("World!");
// cout << str << endl;
return 0;
}
Edit 2:
I narrowed the error to MinGW, as this picture of a Cygwin-Bash-Terminal demonstrates. (The file was not changed beetween the to g++ calls and contains the example above)
Edit 1 (Legacy)
Toolchain-picture:
-picture removed- (don't think it was necessary)
After reinstalling eclipse and MinGW again, step-by-step following this video tutorial:
http://www.youtube.com/watch?v=77xZOT3xer4
and having the same problem afterwards, I stumbled uppon this post in the eclipse forum:
http://www.eclipse.org/forums/index.php/u/104305/
which has brought me to this solution:
Right-click Project -> Properties -> Run/Debug Settings
Choose executable and hit the "New"-button.
Go to the Environment-Tab and create a new variable named PATH with the value: "C:\MinGW\bin".
As I am no expert, I can't explain to you why it works, but it worked for me. If someone knows, how to do this better or wholly avoid this problem, I'd be glad to listen.
This entry was definitively in my Windows-PATH...
PS.: The problem seems also to be known here:
unable to see the output of c++ program in the console
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.]
This code:
#include <iostream>
using namespace std;
int main()
{
cout << "Hello world!\n";
return 0;
}
when comiled give size 457KB in Code::Blocks with GCC 4.4.1 and only 8KB (eight) in VS2010. Both compilers optimized for size.
Anyone knows why such a difference?
This is due to the c++ standard library being linked statically by g++, whereas VS will link it dynamically. A quick check using gcc under cygwin gives me approximately same sizes, and the resulting exe only import some C functions.
#include <stdio.h>
int main() {
printf("Hello world\n");
return 0
}
On the other hand, this application compiled to the same minimal EXE under gcc, as it does not require any c++ functionality.
You are right, the executable by gcc is obviously larger, in your case 57 times larger than that built by vc++.
The main reason is the one made with
GCC won't require any external
dependencies to run while the one made
with VS2010 would need at least its runtime
files to be present on the system.
For instance, say you try it on some friend's computer with no vs2010 installed, rather try earlier OS like XP with no chance of having VS2010 runtimes even.
The one built with GCC will have no problems while the one made with VS2010 would throw an error of missing runtime file ( dependency ).
Hope this helped, if it didn't or you have any other question in your mind, feel free to ask and I'll be glad to help :)