Closed ojwb closed 1 year ago
I believe this is no longer a problem with HEAD, and indeed it would seem that configuring/building it with at least MinGW 64-bit (the non UCRT version, albeit all other flavors should work the same) creates a working pcre2posix_test.exe
which is even good enough to pass make check
In any case, including config.h in pcre2posix_test is not right because that program is a client program that should not make any use of internal pcre2 information. That was the whole point of creating that test.
I hit with the mingw32 (what was known as "mingw dot org" but they managed to let the domain lapse). I realise this isn't nearly as well maintained, but people do still seem to use it for some reason (I've had bug reports for build failures on it this year). I also saw this with MSVC, but it seemed more helpful to show the problem with non-proprietary tools.
I was using the latest release - will try to reproduce with HEAD.
I was using the latest release - will try to reproduce with HEAD
It is a known bug (since 10.41), as seen in #243
If I make dist
from HEAD and use the resulting tarball then I don't get the failure, so this is indeed already fixed (presumably by #243 but I've not tried without that change to actually confirm). Sorry for the noise.
Without this, linking fails on mingw when configured with --disable-shared because PCRE2_STATIC doesn't get defined, leading to pcre2posix.h incorrectly enabling use of __declspec(dllimport). The errors look like:
c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: src/pcre2posix_test-pcre2posix_test.o:pcre2posix_test.c:(.text.startup+0x6f): undefined reference to `_imp__pcre2_regcomp'