mercredi 16 décembre 2015

Compiling new GCC on Unix

I want to update the GCC on an old embedded system running Debian 6. The embedded system is a Debian 6, single core, RT linux 3.6.11 with custom modules in the kernel, i486.

The development environment we use, runs on CentOS 6.6 2.6.32-504.1.3.el6.i686.

I'm trying to understand the intricacies of the process, but I'm far from it.

IDEAL Situation: cross compiler In the ideal situation I would have a proven cross compiler and I could cross compile the new compiler. Unfortunately this is not the case.

SECOND BEST: chroot, does it work? The second best I can think of is a chroot, which I have. My doubts raise because of the fact that anything is running on a different kernel. And this is what makes it really difficult for me to understand: if I load my kernel and my system with my library, and then restrict a shell to a certain root, anything executed is still calling my kernel and my system (up to a certain point) right? So how can I be sure that what I do in the chroot will actually work?

ACTUAL Solution: run a VM of the system and compile there This is what I am doing, and it kinda works but the bootstrap process runs into a lot of errors. Something I do not understand how to analyze let alone fix. It originally has gcc 4.4.5

Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-targets=all --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-8)

I used this to build 4.9.2

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i486-linux-gnu/4.9.2/lto-wrapper
Target: i486-linux-gnu
Configured with: ../configure --enable-languages=c,c++ --program-suffix=-4.9.2 --enable-shared --enable-linker-build-id --with-system-zlib --without-included-gettext --enable-threads=posix --enable-nls --enable-clocale=gnu --with-tune=generic --with-default-libstdcxx-abi=gcc4-compatible --enable-checking=release --with-arch=i386 --prefix=/usr/local --libdir=/usr/local/lib --host=i486-linux-gnu --target=i486-linux-gnu --build=i486-linux-gnu --enable-obj-gc --enable-multiarch
Thread model: posix
gcc version 4.9.2 (GCC) 

With 4.9.2 I then build 5.2. In the 5.2 folder I put

  • binutils-2.25
  • gmp
  • mpc
  • mpfr

This is my configuration script

../configure
--enable-languages=c,c++
--program-suffix=-5.2
--enable-shared
--enable-linker-build-id
--with-system-zlib
--without-included-gettext
--enable-threads=posix
--enable-nls
--enable-clocale=gnu
--with-tune=generic
--with-default-libstdcxx-abi=gcc4-compatible
--enable-checking=release
--with-arch=i386
--prefix=/usr/local
--libdir=/usr/local/lib
--host=i486-linux-gnu
--target=i486-linux-gnu
--build=i486-linux-gnu
--enable-obj-gc
--enable-multiarch
--enable-bootstrap

Compiling succeeds but testing doesn't with lots of failures. gcc/testsuite/gcc/gcc.log

                === gcc Summary ===

# of expected passes            62026
# of unexpected failures        256
# of expected failures          40
# of unresolved testcases       220
# of unsupported tests          256

How can I make sure this toolchain is reliable? How can I improve the workflow? How can I determine exactly what is needed to achieve what? For example I am incredibly muddy as to how to setup (build) the cross-compiling toolchain.

Aucun commentaire:

Enregistrer un commentaire