Note:
In my opinion it is perfectly safe to export CXX in toolchain stage because
I can see no reason why we can't assume that the build host has a properly
installed C++ compiler available.
Note:
The fixincludes script attempts to "fix" the system headers installed so far.
Since GCC is cross-compiled expecting the system headers to be in
/usr/include, the script will be looking at the host system's headers.
Note:
Without this patch a 'include-fixed' directory is created on install, where # the 'limits.h' and 'syslimits.h' header files get installed as following
flist output is demonstrating:
--------------------------------------------------------------------------
gcc: usr/lib/gcc/i686-unknown-linux-gnu/4.4.3/include-fixed
gcc: usr/lib/gcc/i686-unknown-linux-gnu/4.4.3/include-fixed/README
gcc: usr/lib/gcc/i686-unknown-linux-gnu/4.4.3/include-fixed/limits.h
gcc: usr/lib/gcc/i686-unknown-linux-gnu/4.4.3/include-fixed/syslimits.h
--------------------------------------------------------------------------
Note:
While trying to cross-compile a uclibc based target I experienced failing
configure tests for computing the suffix of object files.
In the respective config.log following error occured multiple times:
TOOLCHAIN/tools.cross/crosscc/../libexec/gcc/i686-unknown-linux-uclibc/4.4.3/cc1: error while loading shared libraries: libc.so.0: cannot open shared object file: No such file or directory
No matter if that problem occured only while building a uclibc target, it seems
to be a good idea to assure that we link against the right libc.
gcc 4.4 introduced configure options for arch, cpu and tune which influence
the default compiler settings on the final target machine.
Because we inject -m{arch,cpu,tune} through the gcc wrapper we now have to
provide the same settings through configure options, so the final user is
not running into problems like getting missing symbols for software
emulated facilities provided by the gcc support library.
Christian Wiese
Aldas Nabazas
Christian Wiese
Alejandro Mery
Christian Wiese