ct-ng x86_64-host, but want ia32 binaries

Doug Reiland dreiland@hotmail.com
Thu Jan 29 19:17:00 GMT 2009

> From: yann.morin.1998@anciens.enib.fr
> To: crossgcc@sourceware.org
> Subject: Re: ct-ng x86_64-host, but want ia32 binaries
> Date: Thu, 29 Jan 2009 19:32:02 +0100
> CC: dreiland@hotmail.com
> 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
Yes, this is what I need
> 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...
I understand. I was hoping others have done something like this since is x86_64 has -m32.

>> 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? :-)

Maybe I said it wrong. I can't depend on actual "host" system being x86_64 so I want host=ia32(i386/i686..). If the actual host system is x86_64 or ia32 the binaries will still work.
> 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).
First, I nothing of GMP, and I should test attempting to do a build without it. It is the one thing that broke when I forced -m32 during the configure step and the error messages directed me to it's ABI environment variable.

> 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. |
> `------------------------------^-------^------------------^--------------------'
Windows Live™ Hotmail®…more than just e-mail. 

For unsubscribe information see http://sourceware.org/lists.html#faq

More information about the crossgcc mailing list