VOGONS


First post, by Silanda

User metadata
Rank Member
Rank
Member

This is a bit strange. I decided to unify my build environment by building with MSYS2, which I use for other things, rather than the older MinGW environment. I've ran into a problem however: the executable that's produced works just fine, including screenshots and video capture, until I close Dosbox.

If I close it by typing "exit", everything's fine, but if I close it by clicking the X in the right corner, the program crashes rather than exiting cleanly. Oddly, this didn't seem to happen when I had a debugger attached, but debugging is not my forte. Builds without screenshot support don't have this issue.

This is on Windows 10, and Msys2 is using up to date versions of Zlib and libPNG as installed by pacman, although I did try to use the version of libPNG suggested in the MinGW build guide, with the same results.

Any suggestions would be appreciated.

Reply 1 of 11, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Check the guide in my signature on Google drive, I build working builds with that. I do remember having that issue once and it may be documented in the mess at the end of the guides that I haven't organized yet. sigh lazy me.

How To Ask Questions The Smart Way
Make your games work offline

Reply 2 of 11, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

I built my 32-bit DOSBox SVN r4160 with MSYS2/mingw-w64-i686, screenshot is enabled but not sure about video capture. It worked fine though. I hope you were actually building with mingw-w64-i686 instead of MSYS2. MSYS2 simply provides the POSIX shell environment, which means the EXE was not linked with msys-2.0.dll. I am on Windows 10, too, 64-bit Pro build 1803.

Reply 3 of 11, by Silanda

User metadata
Rank Member
Rank
Member

Thanks for the advice. Yeah, it's built with mingw-w64-i686. FWIW, it crashes silently and was only really noticeable through event viewer and the slight pause before the Window closed. 64-bit builds don't have this issue, but aren't really usable for my purposes with the dynarec core being broken on Windows.

Reply 4 of 11, by Silanda

User metadata
Rank Member
Rank
Member

Seem to have it working now. Cleaned out all traces of libpng, downloaded the source of the latest version rather than installing with Pacman, configured that with the --disable-shared flag as instructed in the MinGW guide, rebuilt Dosbox, and it works fine now.

Funny thing is that I could have sworn that I tried this before starting this thread.

Reply 5 of 11, by DosFreak

User metadata
Rank l33t++
Rank
l33t++
Silanda wrote:

Seem to have it working now. Cleaned out all traces of libpng, downloaded the source of the latest version rather than installing with Pacman, configured that with the --disable-shared flag as instructed in the MinGW guide, rebuilt Dosbox, and it works fine now.

Funny thing is that I could have sworn that I tried this before starting this thread.

Aha! Thanks for confirming that. I didn't mention it because I wasn't 100% but that makes sense.
I spent quite a bit of time banging my head against a wall create those guides so I know what you mean. Mostly due to by own ineptitude, mostly because I'm focusing on compatibility which most people don't care about and mostly because the tools in the Mingw w/ Msys ver are really out of date so alot of weird issues compiling. Hoping to get back to the guide soon.

How To Ask Questions The Smart Way
Make your games work offline

Reply 6 of 11, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
Silanda wrote:

Seem to have it working now. Cleaned out all traces of libpng, downloaded the source of the latest version rather than installing with Pacman, configured that with the --disable-shared flag as instructed in the MinGW guide, rebuilt Dosbox, and it works fine now.

Funny thing is that I could have sworn that I tried this before starting this thread.

There shouldn't be anything special to build a working DOSBox SVN using MSYS2/mingw-w64-i686. Libpng installed from pacman is fine. I prefer my build without any statically linked libraries. All dependencies should be dynamically linked with the DLLs. Every dependencies of DOSBox can be resolved through pacman. The only exception is SDL_sound, but it is not a mandatory dependency.

Even building SDL_sound from source is super simple because all its dependencies (ogg/vorbis, smpeg, mikmod, modplug, physfs etc.) can all be resolved through pacman.

With MSYS2/mingw-w64-i686, it should be as simple as:

 $ ./configure && make 

Reply 7 of 11, by Silanda

User metadata
Rank Member
Rank
Member

What should be happening and what I'm experiencing are two different things. No errors are thrown during configuration or compilation, and the builds produced are fully functional. The only problem I'm experiencing is the silent crash when closing the Window, rather than typing "exit", if libPNG is dynamically linked. I lack the knowledge to debug this, so I'll leave libPNG statically linked.

EDIT: Except, based on your suggestion, kjliew, now I've tried a build with everything dynamically linked, and it works too! I'm stepping away from this can of worms I think. I have no clue what's going on.

Reply 8 of 11, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
Silanda wrote:

The only problem I'm experiencing is the silent crash when closing the Window, rather than typing "exit"

I did check my Event logs and found none about any app crash. Perhaps you can provide yours to understand the cause.

Reply 10 of 11, by Silanda

User metadata
Rank Member
Rank
Member

I did a clean install of MSYS2 and the MinGW toolchain once the problem happened on my existing install. As for different switches, I was using "./configure --enable-core-inline LDFLAGS="-static-libgcc -static-libstdc++ -s" LIBS="-lvorbisfile -lvorbis -logg"", which works fine as long as libPNG is statically linked. This morning I used "./configure --enable-core-inline LDFLAGS="-s" LIBS="-lvorbisfile -lvorbis -logg"" along with libPNG installed through Pacman in order to create a fully dynamically linked build (which also works properly).

My event log produced this:

Log Name: Application
Source: Application Error
Date: 21/10/2018 21:50:56
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer: Chris-PC
Description:
Faulting application name: dosbox.exe, version: 0.74.0.0, time stamp: 0x5bcce673
Faulting module name: dosbox.exe, version: 0.74.0.0, time stamp: 0x5bcce673
Exception code: 0x40000015
Fault offset: 0x001af6da
Faulting process ID: 0x26f8
Faulting application start time: 0x01d4697fc2404083
Faulting application path: C:\Program Files (x86)\DOSBox-0.74\dosbox.exe
Faulting module path: C:\Program Files (x86)\DOSBox-0.74\dosbox.exe
Report ID: e5a09c8c-69fe-45a5-bd59-78e50b25bc62
Faulting package full name:
Faulting package-relative application ID:

Reply 11 of 11, by Silanda

User metadata
Rank Member
Rank
Member

Okay, I see what's going on now, though not why: If the exe is compiled with libGCC statically linked, it seems that libPNG must be statically linked too. The problem goes away when libGCC is dynamically linked.

AFAIK this doesn't happen with builds made with my old MinGW environment,