-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24/08/18 09:23, Sébastien Hinderer wrote: > Keith Marshall (2018/08/23 20:00 +0100): >> For --build, the output from config.guess should always be >> suitable; for --host, it may be okay to affix an arbitrary >> suffix to mingw32, such as (untested [*]) --host=mingw32cl >> CC=cl.exe, (and any other explicit tool identification >> assignments which may be required). > > But why would you include a "mingw" string in something that does > not use mingw at all? Because it's an OS name already known to config.sub, and because it's an OS designator which is specific to native MS-Windows software builds, (but see below). Also, "MinGW" is a contraction of "Minimalist GNU for Windows", and you are using at least one GNU tool (autoconf) in your build process. > Isn't that a bit confising? Perhaps not to anyone who understands the "MinGW" concept, but again, see below. >> You could possibly also use AS_IF, or AS_CASE, in configure.ac or >> a user written macro included by configure.ac, to test >> $host_alias for your specific modified host identifier, and make >> a conditional assignment of CC=cl.exe and so on, within the >> generated configure script itself. > > Ah I quite like this idea, thanks! Let's see whether it's doable! > :) It is: $ cat configure.ac AC_INIT AC_CANONICAL_SYSTEM AS_CASE([$host_alias],[*mingw32cl],[CC=cl.exe]) AC_PROG_CC $ autoconf $ ./configure --build=`./config.guess` --host=i386-pc-mingw32cl checking build system type... x86_64-unknown-linux-gnu checking host system type... i386-pc-mingw32cl checking target system type... i386-pc-mingw32cl checking for i386-pc-mingw32cl-gcc... cl.exe checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... yes checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether cl.exe accepts -g... yes checking for cl.exe option to accept ISO C89... none needed Note that I've run this on GNU/Linux, so cl.exe doesn't really exist; I've kludged it as a hard link to gcc. >> [*] Note that I've explicitly avoided "mingw32msvc" as a host >> identifier in this example, because some GNU/Linux distributors >> have adopted that, (inappropriately, IMO), to designate their >> mingw32 cross-compiler tool chains. > > The choice looks unfortunate to me, too. It's a really terrible idea. I believe that their idea is to indicate that the generated code depends on MSVCRT.DLL, (which is distributed with Windows itself -- not with MSVC); this would be credible, if they called it "mingw32msvcrt", but they don't! "mingw32msvc" implies a dependency on MSVC -- the Microsoft Visual-C compiler -- which is 100% bullshit; there is no such dependency. > Okay so as far as msvc is concerned, on 32bits I am able to run > configure with: > > ./configure --build=i686-pc-cygwin --host=i686-pc-windows CC=cl > > (what matters here is --build and --host), the assignment to CC > could indeed go away if it becomes host-based. Okay. I wasn't aware that config.sub already understands "windows", (and indeed, it even understands an arbitrary suffix appended to "windows", provided there's no hyphen within it). If you are happy to interpret "--host=windows", (or any canonical triplet which ends with "-windows"), to implicitly require cl.exe, then you could adapt: AS_CASE([$host_alias],[*windows | *mingw*cl],[CC=cl.exe]) or otherwise, you could qualify it: AS_CASE([$host_alias],[*windowsmsvc | *mingw*cl],[CC=cl.exe]) > For the 64 bits architecture, it seems the followingworks: > > ./configure --build=x86_64-unknown-cygwin --host=x86_64-pc-windows > CC=cl This should also work, with any of the preceding adaptations. > Do you guys think I can proceed with these values for build and > host? I don't see why not; you've nothing to lose by trying. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJbf9TTAAoJEMCtNsY0flo/Bg4P/jbKi8Pg1jrIUWPcSMI+BxxP 3i3aQDsj7vRwtidEepYl4V2WVvOkTfXb+oHW02dQ//9PIzbND8TRqZbztD12cfRn wVp7UA3uGRocCeVa54HoDzgb4wfi2fYgoHZP4MkmyeOfW2gXD2VmSOWYOiuHXDGk TyR7PLC2yfxzaoJoK2OzeIWK0qjAWFeLrDJRL9XBwD+HHelW9ciZbA2qvLzyCpvo GklwsVNqPZcKlGGNYCQ6890ck1s/ZcapS6QkljkBTQ80sNTOQoMzNdfxCrTKUgME 07X0QZkGikW07IBVE0QD51Rz9dYl59hbxvX/WU7Ct7IdsiGfh5pF/wJgX/2fNgET hJNqZuWiZX6Z6rPJLR8T9nJ8221igOUUz59ARnHo6rHJS4CsCTjzzS5gmJt2SHit 9yKKQ4+tYS9V8ZhO+MOoCQfM0EjC6VjPVGfb/j46kYRCxK/qJTc770Vdwepketee I+dC/y27ZzpIqoMaSiJQTsPwURTs+bgNCI1bsKEeITfbIAABsWA2hv9ywKvsMi6i lAUel8fuDrHHMfwKU5XYWzvDyMnaTuO8xPbsncI+97Sgnc8Zzr1+dCSS2Ukc/iqn TADQK/QnPy0guxy4JGdFP3yh9xEfkoJbOQ4vv0FhSExwestV9iQAFML4xO39ZEjJ ng6AoynCDuQio8t8e8j3 =ObUU -----END PGP SIGNATURE----- _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
