ct-ng x86_64-host, but want ia32 binaries
Yann E. MORIN
Thu Jan 29 18:32:00 GMT 2009
On Thursday 29 January 2009 17:27:48 Doug Reiland wrote:
> I want to produce a cross-compiler that executes on a ia32 host and
> produces ia32/i686 binaries
> I want to produce another cross-compiler that executes on a ia32 host and
> produces x86_64 binaries.
> The bad thing is I am being the cross-compilers on a x86_64 system.
If I get it right you want for the first compiler:
build : x86_64
host : x86
and for the second one:
build : x86_64
host : x86
For the first compiler, this is what crosstool-NG calls a cross-native
compiler, eg, a compiler that generates code for the machine it is run on
(hence the "native" part), but the compiler itself was cross-built (hence
the "cross" part). As build != host, you first need a x-compiler that is
able to do build --> host, and then you can build your cross-native.
The second compiler is indeed a canadian-cross, really, as build != host !=
target, even if build == target, that does not count. For this, you need two
pre-existing compilers, one that does build --> host, and one that does
build --> target (which in this case is the native one).
Unfortunately, crosstool-NG does not (yet) support these combinations.
Currently, you have to have build == host. I'm planning to have
at least the canadian case work, but I need to setup host and target
systems first, which will have to wait a little bit, as I have another
project on the table...
> The reason is I am sharing these cross-compilers across different
> development servers and I cannot be certain that they are all x86_64
That is not at par with your first paragraph, where you state that both
compilers would run on x86, but would generate code for either x86 or
So where's the truth? :-)
Note, to be sure we speak the same language :-)
- "build" is the machine where the toolchain is _built_
- "host" is the machine where the toolchain _runs_
- "target" is the machine the toolchain _generates_code_ for
- "target" is only meaningfull for those components generating or
interpreting code (such as binutils, gcc, gdb); others (such as
GMP, C library) have no notion of target.
> I know this is a special case that can't be generically coded for in the
It should be. Let's find a way, _if_there's_need_to_.
> Note, I am testing a build now that just might work. I had to force:
> CT_CFLAGS_FOR_HOST=-m32 in crosstool.NG.sh
[--SNIP see below--]--
> If this works, maybe we can expose these variables cooresponding .in
> files so they can be controlled via menuconfig.
I'm not in favor of blindly setting such flags. This would bite back when
we eventually code the native/cross-native/canadian cases.
Eventually, CT_CFLAGS_FOR_HOST shoud be constructed from internal settings,
augmented with user-defined settings (that would indeed come from .in files)
> ABI=32 in gmp.sh
What is "ABI"? A GMP-specific variable?
This should be set conditionnally to the host tuple, that is 64 bit hosts
should get ABI=64, while 32-bit hosts get ABI=32.
But doing so means that the GMP ./configure is somehow broken, if it can't
see what the word-size for host is (for GMP, there's no target, only build
In the hope I've been clear enough... :-)
Yann E. MORIN.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software Designer | \ / CAMPAIGN | ___ |
| --==< ^_^ >==-- `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
For unsubscribe information see http://sourceware.org/lists.html#faq
More information about the crossgcc