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.]
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.
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 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 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.
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 :)