Re: [Mingw-users] MinGW GCC 5.3.0 doesn't work on Windows XP
-----BEGIN PGP SIGNED MESSAGE-----
Apologies for joining this discussion belatedly; I've been on
vacation, away from both home and computer.
On 16/04/16 15:12, Eli Zaretskii wrote:
> I cannot compile any programs with this version of GCC on a Windows
> XP SP3 machine: cc1.exe pops up an error dialog saying "The
> procedure entry point strnlen could not be located in the dynamic
> link library msvcrt.dll".
Right; that's useful to know, thanks. You may note that I haven't yet
formally announced the release of GCC-5.3.0 -- nor have I attempted
any mingw-get integration -- because I had concerns that such issues
might arise. I definitely appreciate this sort of feedback from users
who are willing to experiment with such unannounced releases.
> Does this mean MinGW no longer supports Windows XP? I hope not.
Not by any intent of mine; I certainly hope to be able to continue to
support legacy Windows versions, for as long as remains practicable.
On 18/04/16 19:28, Eli Zaretskii wrote:
>> From: Earnie <earnie@xxxxxxxxxxxxxxxxxxxxx> This has been
>> discussed before, it will eventually happen. In this case I
>> believe that the issue is that the maintainer was using a more
>> recent Windows version to build the package
> I think you are right.
While that's a plausible assumption, on this occasion you're wrong; it
was I who built it, and I did so as a crossed-native build on my Linux
box, (and with _WIN32_WINNT left at its _WIN32_WINNT_WIN2K default).
The real issue here is that I used current mingw-wsl-legacy ex. git,
as my mingwrt, and that has strnlen() added to the exported symbols
list for MSVCRT.DLL, (to facilitate building Vista or later dependent
code, albeit with it's header visibility rigorously occluded when the
user has not set _WIN32_WINNT to accept the Vista or later
limitation). Unfortunately, that addition to MSVCRT.DEF makes the
strnlen() symbol visible to GCC's configure time tests, and those
tests aggressively disregard all version specific filters within the
header files, which becomes problematic in the case of symbols such as
strnlen(), which really should not be detected for the default build cas
I've already fixed one issue related to bogus detection of strnlen()
at configure time, in the build of libgfortran-5.3.0, (i.e. the
fortran support library for this very GCC release); at least _that_
build had the grace to die, when it didn't find the corresponding
function prototype at make time. Sadly, the cc1.exe build _didn't_
exhibit any similar failure, so it went unnoticed.
>> We need to create our own version of strnlen for libmingw32.a so
>> that it will always be present if you want to continue XP
>> support. This will be true for other functions that may now be
>> in MSVCRT.DLL that are not in the XP version.
A reference listing of all such functions may be found here:
I'm now using the same MSVCRT.DEF source to generate both this
document, and libmsvcrt.a; it already incorporates infrastructure to
suppress selected symbols from the latter, so the first step would be
to add strnlen() to the excluded list; we may also wish to consider
adding a corresponding __LIBIMPL__ definition to <string.h>, (although
the GCC build should be able to live without it).
> I agree. I hope a fixed binary distribution of GCC 5 will be
> available soon.
I'll follow this up, as my time permits; thanks for the heads-up.
Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
-----END PGP SIGNATURE-----
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
MinGW-users mailing list
This list observes the Etiquette found at
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.
You may change your MinGW Account Options or unsubscribe at: