VOGONS

Common searches


Broken executables with MinGW-w64 (GZDoom)

Topic actions

Reply 60 of 65, by dondiego

User metadata
Rank Member
Rank
Member

I dunno but this is not a thread_local crash, still crashed without thread_local. And there was another crash on exit before in the GL renderer. Seems there's some kind of race condition with destructors.
Also when i restored the low detail modes in LE (BTW 3x2 is not working 100%) some small levels with tall skies which apparently loaded too fast crashed and skies were screwed anyway (i fixed that later).
On an Athlon XP 2400+ GZDoom didn't crash on exit in the VM so may be cpu speed has something to do with it (i remember that setting video mode pressing enter twice issue on pentiums). So it seems MinGW has problems with multithreaded applications.
BTW have you tried CLang? There's a version for windows.

LZDoom, ZDoom32, ZDoom LE
RUDE (Doom)
Romero's Heresy II (Heretic)

Reply 61 of 65, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

I haven't tried CLang before, although I think that the libc++ code is worthwhile to test with gzdoom. Either way, it seems that you resolved all known issues by thoughtful commits in gzdoom.

Reply 62 of 65, by dondiego

User metadata
Rank Member
Rank
Member

I think i've addressed the issues in my legacy branch but i should do a PR to keep GZDoom compatible and hacks won't be accepted there.
CLang is supposed to be compatible with gcc but requires the MinGW libraries and C runtime so i don't think it would be any better.
http://www.malsmith.net/blog/clang-system-req … ements-windows/

LZDoom, ZDoom32, ZDoom LE
RUDE (Doom)
Romero's Heresy II (Heretic)

Reply 63 of 65, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

Nice work. Your project built without issue.

As an aside, I had an issue linking a COFF object file in the DJGPP/DOS environment. It showed a linker error while building it into a DXE. The error was about "multiple sections". I think that the DXE file supports only one section for .data, .text, and .bss. It also doesn't allow for a .rdata section. Once the assembly file was fixed in this way, then the object file built into a DXE.

Reply 64 of 65, by dondiego

User metadata
Rank Member
Rank
Member

Thanks, this was going to be an official legacy build but it has been rejected for reasons. So i've changed the name to LZDoom and plan to do a release very soon. For now there's a pirated version @DRD Team devbuilds that i will delete soon, please don't tell anyone. 😵
The MinGW non SSE2 version there is bad, somehow i compiled with SSE2.
Now i'm also working on another official legacy build for 3.5.

BTW i released another source port here, seems it went unnoticed:
RUDE: new Doom sourceport

LZDoom, ZDoom32, ZDoom LE
RUDE (Doom)
Romero's Heresy II (Heretic)

Reply 65 of 65, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

I look forward to the release of LZDoom, although I will try the insider's preview devbuild first. 😀

The other source port looks interesting since it is closest to vanilla Doom behavior along with support for popular wads that go beyond vanilla limits. I assume its single threaded except for its audio system which may not be?

I have been testing Intel's TBB threading library, version 4.3-6/11/2015, in mingw32. It seems like a useful library to test against, but it doesn't appear to support an older OS. Some have referred to these as dinosaurs, so I can imagine what sort of creature a Commodore Amiga is.