thought dosbox was independed of that if you used the dosbox ./confgure (sets some flag)

Looking through google results it might be related to Qt, do you have that
installed or some stale references to that around?

Hmm, my mingw/msys build environment is not exactly clean. I don't *remember* having anything from Qt *ever* on my Windows and/or build environment, but since I also build Exult and Exult Studio I rely on a series of Gimp/GTK+ libraries as well. I don't know if these rely on some Qt stuff or if anything creeped in through that. I also found those references on google...
I only wonder how that would affect Dosbox compiling...
If it is a flag you can set with ./configure, I couldn't figure that out from --help...

All releases of dosbox are compiled with mingw as well and none depends on that dll

No dosbox doesn't need it, but if you have libs and stuff to be added to all
compilings you might end up linking that dll to everything.

Maybe start from scratch and only add what's needed 😀

Maybe start from scratch and only add what's needed

I hoped I could avoid that 😀

Well it's not that hard actually with that automated installer.

Well it's not that hard actually with that automated installer.

Yeah, only that the automated installer doesn't seem to use the newest packages, so you have to do it manually anyway... But I'm almost done now 😀

Just need to download a few packages and overwrite it. Good luck 😉

grrrrrr.... I give up 😀
I set up the build environment totally new and I get Dosbox, Exult, Pentagram to compile just fine... BUT Dosbox still has a dependency on that @&$% dll 🙁
I'm giving in.. whatever... since I don't give the compiled CVS out to anybody anyway it doesn't really matter (I just wanted to know how...).
Days of compiling and collecting binaries on the net wasted for nothing. Time to do something usefull and testdrive the CVS now 😀

(btw, time to change the titlebar name of the CVS something other than 0.72 or do you just don't care about this? 😀)

Try this: Topic 14743

Thanks MiniMax, SDL 1.2.13 compiled fine (except that the makefile.in patch failed) with this mingwport. But it didn't change the need of a fresh compiled Dosbox for mingwm10.dll 🙁

There's info on the web explaining that the dll is related to exception handling for threads. Compiling with the -mthreads option, which is supposed to be used with multi-threaded programs, is the most straightforward reason the dependency on the dll gets linked in. DOSBox is single-threaded, but has that compile option somehow made it into your environment?

Hm sdl is marked multi-threaded in their msvc project, but under mingw
i never had that problem Dominus describes (if it's bound to -mthreads).

Ok, I'm stupid 😀
To start my dosbox compile, I execute a bat file and I haven't looked at that. There are some optimizations in there that I used because it was discussed somehwere here (can't find that now...) and those include CXXFLAGS="-mthreads... I haven't looked at that in ages, so I didn't notice that and I had just copy/pasted that anyway since I am clueless (as proven here 😀).
Any other culprits I'm letting myself in with these flags?:
make CFLAGS="-O2 -march=pentium4 -pipe -fomit-frame-pointer -ffast-math -mfpmath=sse" CXXFLAGS="-fno-omit-frame-pointer -O2 -march=pentium4 -pipe -mfpmath=sse"

Any other culprits I'm letting myself in with these flags?:
make CFLAGS="-O2 -march=pentium4 -pipe -fomit-frame-pointer -ffast-math -mfpmath=sse" CXXFLAGS="-fno-omit-frame-pointer -O2 -march=pentium4 -pipe -mfpmath=sse"

-ffast-math is rather famously broken, and can result in all kinds of weirdness on floating point (which some DOS games do use, after all).

-mfpmath=sse is basically redundant to -march=pentium4 (if you select -march= gcc tries to do "the right thing" in terms of the processor type and picks the relevant features of the proc as available).

-Frob

ffast-math is rather famously broken

gcc version? reference?

Well, you could look at the fact that it's not turned on by default by GCC itself with any -O level, that it is inclusive of the "-funsafe-math-optimizations" setting (which name the GCC team picked deliberately), or that it is listed in the documentation of GCC itself to cause accuracy problems.

Then again there are various indications around that it can cause failures in both operation and compilation.

It's not like fast-math is "broken", but it causes a completely different math lib than default to be used, and one that is known (by design) to not be as accurate as the default float path. On Intel architectures where the floating point units are so hyper-optimized it would seem of questionable value to sacrifice potential compatibility for the feature - on ARM or something like that, sure, since float is going to be dog slow by comparison.

If you really want to know the subset of flags that can make a set of code be all that it can be under gcc, I'd run it through Acovea, although that's pretty exhaustive and you have to provide repeatable invariant examples for it to crunch on.

-Frob

Then again there are various indications around that it can cause failures in both operation and compilation.

But you did read the whole threads of the links you posted, didn't you?
At a quick glance, one is an alignment bug in gcc shown by adding ffastmath,
one is a testsuite(!) bug.

it is inclusive of the "-funsafe-math-optimizations" setting (which name the GCC team picked deliberately)

But you *do* understand what the unsafe part in that setting is, which is
quite obvious from the gcc docs:

it can result in incorrect output for programs which depend on an exact implementation of IEEE or ISO rules/specifications for math functions

it would seem of questionable value to sacrifice potential compatibility for the feature

Don't see anything that would reduce compatibility by using ffastmath, nor that
it's "famously broken".
But thank you for providing information. I won't argue that gcc's non-standard
flags are safe in general, but don't see a point in avoiding them judging the
available stuff.