Keith Marshall
keith****@users*****
Mon Jul 2 01:20:19 JST 2018
On 28/06/18 14:02, Eli Zaretskii wrote: >> From: Keith Marshall <keith****@users*****> >> Date: Thu, 28 Jun 2018 08:50:12 +0100 >> >> Well, I too have forgotten most of what I did for the gcc-6.3.0-mingw32 >> distribution, but that's where a good source code management system, >> (one with good patch queue management, in particular), comes into its >> own; for example, with Mercurial, I can readily see: > > Btw, as long as we are discussing this: any chance of having MinGW > GCC 7.x some time soon? If it's left to me to produce it, then the answer's "not very likely". Sorry, but I just don't have the willpower to contend with crap such as: cc -nostdinc -x c /dev/null -S -o /dev/null -fself-test=../../src/gcc-7.3.0/gcc/testsuite/selftests cc: error: unrecognized command line option ‘-fself-test=../../src/gcc-7.3.0/gcc/testsuite/selftests’ make[2]: *** [s-selftest] Error 1 rm gfortran.pod gcc.pod make[2]: Leaving directory `/home/keith/src/mingw/gcc-build/ gcc-7.3.0-mingw32-cross-native/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/home/keith/src/mingw/gcc-build/ gcc-7.3.0-mingw32-cross-native' make: *** [all] Error 2 Given that 'cc' is: $ cc --version cc (Debian 4.8.2-1) 4.8.2 Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. while 'gcc' (just built by 'make bootstrap-lean') is: $ gcc --version gcc (GCC) 7.3.0 Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. and the cross-compiler it *should* be using (also just built) is: $ mingw32-gcc --version mingw32-gcc (GCC) 7.3.0 Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Given that the top level configure script correctly identifies the mingw32-gcc cross-compiler suite, it simply beggars belief that the GCC build process is then using the ancient Debian host 'cc'; even if the native compiler is appropriate, in this context, surely the more recent 'gcc' replacement would be the appropriate choice? But, even if that is so, in that particular context, it gets even worse! If I help it out with that choice, (by creating 'cc' as a link to that newer 'gcc'), then libgcc's configure script seems to think that 'cc' is the appropriate choice for building 'mingw32' host code; from its config.log: configure:2450: checking for a BSD-compatible install configure:2518: result: /usr/bin/install -c configure:2534: checking for gawk configure:2561: result: gawk configure:2661: checking for mingw32-ar configure:2688: result: ar Wrong! mingw32-ar is right there in $PATH; configure should have found, and selected it! configure:2753: checking for mingw32-lipo configure:2780: result: lipo configure:2845: checking for mingw32-nm configure:2872: result: nm Wrong again! mingw32-nm is available, and should have been selected. configure:2937: checking for mingw32-ranlib configure:2964: result: ranlib Similarly, wrong again! configure:3029: checking for mingw32-strip configure:3056: result: strip And, wrong again! configure:3118: checking whether ln -s works configure:3122: result: yes configure:3139: checking for mingw32-gcc configure:3166: result: cc -L/... And this is the real killer: mingw32-gcc is the *only* viable choice here, and configure *should* have found and selected it. The actual choice of the native 'cc', irrespective of the following (elided) library path hints, has absolutely no hope of doing anything useful! The top level configure script got this right, so it's inexcusable that the sub-configure for libgcc should get it so hideously wrong. With gcc-6.3.0, once I'd worked out the mingw32 cross-compiler build, the subsequent cross-native build for mingw32 itself just fell into place; not so for gcc-7.3.0, which seems to be an utter TARFUBAR, to which I am reluctant to devote any more time! -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature Url : https://lists.osdn.me/mailman/archives/mingw-users/attachments/20180701/def5e7e5/attachment.pgp
Fork