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