Spaces in arguments to the core gcc backend were not handled.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
(transplanted from 7cce5c8fc79a62bca1e448fc721e7209ac85d204)
That option is coming from the original crosstool, and is not entirely
understand here.
Moreover, it breaks with newer gcc-s: 4.6.1 now breaks while configuring
libjava (and probably some other libs as well, untested).
There is an related bug report to the gcc BZ:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49555
If need be, the old behavior can be restored with:
CC_CORE_EXTRA_CONFIG_ARRAY="--enable-symver=gnu"
CC_EXTRA_CONFIG_ARRAY="--enable-symver=gnu"
Reported-by: Bryan Hundven <bryanhundven@gmail.com>
Reviewed-by: Bryan Hundven <bryanhundven@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
(transplanted from b24ead1a59472195f5b2071ff70664c36fa21c3f)
Fixes the issue with {e,}glibc addons having short and long names (such as
eglibc-ports-2_13 and ports), which caused configure scripts to run
through them twice and thus configuring incorrectly.
For instance, the mips64el-n32-linux-gnu toolchain would be recognized
correctly first, but then the second pass would change it to mips32,
building a mixed MIPS-III N32 and MIPS-I libc.
Signed-off-by: Nicolás Reynolds <fauno@kiwwwi.com.ar>
[yann.morin.1992@anciens.enib.fr: remove spurious trailing spaces]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
(transplanted from af25723a794f2017f45c300369a6d36849e22236)
This patch sets the runtime sysroot to fix the following GDB warning:
"Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code."
The sysroot can later be changed within gdb with the `set sysroot`
command if necessary.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
(transplanted from 7690196856ce4a4700d1887cc3adf80acc627c52)
By default, PPL wants to build interfaces for any of a variety of
langauges it finds on the local host (python, java, possibly perl, also
more esoteric languages such as ocaml and prolog).
These extra interfaces can double the compile time for the library. For
single-process builds, I found a savings of more than 40%:
default / j1: 716s total, 143.2s avg, 0.52s stdev
just_c / j1: 406s total, 81.2s avg, 0.33s stdev
just_c_cpp / j1: 413s total, 82.6s avg, 0.22s stdev
And for multi-process builds, it approached 50%:
default / j4: 625s total, 125.0s avg, 0.57s stdev
just_c / j4: 338s total, 67.6s avg, 1.25s stdev
just_c_cpp / j4: 327s total, 65.4s avg, 0.36s stdev
Since the PPL we build within ct-ng is only used by GCC, we only need to
build the C and C++ interfaces.
Signed-Off-By: Anthony Foiani <anthony.foiani@gmail.com>
(transplanted from ec30b191f0e3fe9bc73199f0bcb8d789db17aa92)
'configure' for PPL 0.11 (and later) needs "--with-gmp-prefix" to
provide the location of the GMP toolkit; the previous switches were
"--with-libgmp-prefix" and "--with-libgmpxx-prefix".
The upstream log message is:
commit 08dfb6fea094f8c5a533575a3ea2095edce99a6d
Author: Roberto Bagnara <bagnara@cs.unipr.it>
Date: Sun Jul 12 21:39:46 2009 +0200
New configure option --with-gmp-prefix supersedes the (now removed)
options --with-libgmp-prefix and --with-libgmpxx-prefix.
Link: http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git;a=commit;h=08dfb6fea094f8c5a533575a3ea2095edce99a6d
Since PPL's 'configure' ignores unknown switches, we use all three so we
don't have to conditionalize the ppl.sh build script itself.
Signed-Off-By: Anthony Foiani <anthony.foiani@gmail.com>
(transplanted from 4f0c4fb572e2862c24b28e8d27ce7e9cb9adba65)
Fix typo introduced by changeset #055e505f28be.
Also, handle older versions of gcc (typically, all versions
prior to 4.0.0).
Maxime provided a similar patch, missing the case for the
legacy versions of gcc.
Reported-by: Maxime Bizon <mbizon@freebox.fr>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
(transplanted from 539a3fa894f00888b02c7f89a2046f02c9d51e75)
We can't run the newly built gcc when it is a canadian cross.
Thus, we can't get the version number, and thus we can't get
the directory libexec subdirectory to strip.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
gcc installs the C++ headers in ${PREFIX}/include/ but we trash
that directory at the end of the build.
We previously removed that directory as it contained the companion
libraries header files. But it's been some time now that we isntall
the companion libraries in their own dedicated place, so we do not
need to remove that directory.
Until we have a better fix, just keep that directory for now.
Reported-by: Bob Rossi <bob@brasko.net>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Managing the shared version of the companion libraries
has become cumbersome.
Also, it will one day be possible to use the companion
libraries from the host distribution, and then we will
be able to easily use either shared or static libs.
As a side note, while working on the canadian-rework
series, it has become quite more complex to properly
handle shared companion libraries, as they need to be
built both for the build and gost systems. That's not
easy to handle. At all.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
gold is not capable of building glibc/eglibc, so we have to
force using the BFD linker, ld.bfd.
Offer a blind option that affected components can select to
force use of the BFD linker during the build.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Add support for building SPARC targeted toolchain.
With this patch I have built a working sparc V8 (32 toolchain).
Testing shows that not all gcc versions works well:
4.4.1 OK (kernel builds and the final kernel can boot)
4.4.2 Not tested
4.4.3 Not tested
4.4.4 BAD (Kernel can build but fails during boot)
4.4.5 BAD (Kernel can build but fails during boot)
4.5.1 BAD (Build fails with a spill related ICE - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35664)
4.5.2 OK (kernel builds and boots)
I have successfully been using the 4.5.2 version for a few months.
This patch does not add support for the LEON variant.
That may come later.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
[yann.morin.1998@anciens.enib.fr: for 32-bit, default CT_TARGET_ARCH is OK]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
PPL 0.11+ installs three libs: lippl, libppl_c and libpwl.
libppl_c has a dependency on libpwl (at least for watchdog stuff).
While gcc correctly links with libppl and libppl_c, it does not
pull libpwl in. In case of shared libs, this is not a problem, as
libppl_c has a NEEDED dependency on libpwl. But for static libs,
that does not work. Although libppl_c.la exists and has a correct
dependency on lipwl, somehow gcc misses it. So we have to force
pulling libpwl when needed.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
There was a mishap when cut-n-pasting code from the final
step into the core step: a variable was not renamed.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Some scripts have 'very long lines', so the output of 'file'
will have that mentioned, such as:
POSIX shell script, ASCII text executable, with very long lines
Reported-by: Kyle Grieb <grieb.kyle@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The heuristic to find shell script is deficient. Fix it.
Reported-by: Kyle Grieb <grieb.kyle@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Building the start files requires a shared-capable compiler, which we do
not have when the threading implementation is LinuxThreads.
So, only build the start files when the threading implementations is NPTL.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
By default, recent versions of glibc and eglibc will build some
functions that take format strings (eg. printf, syslog...) with
run-time checks against some format string attacks. This is
called a fortified build.
Unfortunately, this fails somehow while building the instrumented
version of syslog, with some kind of circular dependency...
Disable fortified builds by default, and hide the enabling option
behind EXPERIMENTAL for daring users...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
As companion tools might or might not be used to build each
toolchain, they do belong to that toolchain's build tools,
not to the generic override tools.
Fix a typo in the autoconf URL.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
