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!
New gas requires sign extention in lea instruction. This resolves md5-x86_64.pl
and sha1-x86_64.pl bugs, but without modifying the code. PR: 2094,2095
http://cvs.openssl.org/chngview?cn=18869
Fix for out range of signed 32bit displacement error on newer binutils in file
sha1-x86_64.pl.
http://cvs.openssl.org/chngview?cn=18864
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.