Just to confirm that mpc-1.2.0-rc1 seems fine on native Windows 7, building in the MSYS2 (bash) shell.
I did strike something that confuses me wrt shared library (dll) builds.
Being confused by shared library builds on Windows is nothing new to me - and that's' the reason I shun dlls in preference to static libraries.
My mpfr-4.1.0 and gmp-6.2.0 dlls are in C:/msys/1.0/local_dyn/bin.
Therefore, 'make check' requires that C:/msys/1.0/local/bin be in my PATH environment variable - because the test executables require that those 2 dlls be loaded.
Unfortunately, in the same folder there exists a libmpc-3.dll from a previous build of mpc-1.1.0.
Annoyingly, 'make check' insists on loading that pre-existing libmpc-3.dll instead of src/.libs/libmpc-3.dll -.even though.the (fully qualified) src/.libs directory occurs at the very beginning of the PATH.
With mpc-1.2.0 I'm finding that if I want 'make check' to succeed, then I first have to delete the pre-existing C:/msys/1.0/local_dyn/bin/libmpc-3.dll, otherwise tdiv.exe, tdot.exe & tpow.exe all fail, and ttan.exe hangs.
I thought I understood the method used by Windows 7 to determine which dll to load ... but apparently not.
It's probably a PEBCAK, but I cannot for the life of me work out why the mpc dll that occurs second in the PATH is being loaded instead of the mpc dll that occurs first.
Any thoughts on what I'm missing in trying to understand this weirdness ?
Configure command was:
$ ./configure --disable-static --enable-shared LDFLAGS=-L/C/msys/1.0/local_dyn/lib CPPFLAGS=-IC:/msys/1.0/local_dyn/include --prefix=C:/msys/1.0/local_dyn