Sadness. After some reboots, things just started working. So no idea what was wrong...
MinGW *.exe not a valid win32 application
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).
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 :)
MinGW is not a great out-of-the-box tool chain for sure :)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
