This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Standardized instructions for cross-compiling toolchain?


On 5/4/16, Andrew Haley <aph@redhat.com> 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
surprised me.)

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
commented (https://gcc.gnu.org/ml/gcc-help/2016-03/msg00105.html)
that:

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

Pip Cet


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]