What is best recommended practice, to work around the issued described in this MinGW bug: https://sourceforge.net/p/mingw/bugs/2155/ ? In summary: building cross-gcc, all up to stage 1 compiler build is fine, but stage 2 cannot proceed until the host libraries are built. The stage 1 compiler should suffice to build these, but with current configure.ac, they need an already existing stage 2 compiler. I know there's the GCC_NO_EXECUTABLES macro, provided in the GCC sources themselves -- that's what mingwrt-3.x used -- or there's the even simpler hack of simply overriding _AC_COMPILER_EXEEXT. Either of these seems to work, but neither seems entirely satisfactory, (kludging around, as they do, with dependencies on undocumented autoconf internals). MinGW's old w32api-3.x used an alternative avoidance strategy -- using AC_CHECK_TOOL rather than AC_PROG_CC, to identify the compiler. This also has the desired effect -- and with no undocumented dependencies -- but then doesn't capitalize of other useful side effects of AC_PROG_CC. There seems to be no mention of this in the autoconf manual, beyond a comment confirming that AC_PROG_CC will fail if the compiler cannot successfully create executables. Googling turns up a significant number of relevant discussions, but there appears to be a deafening silence from the autoconf development community -- perhaps someone would care to remedy that omission? -- Regards, Keith. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
