I am running on Windows 7. I downloaded and installed MinGW and MSYS, which contains gcc 4.7.0, downloaded and compiled SDL-1.2.15 without errors, downloaded and compiled SDL_net-1.2.8 without errors, downloaded, extracted and compiled dosboxsvn.tgz. Everything seemed to work right. I copied the resulting dosbox.exe, SDL.dll and SDL_net.dll to a directory with a recent dosbox installation and ran dosbox. It seemed to run fine except issuing a mount command would either 1) not do anything for a while, then the prompt would come back without the command having done anything or 2) dosbox would exit with the following message: Exit to error Illegal GRP4 call 5. Then I noticed other commands would exit the same way.

I followed the wiki page titled "BuildingDOSBox" carefully. Since I am not getting any errors while compiling any of the libraries I'm not sure where the problem lies. The only deviation from the wiki page was statically linking the C libraries so I wouldn't have to copy them as well.

Is there a plan to understand the problem with compiling with MinGW gcc > 4.6.2? Both gcc 4.7.2 and 4.8.1 have been released for MinGW/MSYS and I had tried both and they both produce non-functional DOSBox binary. I have been building DOSBox from source since the 0.6x era and would very much like to continue using the cutting edge GNU tool chain to build it.

I also use several open-sourced projects to qualify the sanity of MinGW/MSYS build environment whenever there is an update to the GNU tool chain. It's been working very well so far and it is sad to see DOSBox away from keeping up with latest GNU tool chain.

MinGW is not fully POSIX compliant and has a defect in compiling SDL+OHQ code. There was also a report, from my recollection, that it has problems compiling MT32 code. However, VS (or a typical, modern Linux) has no problems with this code. From some exploration, I suspect that the threading libraries in MinGW are not yet robust for compiling the OHQ code, in particular.

Even so, I typically compile dosbox with MinGW+GCC 4.6.2 and SDL with VS; however, I wonder whether there is enough interest to port and test all code in the MinGW environment, and even less for verifying a dosbox build via the newer GCC versions (+ libraries!).

The releases are cross compiled from linux and there are no official SVN builts so, no, THIS project is not leaning towards proprietary tool chains for its Windows builds.

Also this error might be due to "unclean" environment. If any of the binaries is linking to a dll that was built with pre 4.7 gcc then something like that is likely to happen. From what I read in varios discussions on irc

I am wondering if building DOSBox with gcc 4.7.3 or gcc 4.8.1 under Linux/x86 (not x64) is producing a working native binary. I don't have any Linux distro with such recent GNU tool chain available at my disposal to try this out, as my primary machine is still Win7. And, I am not in a mood to build gcc from source on my Linux machine just to see if that works. Hopefully, someone will try it out and share his/her findings.

GCC versions 4.7.0 and 4.7.1 had changes to the C++ standard library which affected the ABI in C++11 mode: a data member was added to std::list changing its size and altering the definitions of some member functions, and std::pair's move constructor was non-trivial which altered the calling convention for functions with std::pair arguments or return types. The ABI incompatibilities have been fixed for GCC version 4.7.2 but as a result C++11 code compiled with GCC 4.7.0 or 4.7.1 may be incompatible with C++11 code compiled with different GCC versions and with C++98/C++03 code compiled with any version.

I am aware of the above GCC ABI change since 4.7.2 as both MinGW release and GNU gcc release note have explicitly highlight it. However, I have tried rebuilding all external DLLs used by DOSBox but to no avail. And I have no clue what else I should rebuild with new gcc > 4.7.2.

QEMU, another my favorite open-sourced project which also requires SDL, works fine with MinGW gcc 4.7.2 using SDL library built with older MinGW gcc 4.6.2. However, I noticed that QEMU does not link with C++ standard library, but DOSBox does.

The problem was caused by gcc 4.7.0 and above turning ON -mms-bitfields by default, but in dosbox source files the #pragma pack(1) is only applicable to MSVC. So to build dosbox SVN without changing any of the source files, it needs to be configure with CXXFLAGS="-mno-ms-bitfield .... "

With this change, MinGW gcc 4.8.1 is producing working dosbox binary from SVN. Yay!!!

I recall that gcc 4.7.x is building a working dosbox-SVN in Linux. There are also outside posts about mingw gcc mirroring the behavior of VS; therefore, I believe this problem is mingw/gcc specific, and other gcc environments are not mirroring VS behavior.

Yes, -mms-bitfields is only turned on by default for Windows mingw targets. However, this exposes a bug since gcc 4.2.0 that __attribute__(packed) is broken with -mms-bitfields.

I can't understand what state of mind GCC dev team is in when it is OK to enable -mms-bitfields by default, ignoring the many open-sourced projects that have long been building codes using gcc specific directives and ported to Windows, thanks to MinGW/Cygwin port of gcc. I am not against GCC efforts towards binary compatibility with MSVC, but they could have at least fixed the bug before enabling -mms-bitfields by default.

Thank you, kjliew, for the hint to compile dosbox-SVN by the newer mingw/gcc versions (gcc >=4.7.0). I had unsuccessfully tried this a few months ago and, with your hint, now have working binaries. The hint was to add "-mno-ms-bitfields" to CXXFLAGS while running configure. Attached are DOSBox-SVN+OHQ, C/C++ runtimes, SDL.dll, and SDL_net.dll, all compiled by the newest MinGW build + gcc4.8.1. To enable OHQ mode, pair dosbox.exe with a SDL.dll+OHQ generated by VS (available from OpenGL-HQ web page).

By artificial (pcpbench) and real game (quake1 timedemo) benchmarks, this mingw/gcc4.8.1 dosbox build has the same speed (in fps) as the older mingw build by gcc4.6.2 (/O2 in both cases). This result was verified under the dynamic and the normal core. However, the newer mingw builds presumably compile code faster and provide bug fixes. OHQ is still problematic in this newer mingw/gcc environment, likely an unfixed bug in its threading libraries (causes use of OHQ fallback renderer). For the other patches, I assume that they will work as in previous mingw builds.

One unresolved issue with this mingw version is the inability to statically link the C/C++ runtime libraries with the executable, at least by the method used in previous versions. There are other internet posts about this minor issue.

This dosbox-SVN build is (theoretically) well optimized for speed and compatibility across windows platforms. It may be worth testing against other builds in terms of emulation speed.