VOGONS


First post, by Mortifere

User metadata
Rank Newbie
Rank
Newbie

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.

Has anybody been able to compile with gcc 4.7.0?

Any help would be highly appreciated.

Thank you.

Reply 1 of 14, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

this came up on irc as well. Think the solution was to build it with gcc 4.6.2 or gcc 4.7.1 (at least that version was tested on linux)

Water flows down the stream
How to ask questions the smart way!

Reply 2 of 14, by Mortifere

User metadata
Rank Newbie
Rank
Newbie

Thanks for the tip. I've downgraded from 4.7.0 to 4.6.2 and I am now able to produce an executable that works.

If anybody is intrested, this is what I've done on my environment:

1) remove gcc 4.7.0
mingw-get remove gcc
2) install gcc 4.6.2
mingw-get install gcc=4.6.2-1
3) remove g++ 4.7.0
mingw-get remove g++
4) install g++ 4.6.2
mingw-get install g++=4.6.2-1

After that I recompiled everything and once I place the files in the appropriate directory the resulting exe now works.

Good times!

Reply 3 of 14, by onigame

User metadata
Rank Newbie
Rank
Newbie

I tried to do this and the resulting executable kept on failing.

Eventually I figured out what was going on. Not only do you need to copy the DOSBOX.EXE executable, but you need to make sure the Dosbox directory has the correct gcc DLL files.

Specifically, I needed to copy libgcc_s_dw2-1.dll and libstdc++-6.dll from your MinGW/bin directory to my Dosbox directory. Posting this here in case anyone else has the same problem.

Reply 4 of 14, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

Bring the thread back into dev attention.

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.

Reply 5 of 14, by truth_deleted

User metadata

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!).

Lastly, there are many Win32/VS developers in this community.

Reply 6 of 14, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

I had built SDL, SDL_net and SDL_sound with MinGW and I had no issue with the builds. I am not sure about OHQ addition into SDL. Does OHQ mean OpenGL HQ? My SDL does not have such enhancement.

It is frustrating and discouraging to see open-sourced projects leaning towards propriety tool chain, especially Visual Studio, for their Win32/Windows builds.

Reply 7 of 14, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator
kjliew wrote:

It is frustrating and discouraging to see open-sourced projects leaning towards propriety tool chain, especially Visual Studio, for their Win32/Windows builds.

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

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 8 of 14, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 9 of 14, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

Solved.

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!!!

Reply 10 of 14, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

the __attribute__(packed) is supposed to do that for GCC (at least that is why we added it). Did GCC change something or did we miss on a few fields ?

Water flows down the stream
How to ask questions the smart way!

Reply 12 of 14, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991

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.

Reply 13 of 14, by truth_deleted

User metadata

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.

Attachments

  • Filename
    DOSBox_MinGW.zip
    File size
    1.39 MiB
    Downloads
    642 downloads
    File comment
    DOSBox-SVN+SDL by mingw/gcc4.8.1
    File license
    Fair use/fair dealing exception

Reply 14 of 14, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

configure.ac has been updated to include this -mno-ms-bitfields flag by default.

Water flows down the stream
How to ask questions the smart way!