--- Begin Message ---
Subject: |
27.0.50; 32-bit build of master failing with MSYS2 |
Date: |
Wed, 24 Apr 2019 09:28:50 +0200 |
Trying a 32-bit MSYS2 build of master on Windows 10 configured with
CFLAGS='-O3' gets me here:
w32.o:w32.c:(.text+0xa29f): undefined reference to `_imp___futime32'
collect2.exe: error: ld returned 1 exit status
make[1]: *** [Makefile:643: temacs.exe] Fehler 1
make[1]: Verzeichnis „/c/emacs/trunk/opt-32/src“ wird verlassen
make: *** [Makefile:423: src] Fehler 2
A build configured with CFLAGS='-O0 -g3' proceeds without problems.
The 32-builds use gcc 7.4.0. 64-bit builds with the same options
proceed without problems using gcc 8.3.0.
A workaround here is to add a check to mingw_time.h like
/* The @#$%^&! MinGW developers stopped updating the values of
__MINGW32_VERSION, __MINGW32_MAJOR_VERSION, and
__MINGW32_MINOR_VERSION values in v4.x of the runtime, to
"discourage its uses". So the values of those macros can no longer
be trusted, and we need the workaround below, to have a single set
of macros we can trust. (The .17 minor version is arbitrary.) */
#ifdef __MINGW32__
#include <_mingw.h>
# ifndef __CRT__NO_INLINE
# define __CRT__NO_INLINE
# endif
#endif
martin
--- End Message ---
--- Begin Message ---
Subject: |
Re: bug#35410: 27.0.50; 32-bit build of master failing with MSYS2 |
Date: |
Wed, 9 Oct 2019 20:11:38 +0200 |
> > Hmm, I tried updating, but now my mingw32 gcc is 9.1.0, and it still
> > builds fine. I'm not sure if it's practical to support old compiler
> > versions from a rolling release.
>
> The problem is not with the compiler version per se but with the
> headers shipped with MinGW64. So hopefully they fixed that problem in
> our sense in the meantime. I'm reluctant to update as well because
> the 64-bit builds work sufficiently well and updating always bears the
> risk spoiling that. I filed the report only to hear opinions from
> other MinGW64 users but apparently neither of them uses my version.
I now upgraded MSYS2 to its present version and it builds fine so I'm
hopefully closing this bug.
Thanks for the heads-up, martin
--- End Message ---