Stefano Lattarini skrev 2012-01-20 15:02: > Hi Peter. > > On 01/20/2012 12:56 PM, Peter Rosin wrote: >> Stefano Lattarini skrev 2012-01-19 14:55: >> >> [MEGA-SNIP] >> >>> +# Prefer generic compilers to GNU ones when possible. This will ensure >>> +# more testsuite coverage "in the wild". >>> +# FIXME: maybe we should a more comprehensive list too look for more >>> +# FIXME: "exotic" compilers? And what about looking also for the MSVC >>> +# FIXME: compiler on Cygwin/MinGW systems? >>> +_AM_COMPILER_CAN_FAIL([AC_PROG_CC([cc gcc])], [CC=false]) >> >> Looking for MSVC on Cygwin is a definite no, IMHO. MSVC can't produce >> Cygwin programs (I have never heard of it anyway, maybe with -nodefaultlib >> and adding a bunch of low level cygwin stuff instead, but I highly doubt >> it will fly), so it can only be viewed as a cross compiler in that >> setting. IOW, the same as looking for it on Linux with Wine/binfmt-misc... >> BTW, that's a good starting point for how Cygwin should be viewed when it >> comes to build systems; as Linux with Wine and binfmt-misc set up to >> handle PE stuff. >> >> MinGW is another matter... >> > Thanks for the detailed information. I'll adjust the FIXME comment > accordingly. > >>> + >>> +# The list of C++ compilers here has been copied, pasted and edited >>> +# from `lib/autoconf/c.m4:AC_PROG_CXX' in the Autoconf distribution. >>> +# Keep it in sync, or better again, find out a way to avoid this code >>> +# duplication. >>> +_AM_COMPILER_CAN_FAIL([AC_PROG_CXX(dnl >>> + [aCC CC cl.exe FCC KCC RCC xlC_r xlC c++ cxx cc++ gpp g++])], >>> + [CXX=false]) >> >> I suppose it can be a problem that cl.exe is before g++ on Cygwin or Linux >> with Wine/binfmt-misc and if MSVC is installed (and visible), when cl.exe >> is best viewed as a cross compiler in those cases. >> > Are you afraid that configure will, in such a setup, automatically (and > erroneously) determine that we are *not* cross compiling, while in fact > we are? If yes, I agree that would be problematic. Maybe we could (in > a follow-up patch) avoid looking for cl.exe if we determine the current > build system is Cygwin? Ugly, but easy to do (and also correct, I hope).
No, that's not what I'm afraid of. I'm afraid, when $host == $build, that configure will think that cl.exe is a native compiler. I mean, it's not as if it's named i686-pc-mingw32-cl.exe just because you are in a Cygwin shell, and when it is on PATH in a Cygwin setting it will produce executables that run, and I fear that configure will think the compiler is fine. So, I'm not afraid that the cross-or-not heuristic will come up with the wrong answer. I'm afraid that CC will point to a cross compiler in a native build, which would be surprising when gcc is on PATH, and probably even before cl. I believe the correct thing to do is to only look for cl when $host is the system cl produces code for. But that's very difficult, as there are cl:s that produce code for other arches (x64, Itanium). But since I think it's too hard to do this right, I don't think we should even try. But I also think that we should only look for cl if we have failed to find gcc/g++, that way we avoid that particular can of worms in the vast majority of cases. Perhaps it's as simple as moving cl.exe over to the end? >> But I usually don't >> source my script that adds MSVC to PATH and sets up various other bits >> needed in the environment when in Cygwin, so cl.exe isn't normally on my >> PATH so it wouldn't be a problem *for me*. But I think there is an option >> to add MSVC to the "global" environment though, and if that has been done, >> it might not be so easy to avoid finding MSVC from Cygwin. >> > So the hack I have proposed above might be necessary after all. Damn. > > I will await confirmation from you that I have inderstood the situation > correctly, before proceeding to write a patch. Ok. Cheers, Peter
