This is the mail archive of the
mailing list for the GCC project.
Re: Standardized instructions for cross-compiling toolchain?
- From: Pip Cet <pipcet at gmail dot com>
- To: Andrew Haley <aph at redhat dot com>
- Cc: Michael Habibi <mikehabibi at gmail dot com>, gcc-help at gcc dot gnu dot org
- Date: Thu, 5 May 2016 15:25:35 +0000
- Subject: Re: Standardized instructions for cross-compiling toolchain?
- Authentication-results: sourceware.org; auth=none
- References: <CAOsp8o-fVfAjgez9ttRw0+ckm+MKOomAXnwURcGmCV+AsMX=oA at mail dot gmail dot com> <572A2247 dot 2020003 at redhat dot com>
On 5/4/16, Andrew Haley <firstname.lastname@example.org> wrote:
> On 05/04/2016 05:12 PM, Michael Habibi wrote:
>> However, my question is more general than that. Are there some
>> widely-used, accepted steps for building a cross-compiling toolchain
>> with gcc? I noticed that crosstool-ng does a 3 stage build, where it
>> builds an initial gcc for libc start files, then rebuilds gcc for
>> libc, then rebuilds gcc yet again with libc. Other blogs suggest that
>> two stages are enough. I settled on doing a 2 stage build. I think my
>> steps are fine, but I think some of my configure options may need help
>> (prefix vs sysroot vs prefix+target, etc). But every set of
>> instructions I look at are different, and it seems no two blog posts,
>> pdfs, wikis have landed on the same procedure.
> That's the hard way. The easy way is to grab the root filesystem from
> your target machine and configure --with-sysroot=<target filesystem>.
> You really don't have to build libc for your target, and if your
> target already exists and has a libc you should not do so.
But what if it doesn't? As long as the ABI hasn't been finalized, it
seems to me the only way to move forward is to rebuild gcc, glibc, and
binutils in lockstep. "The hard way" isn't impossible to figure out,
but having a canonical set of instructions would have helped. (The
different interpretation of --prefix, at least, is something that
My point is that probably every port to be written from scratch will
have a phase where the hard way is required, so why not document at
least one way of doing it and put it on the GCC Wiki? Jeff recently
> IIRC, the right way to do this is to first use glibc's install-headers target to get the header files installed, then you can build gcc.
...which suggests there is a right way to do things the hard way (and
also that this is an issue that pops up at least occasionally).
There might also be legal reasons for being absolutely sure that only
the source code, and nothing out of a third party's binary
distribution, went into the build process. Whether it's actually any
cleaner to build from scratch rather than using an existing distro is
probably a philosophical matter, since the result should be the same.
(I'm working on a GCC asm.js backend. Probably unwisely, I started out
emulating the Emscripten "ABI", and changing it gradually to be more
normal, which required many cycles of rebuilding glibc and gcc.)