MinGW *.exe not a valid win32 application

On a side note, I just downloaded Visual Studio 2010 so eclipse would "just work." It doesn't. It seems while I was working with libraries and Java and the web and stuff, C++ by hand because something that a new programmer can't do anymore, which is kind of sad.

Can you share the corrupt exe file?

Which MinGW version are you using? I'm using TDM-GCC 4.8.1 with Eclipse Luna (before that with Kepler and Juno) and never had any problem like that.

I have the same version. Just downloaded it on Friday. I am also using the newest Eclipse (Luna).

This can happen if you've accidentally targeted a different architecture from the one you're running, so give the project settings a check. You could be building a 64-bit binary and then trying to run it on a 32-bit copy of Windows, as an example.

This can happen if you've accidentally targeted a different architecture from the one you're running, so give the project settings a check. You could be building a 64-bit binary and then trying to run it on a 32-bit copy of Windows, as an example.

I'm on windows 7, so there should be no problem running either 32 or 64 bit apps. I have been trying to find a setup for teaching C++ that could use as many of the same tools as possible but still allow for Mac, Widows, or Linux. I settled on Eclipse, but I had hoped installing and configuring the libraries and tool chains would be easier.

What happens if you compile hello world from the command line using MinGW? At least that should tell you if the problem is the compiler or the IDE.

Put hello.cpp in a directory, command just g++ hello.cpp, then run a.out.

(This assumes your bin and include directories are set up by default, may not be the case if you have only used it via the IDE)

I've not had this problem with MinGW myself.

What happens if you compile hello world from the command line using MinGW? At least that should tell you if the problem is the compiler or the IDE.

This was my thought for a next step. I'll try it tonight. I suspect I did something weird when installing it. It seemed like a lot places to go wrong are built into the installer.

This can happen if you've accidentally targeted a different architecture from the one you're running, so give the project settings a check. You could be building a 64-bit binary and then trying to run it on a 32-bit copy of Windows, as an example.

I'm on windows 7, so there should be no problem running either 32 or 64 bit apps. I have been trying to find a setup for teaching C++ that could use as many of the same tools as possible but still allow for Mac, Widows, or Linux. I settled on Eclipse, but I had hoped installing and configuring the libraries and tool chains would be easier.

Windows 7 has both 32-bit and 64-bit editions. Definitely find out for sure which you're using!

http://windows.microsoft.com/en-us/windows7/find-out-32-or-64-bit

Sadness. After some reboots, things just started working. So no idea what was wrong...

When in doubt, reboot. Then reboot again.

Nice to hear it's working now, at least :)

There was still some weirdness with -staticlib preprocessor flags, but it worked.

There was still some weirdness with -staticlib preprocessor flags, but it worked.

Not too sure what -staticlib would have to do with the preprocessor, could you elaborate? I'd expect -staticlib to be a linker command to build a lib file rather than an exe, although I thought for MingW that was just -static?

There was still some weirdness with -staticlib preprocessor flags, but it worked.

Not too sure what -staticlib would have to do with the preprocessor, could you elaborate? I'd expect -staticlib to be a linker command to build a lib file rather than an exe, although I thought for MingW that was just -static?

So after I installed Visual Studio 2010 Express and rebooted, I fired Eclipse back up to try and use that. Just for fun, I tried the MinGW *.exe again. This time there was no error. But nothing happened. No error, no "Hello World!" output in the console, nothing.

Navigating to the Debug folder and running the exe by hand gave this error:

"The program can't start because libgcc_s_dw2-1.dll is missing from your computer."

I had to add "-static-libgcc -static-libstdc++" to the linker flags to get it working...

Well, the alternative would have been to add libgcc_s_dw2-1.dll next to the created application or put it into the path.

The same goes for MSVC as well: you need to add/install the runtime DLLs (unless you compile with /MT instead of the default /MD), otherwise the program won't work. The difference is, the runtime will be in the path by default on development machines (but often not an the average user's). That's why you see those "I gave my program to a friend and he cannot use it"-threads every now and again.

Switching to static linkage for the runtime is obviously an option, but has ramifications: for example it can cause severe problems when you need to dynamically link C++ libraries which require you to pass ownership of objects over the DLL boundary (like for example Qt).

Ah, linker not preprocessor. Makes sense.

MinGW is not a great out-of-the-box tool chain for sure :)