On 2015-08-09 21:26, fabrizio...@tiscali.it wrote: > The output of uname -o is indeed the same in MSYS2 and MinGW/MSYS > > Msys > > However, that is irrelevant because, config.guess does not use uname -o, it > does uname -s > > UNAME_SYSTEM=`(uname -s) 2>/dev/null` || UNAME_SYSTEM=unknown > > The output of uname -s is different between MSYS2 and the old MinGW/MSYS, and > that's the reason why config.guess (at least the latest versions of it) > returns something different between MSYS2 and the old MinGW/MSYS. So the > patch is ultimately necessary
But the problem is that msys 1.0 uses the envvar MSYSTEM to control the output of uname -s, and traditionally it is set to "msys" when building tools for msys 1.0, and to "mingw" in the normal end-user use case where you want MSVCRT instead of the msys C library. I have the feeling that this patch tramples on this aspect of the original msys (1.0). Which is not nice... Since the patch changes branches that were formerly mingw but not cygwin, I guess that the patch is aiming for changing the case where msys is used in its normal use case targeting MSVCRT. If I have assumed wrong here, then the patch is clearly suspect. But why would you want to change the host-triplet from mingw* to msys* in the case that my assuption is correct? That would break a lot of packages that has already been ported to mingw, no? When you cross-compile from linux using a mingw toolchain, you still use a mingw* host-triplet, why you you want to wander away from that when you use the mingw toolchain from msys2? So, the patch is suspect even if my above assumption is correct. Cheers, Peter _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
