Resulting binaries like libstdc++.so will end up having an rpath with an
absolute path to the build sandbox set in the elf headers.
This issue was discovered when trying to run a cross-compiled lftp which
was cross-compiled against musl libc and segfaulted when being executed.
Removing the explicit rpath seems to solve the runtime issue because lftp
is not segfaulting anymore and works as expected.
Note:
This reverts the changes done by following commit:
-----------------------------------------------------------------------------
commit 041df7170f
Author: Christian Wiese <chris@opensde.org>
AuthorDate: Mon Aug 6 23:56:15 2012 +0200
Commit: Christian Wiese <chris@opensde.org>
CommitDate: Tue Oct 23 00:25:40 2012 +0200
gcc: changed to set locations of build prerequisites in all stages instead of toolchain stage only
-----------------------------------------------------------------------------
which badly broke the cross-build of gcc when using uclibc!
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:
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.
default in native stage and not in cross stage and introduced a
Config option to enable it explicitely (default 0)
Note:
This option is useful if multiple versions of gcc are build which
is not the case right now!
git-svn-id: svn://svn.opensde.net/opensde/package/trunk@20308 10447126-35f2-4685-b0cf-6dd780d3921f
by default and introduced a Config option to enable it explicitely
Note:
Disabling PCH in libstdc++ the gcc package becomes 3 times smaller!
git-svn-id: svn://svn.opensde.net/opensde/package/trunk@20307 10447126-35f2-4685-b0cf-6dd780d3921f
Christian Wiese
Aldas Nabazas
Christian Wiese
Alejandro Mery
Christian Wiese
Minto van der Sluis