bug-libsigsegv
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-libsigsegv] mingw failure


From: Eric Blake
Subject: Re: [bug-libsigsegv] mingw failure
Date: Tue, 23 Aug 2011 16:40:19 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.11

On 08/23/2011 04:19 PM, Sam Steingold wrote:

so it can infer the compiler name - which does not have to be gcc - from
the host/build arguments (BTW, build argument should not be needed -
that's the host on which configure is running) but not vice versa.
this is weird.

There are several things at play in configure arguments:

1. --host is necessary for cross-compiles; otherwise it defaults to --build. It says what the end-result host will be for the just-built binaries.

2. --build is optional for any build, but for cross-compiles, explicitly setting it makes it obvious that you are doing a cross-compile. It should always be the current OS doing the build, as determined by config.guess, or something close enough to the current OS as to not be lying (the latter case is sometimes useful for forcing cross-compile logic using only native compilers, by doing something like --build=i386-pc-linux --host=i686-pc-linux).

3. --target is only for building cross toolchains (that is, specifying --target to gcc's configure script produces a gcc that is a binary for the --host platform, but produces executables for the --target platform); Canadian cross is when you specify --host and --target both different from --build. --target has no impact on libsigsegv, since it is not part of a toolchain for building cross executables.

4. Historically, in the dark ages of autotools, the dichotomy of build/host/target was confused, and did not always have the clean definitions it has now; therefore, configure scripts warn if you use --host but not --build under the assumption that you might have been expecting the old semantics where, for some packages, --host in isolation used to mean what --build means now. Note that it is only a warning, which is why I said --build is optional but recommended.


ac_cs_config="'--prefix=/cygdrive/c/sds/src/top-mingw' '--host=i686-pc-mingw32' 
'--build=i686-pc-mingw32' 'build_alias=i686-pc-mingw32' 'host_alias=i686-pc-mingw32'"

I see why "cross compiling... no" but I don't see how that could matter.

It matters because it's a lie. You are telling configure that "I'm a native mingw build, so you can just compile and run any program, and it will give you the correct answer for mingw"; except that you are running in a cygwin environment (which understands symlinks and such), but using a mingw cross-compiler (whose end executables do not understand cygwin), and getting some answers for a native cygwin build even though you were trying to do a cross build to mingw. You would get the same problem if you cross-compiled for mingw using a Linux cross-compiler in an environment where wine is installed.

If you want to do a native mingw build, then you have to have a native mingw toolchain, such as MSYS, where the environment that runs the compiler and the environment used by the test executables produced by that compiler are identical.


When I do:

$ ../configure --host=i686-w64-mingw32 --build=i686-pc-cygwin

Much better - this says that "I am on a cygwin machine, but I want to cross compile and produce native mingw executables". Most cross-compilation setups cannot run the just-built executables (cygwin and/or linux with wine being able to run mingw binaries is an exception to the general rule in cross-compilation), but the most important part to realize is that even if configure can run cross-built executables, it should not rely on them because the compilation environment differs from the running environment.

$ ../configure --host=i686-pc-mingw32 --build=i686-pc-cygwin 
--prefix=/cygdrive/c/sds/src/top-mingw
...
libsigsegv: i686-pc-mingw32 | yes | yes | 2.10

YAY!!!

Glad to hear it.

--
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org



reply via email to

[Prev in Thread] Current Thread [Next in Thread]