Cross-compiling gcc? (sysroot confusion)

[Pierre Ossman]

Hi,

I'm trying to cross-compile gcc (rather than just creating a
cross-compiling gcc), and I'm not getting a clear picture of how all
the configure flags interact. Rather than spending countless hours with
the trial-and-error approach I'd figured I'd ask for help. :)

In short, what I'd like to achieve is to have a /sysroot that I can
chroot into and have a fully functional gcc. I have a working method
for that, but it's very convoluted and high-maintenance. There must be
a simpler way. This is my current theorised plan on how to reach that:

(Note that I'm currently using gcc 4.5.4. I'm planning on an upgrade
but I'd rather deal with one thing at a time.)

1. Start with a system that already has a working gcc. RHEL 7 is what
   I'm using at the moment.

2. Build my own binutils:

   ./configure --target=i686-pc-linux-gnu --prefix=/bootstrap
               --disable-shared --disable-nls --disable-multilib

   I figured it's best to let gcc use the same binutils for the
   initial steps as it will have inside the chroot.

   host and target might be the same, but might differ (32 vs 64 bit).
   I'm not sure if this will confuse some sysroot behaviour.

3. Build my own gmp, mpfr and mpc with --prefix=/bootstrap

4. Build a simple gcc in order to compile the start files for glibc:

   export PATH=/bootstrap/bin:$PATH
   ./configure --target=i686-pc-linux-gnu --prefix=/bootstrap
               --with-gmp=/bootstrap --with-mpfr=... --with-mpc=...
               --with-sysroot=/sysroot
               --disable-multilib --disable-lto --enable-shared
               --enable-threads=posix
               --without-headers
               --enable-languages=c

5. Install kernel headers in /sysroot/usr/include.

6. Build glibc headers and start files:

   export PATH=/bootstrap/bin:$PATH
   ./configure --host=i686-pc-linux-gnu --prefix=/usr
               --disable-profile --enable-add-ons --enable-kernel=2.4.0
   make csu/subdir_lib
   make install-headers install_root=/sysroot
   mkdir /sysroot/usr/lib
   cp csu/crt1.o csu/crti.o csu/crtn.o /sysroot/usr/lib

7. Remove the earlier gcc and binutils.

8. Build binutils again, but with --with-sysroot:   

   ./configure --target=i686-pc-linux-gnu --prefix=/bootstrap
               --with-sysroot=/sysroot
               --disable-shared --disable-nls --disable-multilib

   I'm not sure if this step is necessary. Maybe gcc always overrides
   any sysroot setting compiled into binutils?

9. Build gcc again:

   export PATH=/bootstrap/bin:$PATH
   ./configure --target=i686-pc-linux-gnu --prefix=/bootstrap
               --with-gmp=/bootstrap --with-mpfr=... --with-mpc=...
               --with-sysroot=/sysroot
               --disable-multilib --disable-lto --enable-shared
               --enable-threads=posix
               --enable-__cxa_atexit
               --enable-languages=c,c++

10. Build glibc completely:

   export PATH=/bootstrap/bin:$PATH
   ./configure --host=i686-pc-linux-gnu --prefix=/usr
               --disable-profile --enable-add-ons --enable-kernel=2.4.0
   make
   make install DESTDIR=/sysroot


At this point I should have a fully functional cross compiler from the
local Linux system to that in /sysroot. I'll use that to populate it
with various tools such as bash and make. The problem is gcc. Is it
clever enough to pick up everything it needs from the compiler in step
9, or do I need to tell it things. I.e. should I just do:

   export PATH=/bootstrap/bin:$PATH
   ./configure --host=i686-pc-linux-gnu --prefix=/usr
               --disable-multilib --disable-lto --enable-shared
               --enable-threads=posix
               --enable-__cxa_atexit
               --enable-languages=c,c++
   make
   make install DESTDIR=/sysroot

Or do I need some creative combination of --with-sysroot,
--with-build-sysroot, --with-build-sysroot,
--with-native-system-header-dir, etc.?

I've read what I can find about these flags, and I'm not understanding
then sufficiently to make the answer obvious. Help and feedback much
appreciated. :)

Rgds
-- 
Pierre Ossman           Software Development
Cendio AB		http://cendio.com
Teknikringen 8		http://twitter.com/ThinLinc
583 30 Linköping	http://facebook.com/ThinLinc
Phone: +46-13-214600	http://plus.google.com/112509906846170010689

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-help/attachments/20141031/66df5ce8/attachment.sig>