Note:
This update is disabling a powerpc related patch that we might can remove later.
Seems that the issue this patch addressed is fixed upstream now!
Note:
The authors of ppl advise the user to use '-fexceptions'.
configure output of the ppl package:
----------------------------------------------------------------------------
configure: WARNING: CANNOT PROPAGATE EXCEPTIONS BACK FROM GMP:
*** MEMORY EXHAUSTION MAY RESULT IN ABRUPT TERMINATION.
*** This is OK, if you do not plan to use the bounded memory capabilities
*** offered by the PPL. Otherwise, if you are using GCC or the Intel C/C++
*** compiler, please make sure you use a version of GMP compiled with the
*** `-fexceptions' compiler option.
*** To build such a version, you can configure GMP as follows:
*** CPPFLAGS=-fexceptions ./configure --enable-cxx --prefix=/usr/local
----------------------------------------------------------------------------
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
Christian Wiese
Alejandro Mery
Alejandro Mery
Nagy Karoly Gabriel