build-djgpp.sh failed on MSYS2/MINGW64/UCRT64

[Hatsum]

Hello,

I'm trying to build djgpp with the build-djgpp.sh on MSYS2 (whether environment MINGW64 or UCRT64), however I have the following error:

../../gnu/gcc-12.2.0/gcc/system.h:782:30: error: expected identifier before string constant
  782 | #define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__)
      |                              ^~~~~~~~
../../gnu/gcc-12.2.0/gcc/system.h:782:30: error: expected ',' or '...' before string constant
../../gnu/gcc-12.2.0/gcc/system.h:782:30: error: expected identifier before string constant
  782 | #define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__)
      |                              ^~~~~~~~
../../gnu/gcc-12.2.0/gcc/system.h:782:30: error: expected ',' or '...' before string constant
make[1]: *** [Makefile:1144: prefix.o] Error 1

I found this post on stackoverflow.
It seems that after a Mingw-w64 update, "you should always #define WIN32_LEAN_AND_MEAN before calling #include <windows.h>".
You can already found this patch (already pushed on the gcc repository) but I don't know if it works as is on the gcc version 12.2.0.

[jwt27]

Thanks for reporting!

Maybe a simple fix is to add -DWIN32_LEAN_AND_MEAN in $CXXFLAGS. Could you try that? I can't update my mingw-w64 right now since my Windows machine is still running Win7.

If it doesn't work I'll backport and include the patch you linked.

[Hatsum]

It works. Thanks :)

[jwt27]

Nice, thanks for confirming!

[RobertSundling]

I can't seem to compile on 64-bit Windows (via mingw-w64/msys2) with WIN32_LEAN_AND_MEAN defined (with the command ./build-djgpp.sh gcc-12.2.0).

The problem seems to be with a single file, build/binutils-2.41/ld/ldbuildid.c, for which the compiler emits hundreds of errors about "RPC" constants being missing and make terminates. It looks like that file uses a Microsoft Windows RPC library to generate GUIDs, and the RPC stuff may be omitted with WIN32_LEAN_AND_MEAN defined.

I temporarily added the line #undef WIN32_LEAN_AND_MEAN at the top of my local copy of build/binutils-2.41/ld/ldbuildid.c and was able to (seemingly) build everything successfully. Not sure how to make that into a patch or even if that's the right way to fix it.

[jwt27]

Ah, well, it was a bit of a hack anyway. But worth a try.

I suppose the only "correct" solution is to backport that patch from gcc 14. I'd just have to do it for each gcc version supported by these scripts (that's 31 times). Easier option, but still a hack, is to add the macro in CXXFLAGS only while compiling gcc.

Will look into it tomorrow.

[jwt27]

I went with the easy option. The patch didn't apply to gcc 12 already, and it got progressively worse after that. This should work now.

[RobertSundling]

Seems good enough. It works, so why make things overly complicated?

[jwt27]

Agree, there's nothing wrong with this approach now. Possible concern is that in the future, gcc may need stuff from windows.h that this macro hides, like binutils does now. Then it gets a bit tricky. But we'll cross that bridge when we get there :)