[Top][All Lists]
[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