The place to get 3.x has changed; the version scheme has changed.
No need to be overkill, just support 3.x; 4.x is not even dreamt of.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
If the user builds a toolchain over an existing one, so, without removing
CT_PREFIX_DIR, the build fails as the symlinks already exist, as does the
build.log.
This can also happen (for build.log) if the user first ran in download-
or extract-only.
Patch (with no SoB) originally from:
Phil Wilshire <phil.wilshire@overturenetworks.com>
Modified by me as it did not apply cleanly.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
During the build, we create lib{32,64}/ symlinks out of the sysroot.
In some cases (eg. mingw32 target), these symlinks are still required
when running the toolchain. For other combinations, the symlinks are
without incidence, so they can be safely kept after the build.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The new MIPS-specific options are not valid for other targets.
Also, move the arch-specific setting lower in the extra_config setting.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Add the following MIPS specific options when configuring gcc:
--with(out)-llsc
--with(out)-synci
--with(out)-mips-plt
--with-divide=type
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Add an option to specify the hash type that gcc will ask the linker to use.
It is a provision for the upcoming 4.7, as no version currently supports it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Add an option to configure gcc with --enable-linker-build-id.
Reported-by: Bryan Hundven <bryanhundven@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Instead of getting eglibc over standard svn://svn.eglibc.org
Add an option that allows the user to get source from
http://www.eglibc.org/svn
This is useful if you are behind a firewall or proxy.
If you are behind a proxy, don't forget to configure
${HOME}/.subversion/servers
In the [global] section setup your proxy configuration.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
[yann.morin.1998@anciens.enib.fr: removed useless 'default n']
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
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>
Refactor the contents of 'do_libc_start_files()' and 'do_libc()' into a
parameterized 'do_libc_backend()'. 'do_libc_start_files()' and 'do_libc()'
call 'do_libc_backend()' with either 'libc_mode=startfiles' or
'libc_mode=final' (respectively) so that the startfiles/headers and
the final libc builds are configured and built with the same options.
One example of where this is needed is when building a mips toolchain.
Previously, if you were building an n32 toolchain, you wouldn't have
noticed an issue, because if '-mabi' is not in CFLAGS, n32 is the
default:
http://sourceware.org/git/?p=glibc-ports.git;a=blob;f=sysdeps/mips/preconfigure;hb=HEAD
But when trying to build an o32 or n64 toolchain the build would
have failed. This is because (e)glibc expects "-mabi={o32,n32,n64}" to be
in CFLAGS, but was not previously provided in 'do_libc_start_files()'.
The build failure would happen in the shared-core gcc when it tries to
configure an n64 or o32 gcc with an n32 libc.
A simpler solution would have been to just add TARGET_CFLAGS to configure
in 'do_libc_start_files()', but this way makes configure and make
consistent for both steps.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Cross-gdb depends on expat and python. If either is missing, cross-gdb will
build successfully, but lacking some features.
Especially, if expat is missing, cross-gdb will be unable to parse the target
description, which may lead to runtime malfunctions and the following GDB
warning:
"Can not parse XML target description; XML support was disabled at compile time"
Hence, expat should be considered mandatory.
On the other hand, the features missing without python are not critical, so
python should not be considered mandatory.
This patch does the following:
- At configure time, warn the user if either expat or python is missing.
- In menuconfig, disable the static build options regarding cross-gdb if no
static version of expat is available, and disable cross-gdb if expat is
missing.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
[yann.morin.1998@anciens.enib.fr: add comment for impossible static cross-gdb]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The NPTL add-on has always been internal, so there is no
reason to try downloading it, it will never succeed.
Add provision to skip other add-ons as well.
For consistency, do the same test in both glibc and eglibc.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
"crosstool-NG-${CT_VERSION}" is currently the default for TOOLCHAIN_PKGVERSION,
and this options is passed as is to --with-pkgversion.
This patch prepends "crosstool-NG ${CT_VERSION}" to TOOLCHAIN_PKGVERSION before
passing it to --with-pkgversion.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
Some addons are bundled with glibc/eglibc, so we should not try to
download and extract them.
This is done as thus:
- at download time:
- if the add-on download fails, keep going;
- at extract time:
- if the addon is present in the source tree, ignore it;
- if the addon is missing in the source tree:
- if the archive is present, extract it;
- if the archive is missing, bail out.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
eglibc is only available from SVN. The script currently calls svn
in its own tortuous and convoluted way.
Use the egeneric SVN extract functions, and sinplify the eglibc
download function.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
This patch makes gdb benefit from the TOOLCHAIN_PKGVERSION and
TOOLCHAIN_BUGURL options.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
This patch makes eglibc benefit from the TOOLCHAIN_PKGVERSION and
TOOLCHAIN_BUGURL options.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
This patch makes binutils benefit from the TOOLCHAIN_PKGVERSION and
TOOLCHAIN_BUGURL options.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
This patch promotes the PKGVERSION and BUGURL options to toolchain level so that
all toolchain components supporting them can benefit from them.
These options are passed to configure through --with-pkgversion and
--with-bugurl.
They are supported by binutils 2.18+, gcc 4.3+, eglibc 2.9+ and gdb 7.0+.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
glibc and eglibc have a very similar extraction process, so it
makes sense to commonalise it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
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>
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>
Make it explicit that a variable is an array bu the name of the variable.
It will be used later when .config gets munged to allow both multiple
arguments and arguments with spaces at the same time to be passed from the
configuration down to the build scripts.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
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>
PPL does not use the "--enable-cxx" configure switch at all; it's
possibly a cut-and-paste leftover from 'gmp.sh'. (PPL is written in C++
natively, so it doesn't make much sense to have to enable C++; GMP, on
the other hand, is written in C with an optional C++ wrapper.)
Signed-Off-By: Anthony Foiani <anthony.foiani@gmail.com>
'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>
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>
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>
The gcc used by linaro has a version number specific to Linaro, but
identifies itself with its upstream version numbering scheme.
This breaks the strip in the finish step, because the actual gcc version
is not the same as the configured one (eg. 4.5.2 vs. linaro-4.5-2011.02-0).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
We make it an option, as not all combinations of architectures
vs. compiler vs. glibc/eglibc exhibit the issue. Mostly visible
on old glibc versions, it seems...
This is a missing part from the glibc/eglibc merger... :-/
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Enabling plugins in binutils is not enough, and gcc also
needs to be ./configured with --enable-plugins, although
this is not documented anywhere... :-/
Reported-by: karthik duraisami <kdconstant@hotmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Since the advent of make-3.82, some packages now break due to changes
in make-3.82, being stricter than 3.81 when interpreting the Makefiles.
This has bugged us a bit too much so far, and I believe fixing all
of them is a long road, while simply building make-3.81 is the easiest
route for now.
Of course, in the long term, packages will get fixed upstream, and we
should back-port the fixes to old versions, and get rid of building
make-3.81. In the meantime...
Reported several times on the mailing list.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Under mingw, it seems that there is a mix between the traditional /usr
directory, and a similar-purposed /mingw directory (both in the sysroot).
Currently, we create /mingw as a symlink to /usr, and we removed it in
the libc-finish step.
Unfortunately, this prevents the pre-processor to find the headers.
Keeping the symlink makes it magically work...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Depending on local policies, some users have expressed a need to
have the sysroot be named differently than the hard-coded name.
Add an option for that.
Default to 'sysroot' to match the existing literature.
While at it, replace 'sys-root' with 'sysroot' everywhere we
reference the sysroot.
Reported-by: Alexey Kuznetsov <Alexey.KUZNETSOV@youtransactor.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Final step at sharing code between glibc and eglibc.
Fall, wall of shame, fall!... :-)
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The reunification of the glibc/eglibc code paths exposed a nasty
bug in the glibc build: use of PARALLELMFLAGS breaks the build.
See the explanations in that bug report against FC6:
https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=212111
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
glibc and eglibc each have two very similar ways of building this list.
This can, and should definitetly, be shared.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
It will be possible to use that also with eglibc, so this hunk belongs to
the common code.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Use the common procedure, shared between glibc and eglibc. This requires
that glibc-specific bits be included in the shared procedure.
But still build the full libc with the glibc-specific procedure. This will
be commonalised in a future commit.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The build procedure for eglibc is generic enough to
be shared between glibc and eglibc. This includes:
- headers install (empty!)
- start files build
- complete libc build
- libc finish (empty!)
- add-ons list
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
It is unnecessary to split C library preparation into two steps, as only
one really makes sense. So, do_libc_headers is bound to be withdrawn
short-term, in favor of do_libc_start_files.
mingw already had all its start files installation in do_libc_headers, and
do_libc_start_files was empty, just migrate the content of the former into
the latter.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
It is unnecessary to split C library preparation into two steps, as only
one really makes sense. So, do_libc_headers is bound to be withdrawn
short-term, in favor of do_libc_start_files.
uClibc already had all its start files installation in do_libc_headers, and
do_libc_start_files was empty, just migrate the content of the former into
the latter.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
This is an obsolete version which is no longer used by any sample (the only
user, the ia64 sample, has been removed).
It also makes the code path a bit complex, with twists just to accomodate
that version. Removing the version will make those twists go away, and
will ease commonalisation of glibc and eglibc in the future (hopefully!).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
ia64 is broken in every gcc/glibc combinations I tested (except for the
existing sample that used very old versions).
Nobody complained on the list about not being able to build recent versions.
So the only way forward I can see is to remove the architecture altogether.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The location of the longterm Linux kernels on FTP has changed.
Here is a simple (but not very versatile) fix.
Signed-off-by: "Björn A. Herwig" <herwig@gdsys.de>
[yann.morin.1998@anciens.enib.fr: make it generic/versatile]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Latest version of CLooG does not have properly generated autoconf files,
so they need to be regenerated before the call to ./configure
Signed-off-by: "Ilya A. Volynets-Evenbakh" <ilya@total-knowlege.com>
[yann.morin.1998@anciens.enib.fr: make it conditional on 0.15.10 only]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
ltrace 0.5.3 currently fails to build for target mips because MY_TARGET
(introduced by patches/ltrace/0.5.3/150-allow-configurable-arch.patch)
is set to 'mips' via CT_ARCH, while the mips specific stuff in ltrace
(0.5.3) is stored under sysdeps/linux-gnu/mipsel:
result: *** No rule to make target `mips/arch.h', needed by `sysdep.h'.
Stop.
The following patch fixes this issue
Signed-off-by: "Horst Kronstorfer" <horst.kronstorfer@aon.at>
[yann.morin.1998@anciens.enib.fr: reformat commit log]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
To properly enable LTO with gold, gcc has to install a plugin that gold
uses to handle the LTO information.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
When both gold and ld are installed, add a wrapper that calls
to either gold or ld.
In case the wrapper is installed, we also need to symlink ld.bfd
and ld.gold for the core_cc steps.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
When configured with support for threads, gold can link in
parallel, possibly cooperating with a make jobserver.
Add an option enabling threads.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
gold is a new, optimised, multi-threaded linker with support
for plugins.
Add support for gold starting with binutils 2.21. Although 2.20
also had gold, the configure flags have changed, and supporting
2.20 would be a mess in the code.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
libelf is used by gcc to build the lto-plugin used
by binutils' gold to perform LTO.
This requires that files in libelf be compiled with
-fPIC to generate a proper .so.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Hidden version names for uClibc conflicted:
LIBC_UCLIBC_V_0_9_30_2
LIBC_V_0_9_30_1
name them constantly as:
LIBC_UCLIBC_V_<version>
Also update the build script where we use snapshots by version or snapshots by date.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Like rev 2002, eglibc installs some bash scripts, but use the path to the
buildtool bash as the interpreter (on the shebang line). This is only a
symlink to the real bash, and thus is not available at runtime.
Fix that by assuming that shell on the target *will* be /bin/bash.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
headers_install makes .install and ..install.cmd files.
headers_check makes .check and ..check.cmd files.
Remove these files uncoditionaly after installing (and checking) header files
into the sys-root.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
[Yann E. MORIN: reformat the patch, move hunk out of headers_check conditional]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
It appears, that the configure scripts of libelf versions 0.8.13 and
0.8.12 do not honour the --host option. The compiler must be given as an
environment variable or the process will use the command "gcc" as the
compiler.
It seems that this is already done in the function do_libelf_target in
scripts/build/companion_libs/libelf.sh, but not in function do_libelf.
Do not try to strip any script.
Previously, only shell scripts were ignored, but when the Java frontend
is installed, it also installs a Python script. So we have to ignore
any "script text executable", and not restrict it to "shell script text
executable".
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Using a list of files to strip misses a few of them.
Now, scan appropriate directories, and strip all ELF
executables and shared objects.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
- add a new parameter to do_cc_core: build_statically=[yes|no]
- pass build_statically=yes in core_pass_2 when doing bare_metal
- fix handling the static / static libstdc++ / static complibs stuff
- add a commment to keep both blocks (in core and final) in sync
Signed-off-by: "Bryan Hundven" <bryanhundven@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
If the global static option is set, then build the final gcc statically.
Signed-off-by: "Bryan Hundven" <bryanhundven@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
If the global static option is set, then build binutils statically.
Signed-off-by: "Bryan Hundven" <bryanhundven@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
This rules out 0.15.5 and previous versions, that did not
have this option, so remove them from the list. Anyway,
they were marked 'OBSOLETE', so it's not a big loss...
[Yann E. MORIN: remove obsolete versions]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The version string was hard-coded.
Now, the version string follows the crosstool-NG version.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Since Subversion 1.6.13 was released, it is no longer possible
to checkout/export to the current working directory using '.'
(eg. "svn co bla://blabla/foo/bar ." no longer extracts the content
of bar into ./ but into ./bar).
Fix this by luring Subversion to extract into "$(pwd)", which has
the advantage of working both with all known versions so far.
At the same time, remove the useless redirection.
Adds support to enable/disable IOs of floating point values
(float, double, and long double).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
This was intended as a fix for g++ not finding its headers,
but it breaks in othe horrible ways. So just revert it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
I ran into some minor difficulties looking through the build log for a
particular file: I wasn't interested in seeing it unpacked, but only
when it is built or installed. Adding these two levels allows me to
differentiate between those cases.
[Yann E. MORIN: Those are blind log levels, and are used only to search
in the build-log afterward.]
Signed-off-by: Anthony Foiani <anthony.foiani@gmail.com>
In case we build the C++ compiler, we have to tell gcc where to put the C++
headers, or else it will try to # put it in prefix/tuple/include, which we
make a symlink to sysroot/usr/include during the build, and that we delete
(the symlink!) after the build, but gcc will not look in sysroot/usr/inlcude
for C++ headers by default.
Implements a fix suggested by: Bryan Hundven <bryanhundven@gmail.com>
Reported-by: Anthony Foiani <anthony.foiani@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
libssp is the run-time Stack-Smashing Protection library.
It can be usefull to have or miss, depends...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
libgomp is the GNU implementation of the OpenMP API.
It can be usefull to have or miss, depends...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Force gcc to not link with some companion libraries when
there are not needed (because selected-out).
There is no option to tell gcc *not* to build the Graphite and/or
LTO stuff. They *will* be built if gcc finds the suitable companion
libraries. If we do not provide them, but the host has them, then
gcc *will* find them, and link with them.
Consider the following:
- host has suitable PPL and CLooG (eg. Debian Squeeze)
- user wants to build gcc>=4.4
- user de-selects GRAPHITE
- gcc will find the hosts PPL and CLooG, and will use them
- the user moves the toolchain to an older host that does
not have them (eg. Debian Lenny)
- the toolchain fails, when it was properly setup not to
So, explicitly tell gcc *not* to use unneeded companion libs.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
While GMP and MPFR are required by gcc>=4.3 (to build the frontends),
and MPC is required by gcc>=4.5, the other libs are not. If they are
present then gcc will enable advanced features; if they are missing,
then gcc will (should) simply disable those features.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Use the MIPS ABI selection to properly munge the uClibc config file.
This has the side effect to force the ISA:
- n32 ABI -> MIPS-III ISA
- n64 ABI -> MIPS64 ISA
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
This adds selection for one of the o32, n32 and n64 ABIs.
Later, we can easily use those boolean options, rather than
relying on a user-supplied string option.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The symlinks are needed only during the build process.
The final gcc will still search those dirs, but will also search
the standard lib/ dirs, so we can get rid of the symlinks.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
For now, ncurses is the only dependable target library built for gdb.
But expat is coming, and there's no reason to install each library in
its own place.
So, install ncurses in a generic directory, where other dependable
libraries can be installed as well.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
As there's no longer any user of the companion libraries on the
target, nuke the build for the target.
Well, at least, there's libelf that's still needed by ltrace, so
we keep it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Although the gdb ./configure advertises for GMP and MPFR, those libraries
are not used by gdb (the ./configure is used across different packages,
hence the check for GMP/MPFR). See:
http://sourceware.org/ml/crossgcc/2010-08/msg00168.html
The same applies to MPC.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
When targeting mingw32, gcc expects to find its include files
in "mingw/include" instead of the traditional "usr/include".
[Yann E. MORIN: split the original patch]
On some Fedora boxen (at least FC13), it is also required
to link with libm when static ppl is used.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
To reduce filesizes of the toolchain and even improve build times
of projects to be build with this toolchain it is usefull to strip
the delivered toolchain executables. Since it is not likely that we
will debug the toolchain executables itself we do not need the
debug information inside the executables itself.
Signed-off-by: Remy Bohmer <linux@bohmer.net>
For some scenarii, libmudflap is not very usefull
or can break the build. Make in an optioon that
defaults to 'N' to be on the safe side.
For the core gcc-s, there is absolutely no need
to build libmidflap.
Idea from: Bernhard Pfund <bernhard@chapter7.ch>
Some time, someone updated the locale Makefile to use
newer pre-generated locales data, but did not upload
those.
So we just force using the existing, ageing archive,
dating back 20030818. Sigh...
It seems that using pre-generated locale data can be more problematic
than usefull in some circumstances.
Offer a config knob to enable/disable use of the pregen locale data.
Also, do not extract pregen locales data ourselves, it's broken.
I was unable to make the cross-ldd from uClibc to work, and
it is not possible to build it on non-POSIX system.
Besides, we have a generic script that is in the starting-blocks
to replace it, that will work for any C library, and also will
work on non-POSIX systems. Bonus!
When building a cross-compiler for a target which uses a file extension for
binaries the symbolic link to cc is not created correctly because the lookup
of the gcc binary is done in a incorrect path
Signed-off-by: Bart vdr. Meulen <bartvdrmeulen@gmail.com>
GDB requires PDcurses instead of ncurses while running on Windows.
So, do not always compile ncurses in case GDB needs to build.
PDcurses is provided by an earlier build step and is not described in
this file.
Signed-off-by: Remy Bohmer <linux@bohmer.net>
[yann.morin.1998@anciense.nib.fr: we already have a way to detect ncurses usage]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Add several development libraries to the build of the mingw cross-compiler
to be used on target
Libraries:
PDCurses (port of the ncurses library)
GnuRX (the regex library)
DirectX
OpenGL
Signed-off-by: Bart vdr. Meulen <bartvdrmeulen@gmail.com>
[yann.morin.1998@anciens.enib.fr: don't show DX and RX versions if disabled]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Add the option to build a cross-compiler for kernel type 'mingw'.
The resulting cross-compiler can be used to build applications on a Linux host
that can be run on a Windows target.
Compiler is build using the mingwrt and w32-api packages aviable from the
MinGW project (http://sourceforge.net/projects/mingw).
The windows headers (w32-api package) are extracting with the kernel_headers
step The libraries and other headers from both packages are build and
installed in the various steps of libc
Signed-off-by: Bart vdr Meulen <bartvdrmeulen@gmail.com>
[yann.morin.1998@anciens.enib.fr: fix kernel headers comment, don't "return 0"]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
glibc installs some bash-scripts, but uses the path to the buildtool
bash as interpreter (on the shebang line). This is only a symlink to
the real bash, and thus is not available at runtime.
Fix that by assuming that bash on the target *will* be /bin/bash.
Accept a local tarball name as the source of the Linux kernel headers,
rather than forcing the user to use either an upstream tarball, or a
local pre-installed headers tree.
Here, we implement a highly ugly hack. I'm not proud of that one...
To build the libstdc++ library, the compiler requires the C library. In
case we build for non-baremetal, this is normally handled by the final
step, later.
But in the case of bare-metal, we never go through the final step (because
it does not work, and it seems complex enough to make it work), so the
baremetal compilers are issued out of the core step.
A few facts:
- building the C library requires a proper core compiler
- core compiler is issued from one of the core passes
- the C library is required to build libstdc++
- newlib is only built for baremetal
- in bare metal, the final compiler is issued from one of the core passes
So we need to build the C library between core pass 1 and core pass 2.
The only place is eithe libc_headers() or libc_start_files(). The most
pertinent seems to be libc_start_files().
So we build newlib from libc_start_files(), and leave libc() empty.
static linking is not possible on MacOS, and unnessecary on other systems.
The old optimization and warning flags crash the gcc on MacOS
and (imho) are a bit overdone for this software.
This patch adds support for installing the gcc test suite. A helper
Makefile is provided for building and running the gcc tests.
The default configuration runs all gcc tests and requires automatic
ssh/scp login access to a networked target board. See README for
more details.
Note: Current feature is tested with the powerpc-unknown-linux-gnu
sample but it should work with others as well.
Signed-off-by: Martin Lund <mgl@doredevelopment.dk>
The shell wrapper script uses a nonportable call to readlink.
Thus, always use the binary wrapper under BSD/MacOS.
yann.morin.1998@anciens.enib.fr:
Use 'case' instead of 'if'.
The call to stat to find out if a file is a symlink works only on GNU systems,
and the replacing portable call to readlink is also shorter and more concise code.
yann.morin.1998@anciens.enib.fr:
Apply simpler test, after discussion with author and Arnaud LACOMBE on the ML.
While compiling a canadian toolchain for host=mingw32, build=linux,
target=m68k-elf the build fails because in this step of the gcc build
the Host compiler is used in this stage with the build-flags for the
build system. This results in an error where the header <sys/wait.h>
cannot be found.
This problem happens at least in the GCC-4.3.x and GCC-4.4.x range.
This is solved by passing the proper compilers on the Make cmd-line
Signed-off-by: Remy Bohmer <linux@bohmer.net>
Previous addition of the canadian cross compiler did not allow
to build a baremetal only variant, no reason why this is not
allowed
Signed-off-by: Bart vdr. Meulen <bartvdrmeulen@gmail.com>
When building a cross-compiler for a host which depends
on file extensions the symlink for cc was not installed correctly
Signed-off-by: Bart vdr. Meulen <bartvdrmeulen@gmail.com>
[Yann E. MORIN: style fixes, enhancements, code prettying]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Insight seems to be very slow to follow up on mainstreram gdb.
Latest snapshots are more than 6 months old.
Moreover, I don't have time to maintain insight support in crosstool-NG;
and, because I don't use it, I am unable to find any breakage.
For uClibc, the name of the Blackfin architecture is 'bfin'. Actually,
the naming of the architecture is quite messy: for toolchain tuples
and uClibc, it's bfin, but for the kernel, it's blackfin. We've
arbitraly choosen to name it "blackfin" in Crosstool-NG.
Add Blackfin-related uClibc patch to fix a build failure related to
fork() being used in unistd/daemon.c.
Yann E. MORIN:
Apply the patch to the kernel/linux build script to use 'linux'
in the noMMU tuples. See:
http://sourceware.org/ml/crossgcc/2010-04/msg00010.html
When building for bare-metal the core-gcc compiler is delivered
as final compiler, so the version info and bugurl is useful
in the core compiler as well.
Signed-off-by: Remy Bohmer <linux@bohmer.net>
In some exotic case the autoreconf step of mpfr is not executed (correctly)
leaving an incorrect version number for libtool in the configure script.
After extracting the sources files, force autoreconf to be executed.
Signed-off-by: Bart vdr. Meulen <bartvdrmeulen@gmail.com>
If threads are disabled in libc, we don't want to enable them in the
final compiler. Doing so pass the configure stage, but fails latter on
a missing <pthread.h>.
Moreover, we don't want to build libgomp if threads are disabled; its
configure script would fails anyway.
Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
sstrip is now alone in its 'tools' menu, and we will probably never gain
any other 'tool'. Besides, sstrip is just strip, but a little bit more
agressive, so it deserves going to the 'binary utilities' menu.
The native 'tic' will _always_ be run on the build
machine, so no need to handle canadian/native/...
Reported by: Trevor Woerner
http://sourceware.org/ml/crossgcc/2010-03/msg00055.html
(transplanted from 26e89d367ea11660fd3a0bf0bcad8763e4fa21cf)
ltrace uses i386 and x86_64, whereas crosstool-NG use x86 for both cases.
Fix that by detecting what bitness we're building for, and pass appropriate
i386 or x86_64 to ltrace's configure.
The companion libraries on the target are required only for internal use by
binutils and gdb. The user should not have to know about this, so hide the
option.
We can not rely on the user-provided version string (be it via the
choice, or manually entered), so fallback to reading version.h,
which is both reliable and always present.
It's now been a while that glibc switched to git from cvs.
Get rid of cvs to download glibc; this will make for a good
cleanup before we add git support! :-)
Signed-off-by: Remy Bohmer <linux@bohmer.net>
[yann.morin.1998@anciens.enib.fr: use defaults for CT_TARGET_ARCH]
Signed-off-by: "Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
