This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Trouble building gcc-3.4.0 cygwin->linux
- From: Dan Kegel <dank at kegel dot com>
- To: "Gerrit P. Haase" <gp at familiehaase dot de>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 07 Jun 2004 17:01:25 -0700
- Subject: Re: Trouble building gcc-3.4.0 cygwin->linux
- References: <40820717.9060101@kegel.com> <20040418052643.GB22865@lucon.org> <4082A322.7070904@kegel.com> <20040418183933.GA14303@lucon.org> <40831CB0.4030407@kegel.com> <40C37214.1040003@kegel.com> <405171228.20040607212527@familiehaase.de>
Gerrit P. Haase wrote:
.../crosstool-0.28-rc5/build/i686-unknown-linux-gnu/gcc-3.4.0-20040416-glibc-2.1.3/gcc-3.4.0-20040416/configure
--target=i686-unknown-linux-gnu --host=i686-host_pc-cygwin
Isn't the correct host name for Cygwin i686-pc-cygwin?
Yes. However, the 2nd field (manufacturer, I think) of the gnu machine tuple
is checked by very few tools, and I have hijacked it to compensate
for the lack of a "this is a cross compiler, goddammit" flag in autoconf.
In other words, I make the build, host, and target identifiers unique
by appending _build and _host to the build and host identifiers' manufacturer field.
It's a nasty trick, but until autoconf and all the apps that use it
have some other way of forcing cross-compilation, I'm stuck with it.
In any case, that's not the problem; the problem was the bug in method.c,
which I have a workaround for.
- Dan
--
My technical stuff: http://kegel.com
My politics: see http://www.misleader.org for examples of why I'm for regime change