ct-ng x86_64-host, but want ia32 binaries

[Yann E. MORIN]

Doug,
All,

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
  target: x86
and for the second one:
  build : x86_64
  host  : x86
  target: x86_64

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
> servers.

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
x86_64. :-/

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
> scripts.

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
and host).

In the hope I've been clear enough... :-)

Regards,
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