Note:
see: http://gcc.gnu.org/install/configure.html
------------------------------------------------------------------------------
--enable-gnu-unique-object
Tells GCC to use the gnu_unique_object relocation for C++ template static data
members and inline function local statics. Enabled by default for a native
toolchain with an assembler that accepts it and GLIBC 2.11 or above, otherwise
disabled.
------------------------------------------------------------------------------
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.