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.
Christian Wiese
Christian Wiese
Alejandro Mery
Alejandro Mery
Nagy Karoly Gabriel