When building from:
{git,http}://sourceware.org/git/binutils-gdb.git
and setting BINUTILS_CUSTOM or GDB_CUSTOM, they could be the same
source.
These config options should not affect normal released versions.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
As per the change notes of GCC-6:
https://gcc.gnu.org/gcc-6/changes.html
and conversations I've had with the buildroot folks, there is no need
to support sh5/sh64.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
We check for apps:
* make
* sed
* grep
* awk
* libtool/libtoolize
* install
* patch
* and more
...during configure. Our scripts should be consistent about using the
variables that define where the found tool was found.
Of course, we do hard-link these tools in buildtools, but that should be
a backup for the components we are building. Our scripts should always
use the tools we find.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This commit removes ncurses-5.9 and adds 6.0.
I also provide the stable patch updates in patches/ncurses/6.0.
I have also added an experimental toggle for enabling the new ABI
support.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Now that expat/curses have migrated into separate script, no need for
do_debug_gdb_parts() and need_gdb_src checks.
Signed-off-by: Alexey Neyman <stilor@att.net>
Currently, builds for build and target (matching the current
implementation). Need to add building for host for canadian crosses.
TIC_PATH is removed - configure in ncurses searches $PATH, so it finds
'tic' in buildtools anyway. Arguably unneeded code for MacOS also
removed, with a FIXME comment for validation by someone using MacOS.
Signed-off-by: Alexey Neyman <stilor@att.net>
Currently, only libelf has a for-target step - but it generalizes
the step to hook other libraries into this step.
Signed-off-by: Alexey Neyman <stilor@att.net>
The Xtensa processor architecture is a configurable, extensible,
and synthesizable 32-bit RISC processor core. Processor and SOC vendors
can select from various processor options and even create customized
instructions in addition to a base ISA to tailor the processor for
a particular application.
Because of the configurability, the build process requires one additional
step for gcc, binutils, and gdb to update the default configuration.
These configurations are packed into an 'overlay' tar image, and are
simply untarred on top of the default configuration during the build.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
.. they're needed for the RPC generation in glibc
on both Cygwin and MinGW-w64.
Neither are built on GNU/Linux and iconv is not
built on Darwin.
Two patches for gettext are needed, one so that
-O0 works and one so that static builds can be
made.
They can take a good while to build, so if not
needed for_host or for_build then they are not
built.
Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
I've added the .config files to contrib/uClibc-defconfigs from buildroot
to use as default configs if they are not provided in the sample.
If a particular architecture really needs an option set, it should be
either updated in the manange_uClibc_config function in
scripts/build/libc/uClibc.sh or a custom ${uclibc_name}.config should be
added to the sample (usually via `ct-ng saveconfig`).
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This commit updates uClibc to use the new CT_Kconfig options from the
previous commit. The older sed method of sanity checking the uClibc
.config was error prone and clumsy.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
mpfr.org has been less then reliable, so lets make gnu.org the primary
instead of the secondary source.
This closes#250
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This commit removes blackfin support.
I'm open to re-adding blackfin after crosstool-1.23.0 is released, but
it is currently too difficult to port forward to newer versions of gcc
and uclibc.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Some architectures, like arc and blackfin set CROSS_COMPILE to a default
if it is not set on the command-line.
Since we are building the cross-compiler, we need to ALWAYS set
CROSS_COMPILE, since building/checking headers is done after the GCC
PASS1 step.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This change, as per #222, reduces the number of supported releases of
gcc to the latest branch releases.
I noticed while doing this work that gcc-4.5.4 was never added, so I
moved patches for gcc-4.5.3 to 4.5.4 and updated the
bfin-unknown-linux-uclibc example. Also, 120-siginfo.patch was fixed
upstream in the 4.5.4 release, so this patch is omitted.
I also bumped the avr sample to 4.9.3 from 4.9.2.
With the addition of gcc-5.x, the gcc release team now releases the
major.minor.0 versions, while updates to the branch are available in
svn/git. We'll address that when we get to issue #219. This change just
removes CC_GCC_5_1 and moves CC_GCC_5_2 to CC_GCC_5, and removes
CC_GCC_5_1_or_later and moves CC_GCC_5_2_or_later to CC_GCC_5_or_later.
This is the first of two part changes, as mentioned in #222.
This change is slated for release in 1.22.0. The next change will be
slated for 1.23.0, and will limit gcc versions to what is on
https://gcc.gnu.org under "Release Series and Status", which is
currently 4.9.3 and 5.2.0, although I will also support the previous
supported version. In this example that would be 4.8.5.
Last, but not least, this change also retires AVR32 support.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Having *.la in the installation directory breaks ltrace: in ltrace,
libtool somehow considers libsupc++ to be an "accessory library" and
does not add -lsupc++ to the link flags. Neither Ubuntu, nor RedHat
include *.la files into their packages for libstdc++.
Signed-off-by: Alexey Neyman <stilor@att.net>
- New configurations:
- CC_GCC_TARGET_FINAL:
Use the default targets "all" and "install" for the final compiler for
bare metal.
- Adding parameter "build_step" to function do_gcc_core_backend:
do_gcc_core_backend is used for the core compiler and in case of bare metal
for the final compiler, too. To have better control over the parameters for
the final compiler "build_step" is used.
- Used for proper logging.
- Use CT_CC_GCC_CORE_EXTRA_CONFIG_ARRAY or CT_CC_GCC_EXTRA_CONFIG_ARRAY.
- If CT_CC_GCC_TARGET_FINAL is set and the final compiler is build then the
make targets for the final compiler are used ("all", "install").
Signed-off-by: Jasmin Jessich <jasmin@anw.at>
CT_CC_GCC_HAS_LIBQUADMATH and CT_CC_GCC_LIBQUADMATH (--en/disable-libssp,
--en/disable-libquadmath, --en/disable-libquadmath-support) from function
do_gcc_backend.
Signed-off-by: Jasmin Jessich <jasmin@anw.at>
glibc-2.17 and above no longer have external addons or ports.
So if we are => 2.17, don't even think about trying to mess with ports
or addons.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Configure for for core GCC did not use Core gcc extra config.
Use now config variable CT_CC_GCC_CORE_EXTRA_CONFIG_ARRAY.
Signed-off-by: Jasmin Jessich <jasmin@anw.at>
This commit adds support for the avr-libc C library.
According to the project page at http://www.nongnu.org/avr-libc , the
avr-libc package provides a subset of the standard C library for Atmel
AVR 8-bit RISC microcontrollers. In addition, the library provides the
basic startup code needed by most applications.
Support for this library in crosstool-ng is only enabled for the AVR
8-bit target.
The avr-libc manual and most distributions build the AVR 8-bit gcc
toolchain with the "avr" (non-canonical) target.
Some experimentation also led to the conclusion that other (canonical)
targets are not very well supported, so we force the "avr" target for
crosstool-ng as well.
The manual also recommends building avr-libc after the final gcc build.
To accomplish this with crosstool-ng, a new do_libc_post_cc step is
added, in which currently only avr-libc performs its build, and is a
no-op for the other libc options.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
This commit adds support for the Atmel AVR 8-bit RISC architecture.
This is the first 8-bit architecture to be added to crosstool-ng so the
configuration options for 8-bit architectures are added here as well.
gcc has had support for AVR for quite a while, at least since the 4.3
series for the currently popular ATmega microcontroler series.
The AVR architecture only supports bare-metal toolchains.
gcc for the AVR 8-bit architecture, usually referred to as avr-gcc, is
commonly used in conjunction with the avr-libc library which provides
additional resources for the Atmel AVR 8-bit microcontrollers.
avr-gcc can also be found as a supported package in some recent Linux
distributions.
This commit also closes#66
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
This option is old. GCC 4.3.x old. It isn't supported anymore, and just
confuses me. I'm not planning to support 4.3.x, or really anything older
then 4.7. So this option is gone to the wind.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
This commit updates gcc's test suite to use the new config options.
Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
Reviewed-by: Bryan Hundven <bryanhundven@gmail.com>
Reviewed-by: Yann Diorcet <diorcetyann@gmail.com>
Update 300-gdb.sh to use the new config options.
Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
Reviewed-by: Bryan Hundven <bryanhundven@gmail.com>
Reviewed-by: Yann Diorcet <diorcetyann@gmail.com>
Update 100-gcc.sh to use the new config option names.
Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
Reviewed-by: Bryan Hundven <bryanhundven@gmail.com>
Reviewed-by: Yann Diorcet <diorcetyann@gmail.com>
This change updates the CC.* references to CC_GCC.* in the internal
scripts.
Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
Reviewed-by: Bryan Hundven <bryanhundven@gmail.com>
Reviewed-by: Yann Diorcet <diorcetyann@gmail.com>
This commit moves gcc.sh to 100-gcc.sh to accomodate for other
cross-compilers that crosstool-ng might be able to build.
The first, to come soon, is llvm/clang.
Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
Reviewed-by: Bryan Hundven <bryanhundven@gmail.com>
Reviewed-by: Yann Diorcet <diorcetyann@gmail.com>
The argument will prevent the prefix path from being added as an include path while building mingw. Having the prefix as an include path might cause all kinds of weird issues if prefix directory also exists on the build machine.
Signed-off-by: Nils Petter Eftedal <nilspetter@eftedal.org>
Added new functions to support changes in prefix and required vendor tuple for new versions of mingw.
Tested and verified with mingw version 2.0.7, 3.3.0 and 4.0-rc3.
Signed-off-by: Nils Petter Eftedal <nilspetter@eftedal.org>
Glibc actually does create a build executable. It's under sunrpc and it's
called cross-rpcgen. It uses gettext, so if that's not available in a standard
place on your system (for example if you're using Mac OS X and Homebrew), then
you are all out of luck.
Signed-off-by: Lawrence D'Anna <larry@elder-gods.org>
Without this canadion cross builds create invalid symlinks:
When the code in do_cc_core_backend is called there is no
${CT_TARGET}-gcc in the install directory. Therefore ext is empty and
we create a link to ${CT_TARGET}-gcc. The final compiler
step then installs ${CT_TARGET}-gcc.exe and creates a working
${CT_TARGET}-cc.exe symlink but we still keep the invalid link
as well.
Signed-off-by: Johannes Pfau <johannespfau@gmail.com>
Prirotize http downloads before ftp downloads.
By having http download first, those using proxy will work with the
current download mechnism.
This tells me that that mechnism needs to be updated.
(proxy support and/or kconfig toggles)
closes#3
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
glibc versions that don't support --with-pkgversion or --with-bugurl
will cause a harmless:
====================
configure: WARNING: unrecognized options: --with-bugurl...`
====================
If it's set, use it, if it's a recognized option.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
As posted on http://www.eglibc.org/
====================
EGLIBC is no longer developed and such goals are now being addressed
directly in GLIBC.
====================
I'm not interested in maintaining build support for unsupported
software.
Older branches of crosstool-ng continue to have eglibc support.
If you find issues with older branches, I'm always open to pull
requests.
Removing eglibc also frees up glibc cleanup and build optimization.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
We had following problem: We're building a toolchain with an old glibc
version for compatibility with old Linux distributions (glibc 2.9). This
version requires make < 4 to build. However, the configure script of
glibc looks for make in the order "gnumake", "gmake" and "make". So when
"gmake" is available in the system (which is the case on Gentoo Linux
per default, unfortunately), then configure finds the system gmake 4.1
instead of the ct-ng make 3.82.
This patch adds an option to install a symlink so that 'gmake' is also
available in the old version when building toolchains.
Signed-off-by: Bernhard Walle <bernhard@bwalle.de>
Canadian Cross compile for baremetal fails with error;
checking for the value of EOF... configure: error: computing EOF failed
which is due to libstdc++ configure not being able to find stdio.h
Having all modes of the core compiler copyheaders from CT_HEADERS_DIR
(in combination with previous patch for newlib to add a do_libc_start_files
function to copy into the CT_HEADERS_DIR) resolves this.
Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
Require access to newlibs headers in gcc.sh, matching other libc components.
Resolves issue with headers not found.
Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
Currently, the obsolete RPC headers are only installed for eglibc,
but glibc has the same /deficiency/, so install the obsolete RPC
for both.
Signed-off-by: Jérôme BARDON <bardon.pro@gmail.com>
Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
Yes, I missed the backslash which messed up the linaro stuff.
The more I look at this code, I feel it needs to be refactored a bit. So
I'll come back to this in the future and clean it up.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
It's not my day.
linaro_version is a filter. If it is not a linaro toolchain, it will
just be CT_{CC,GDB}_VERSION. If it is a linaro toolchain, CT_{CC,GDB}_VERSION
will be prefixed with 'linaro-' and will not match linaro_version, as
linaro_version will just have the part after 'linaro-'.
This *really* fixes the issue :sigh:
Thanks again to @elsonwei for being right the first time!
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
linaro_version and linaro_series are defined but not set if we are not
configured for linaro builds.
Therefore we need to default them to "" (null string).
As reported by @elsonwei
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
If custom {e}glibc is being used, no need to carry out the
extract or patching phase of scripts/build/libc/glibc-eglibc.sh-common
Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
CUSTOM_LOCATION config options only presented in menuconfig if component
CUSTOM version selected.
Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
CUSTOM_LOCATION config options only presented in menuconfig if component
CUSTOM version selected.
Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
No longer recommended practice to use --enable-add-ons=nptl, so
for 2.20 and later (along with custom glibc), don't add the
CT_THREADS to the addons_list
https://sourceware.org/glibc/wiki/Release/2.20#Packaging_Changes
Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
This change updates the download locations to default to the official
download site.
For gcc and gdb, also separate out the linaro download locations so that
if you are downloading the linaro variant, it skips trying to download
from the official gcc mirror.
This commit closes#3
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Without this fix, elf2flt will blow up complaining that it can't resolve
dlopen() and friends. One has to explicitly pass '-ldl' on the final
linking command line, because the system linker is not resolving
indirect dependent shared libraries.
I've needed to this patch for several years on Fedora systems.
Signed-off-by: Solomon Peachy <pizza@shaftnet.org>
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
When try to build the static toolchain, binutils failed.
I have checked the libtool script, and found that the following option
-all-static
-static
-static-libtool-libs
are processed in a strange way. If any one of those three options
appears firstly in the cmdline, all others will be neglected. Our
LDFLAGS is ".... -static -all-static -o", so the -static option
takes the real effect, and the -all-static has no useage actually!
that is the cause of the failure.
Signed-off-by: Brock Zheng <goodmenlinux@gmail.com>
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This commit adds a configuration knob for enabling extra developer
warnings to be enabled during the musl-libc build.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This option enables a configuration knob for adding debugging info.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
libsaniotizer requires a few headers that are not in uClibc, for
example. Also, it is only available for native threads (NPTL under
glibc.) Finally, it is only available starting with gcc-4.8.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
This patch adds initial support for musl-libc.
Musl-libc versions currently supported:
* 1.0.3 (Stable)
* 1.1.3 (Previous Mainline)
* 1.1.4 (Mainline)
Futher improvements are needed.
* gcc-4.9.x has issues (Might be fixed in musl-1.1.4).
* Multilib support is needed.
* Checks to make sure paths are correct.
* Move to 2-step gcc build. 3-step build is not necessary.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
[yann.morin.1998@free.fr: removed the gcc musl patch, to be added later;
removed dead code do_get_arch()]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
The previous patch (cset b61a1b1, cc/gcc: avoid passing --enable-multilib)
only fixed the core backend, and missed the final backend.
This patch does the same as b61a1b1, but for the final backend.
Signed-off-by: Cody P Schafer <dev@codyps.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Technically, I don't forbid powerpcle support either, but I'm not sure that
there is any library/compiler support for that at the moment (though the hw
technically makes it possible).
powerpc64le needs glibc 2.19 and gcc 4.9. I haven't looked into the support
tools, but at least gdb 7.5 is too old (7.7.1 definitely has support).
Also make powerpc64 non-experimental. It's practically old at this point.
Signed-off-by: Cody P Schafer <dev@codyps.com>
[yann.morin.1998@free.fr: use ${target_endian_le} and ${target_bits_64}]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <64bfbbced9dd8f62e0d6.1399801945@gun>
Patchwork-Id: 347775
In case we're using a custom (aka local) binutils source, we still
need to extract and patch elf2flt.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
The final bare-metal compiler is built using the core backend.
Currently the core uses the CC_CORE_EXTRA_CONFIG_ARRAY variable.
While this works as supposed to, this can leave the user puzzled
in the menuconfig, since all he can see is the core options, not
the final options.
Only show the core options if any of the core passes are needed,
and use the final options in the core-backend if we're issuing
the bare-metal compiler.
Signed-off-by: Cody P Schafer <dev@codyps.com>
[yann.morin.1998@free.fr: hide core options if no core pass needed;
use final option in core backend if issuing the bare-metal compiler]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <22181e546ba746202489.1399688067@localhost>
Patchwork-Id: 347586
Some versions of gcc have a broken --enable-multilib flag. As multilib is the
default, only pass the --disable-multilib flag
Signed-off-by: Cody P Schafer <dev@codyps.com>
[yann.morin.1998@free.fr: make it an if-block; duplicate commit log as comment]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <5c970c1ceb22528fe28a.1399687923@localhost>
Patchwork-Id: 347585
newlib: fix extract process for custom version
If the user specifies the use of a custom newlib version, the logic in the
extract function was reversed, so this step would fail.
Signed-off-by: Trevor Woerner <trevor.woerner@linaro.org>
[yann.morin.1998@free.fr: keep leading indentation]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <c727adf1b7bd2c1e891d.1393353347@openSUSE-i7>
Patchwork-Id: 324060
We now know exactly what pass to build, so build only what is required.
Reported-by: Trevor Woerner <trevor.woerner@linaro.org>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
so that it is available to available to
the core C compiler build because static
libraries are built and ranlib is used
on them.
Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
Message-Id: <CAOYw7dt=+DdnKAHNShfs6a+=7sS+DLQYkyxnQMAwmw7E7zqvgA@mail.gmail.com>
Patchwork-Id: 316477
Decimal floats need support form the C library, namely support
for fenv, which is missing in uClibc for any architecture but
x86/32.
Add an option (a choice) to enable or disable decimal floats.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Support for fenv.h is a little bit more tricky that enabling it only
for x86-32 is not right.
Add an option for the user to choose whther to install fenv.h or not.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Do to glibc what we did to eglibc in #dff359adf15c.
Only (very) old versions of glibc have other external addons,
and they are no longer meaningful.
But for consistency, do the change nonetheless.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
When trying to extract an already present (aka bundled) addon,
print the name of that addon, for clarity, and to help analyse
the build.log post-mortem.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Since gcc 4.8 C++ is also used as implementation language (see gcc
release notes).
Signed-off-by: "Daniel Dittmann" <ddittmann@gmx.net>
Message-Id: <acc7d11bc77b30f21c5b.1388863298@bernalk.machteam>
Patchwork-Id: 306883
gcc-4.8 comes with a new library to sanitise memory access:
- heap-, stack-, and global-buffer overflow, use-after-free
- data-races between threads
This library requires some _np parts of the API, which are not
implemented in the (old) LinuxThreads, which is still available
in uClibc.
Since NPTL requires a i486 or above, i386 are stuck with using LT,
which precludes building the libsanitizer.
Disable libsanitizer, a bit like libatomic is.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Niels Penneman <niels@penneman.org>
For the versions of eglibc where the ports addon is not external (ie,
all versions after, and including 2.17), we would fail to download the
localedef addon, since the test did not care about the addon we were
about to download, only whether the ports addon was external or not.
Fix that by skipping the ports addon only if that's the addon we're
trying to download.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cset 3b61be3d7aa6 (prepare for arch whose kenel name is not the standard name)
failed to name a variable consistently, so all archs but arm64 were broken.
Fix that by renaming the variable in a consistent way.
Reported-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
AArch64 id the 64-bit variant for ARM.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Zhenqiang Chen <zhenqiang.chen@linaro.org>
Cc: Michael Hope <michael.hope@linaro.org>
For some architectures, the kernel architecture name is not the common
name of the architecture for other tools.
For example: ARM 64-bit is commonly referenced as aarch64, but the kernel
calls it arm64.
Signed-off-by: Michael Hope <michael.hope@linaro.org>
Signed-off-by: Zhenqiang Chen <zhenqiang.chen@linaro.org>
[yann.morin.1998@free.fr: split out of the aarch64 patch]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Some of the avr32headers related variables are used in different
functions, so have to be declared globally, not locally.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Don't download glibc-ports when glibc or eglibc version greater than 2.16,
because the "ports" source is mainline in the glibc or eglibc since version 2.17.
Signed-off-by: "Daniel Zimmermann" <netzimme@gmail.com>
Message-Id: <9c045ca3cf1b9dc89da3.1384602843@haus-VirtualBox>
Patchwork-Id: 291766
[yann.morin.1998@free.fr: slightly tweak subject, change variable name]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Building the cross-gdb shoud be done using the host compiler,
not the native compiler.
Reported-by: Per Arnold Blaasmo <per-arnold.blaasmo@atmel.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
In case ${CT_LIBC_GLIBC_CONFIGPARMS} starts with a dash, printf will try
to interpret it as an option for itself, and will invariably flail in
panic as it does not recognise any of it.
Use a more robust solution, as suggested by Cody.
Reported-by: "Roberto A. Foglietta" <roberto.foglietta@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Cody P Schafer <devel-lists@codyps.com>
Add well-known HTTP mirror as a fallback. This lets crosstool-ng
work when behind a HTTP/HTTPS only proxy.
Signed-off-by: Michael Hope <michaelh@juju.net.nz>
[me: split original patch in two]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <aeb4a850d0786ee62dc2.1375559989@wanda>
Patchwork-Id: 264436
Add well-known HTTP mirror as a fallback. This lets crosstool-ng
work when behind a HTTP/HTTPS only proxy.
Signed-off-by: Michael Hope <michaelh@juju.net.nz>
[yann.morin.1998@free.fr: split patch in two]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <aeb4a850d0786ee62dc2.1375559989@wanda>
Patchwork-Id: 264436
CLooG 0.18+ will use ISL instead of PPL, so we have to configure
adequately depending of which backend is in use.
The Kconfig entries will decide for us which is selected, so we
can rely on either PPL xor ISL to be selected, not both.
Reported-by: "Plotnikov Dmitry" <leitz@ispras.ru>
[Dmitry did a preliminray patch to add ISL support,
which this patch is inspired from]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
This means:
- introduce the new symbols for 4.8
- do not always select PPL if graphite is selected
Reported-by: "Plotnikov Dmitry" <leitz@ispras.ru>
[Dmitry did a preliminray patch to add gcc-4.8 support,
which this patch is inspired from]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
ISL is used by gcc-4.8 onward for GRAPHITE, so is also used as
backend for CLooG 0.18.0 onward.
Reported-by: "Plotnikov Dmitry" <leitz@ispras.ru>
[Dmitry did a preliminray patch to add ISL, which this one is inspired from]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
>From 4.8, g++ is used as the default compiler to build the toolchain.
Signed-off-by: Zhenqiang Chen <zhenqiang.chen@linaro.org>
Message-Id: <CACgzC7B-LQvAw3hOYhBA7b7g0H1WtH20gqXM=Y=YFO4FrnZKWQ@mail.gmail.com>
Patchwork-Id: 243590
Building cross-tool based on gcc-4.8 fails while "Installing
pass-2 core C compiler", because building libgcc.mvars needs
libbacktrace.a that gcc.sh doesn't build. This patch inserts
a few lines configuring, and making libbacktrace into gcc.sh
to build gcc-4.8-based cross-tools successfully.
Reported-by: Plotnikov Dmitry <leitz@ispras.ru>
Signed-off-by: Jongsung Kim <neidhard.kim@lge.com>
Message-Id: <201305031831.33395.neidhard.kim@lge.com>
Patchwork-Id: 241258
-fpermissive is not a valid option to gcc.
Adding it to the CFLAGS make the ppl checks fail with the following
error:
[ALL ] Making check in tests
[ALL ] cc1: warnings being treated as errors
[ERROR] cc1: error: command line option "-fpermissive" is valid for C++/ObjC++ but not for C
[ALL ] cc1: warnings being treated as errors
[ERROR] cc1: error: command line option "-fpermissive" is valid for C++/ObjC++ but not for C
[ERROR] make[7]: *** [formatted_output.o] Error 1
Signed-off-by: "Samuel Martin" <smartin@aldebaran-robotics.com>
Message-Id: <bba2482a06a11415207e.1365876457@smartin-de-2.aldebaran.lan>
Patchwork-Id: 236383
This patch fixes the download of the avr32 headers in crosstool-ng by
fetching them directly from Atmel's web site instead of the now-broken URL
given by the original author of the avr32-header-fetching modification,
who fetched them from a copy on his own, now-defunct server.
It also adds the necessary logic to extract from a zip file, as that is
how the headers are packaged.
To configure it for avr32 after launching ct-ng menuconfig in an empty
directory:
Paths and misc options ->
Shell to use as CONFIG_SHELL = sh
Target options ->
Target Architecture = avr32
Toolchain options ->
Tuple's alias = avr32
Binary utilities ->
binutils version = 2.18a
C compiler
gcc version = 4.2.2
C-library
newlib version = 1.17.0
Enable IOs on long long = yes
Enable IOs on floats and doubles = yes
Disable the syscalls supplied with newlib = yes
CONFIG_SHELL is necessary to get round the "fragment: command not
found" bug when binutils-2.18 is configured using bash.
Prepared against crosstool-ng mercurial trunk on 31 March 2012.
Signed-off-by: Martin Guy <martinwguy@gmail.com>
[yann.morin.1998@free.fr: update bundles sample accordingly]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <CAL4-wQrg_NQ7jm-NCADqeyQr9twyhtx42OUGNThP6gWeqZc=kw@mail.gmail.com>
Patchwork-Id: 232612
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Rafael C <groups.r2@gmail.com>
Cc: Jérôme BARDON <bardon.pro@gmail.com>
Cc: Daniel Price <daniel.price@gmail.com>
Reported-by: Rafael C <groups.r2@gmail.com>
Reported-by: Jérôme BARDON <bardon.pro@gmail.com>
Reported-by: Daniel Price <daniel.price@gmail.com>
[yann.morin.1998@free.fr: use a conditional approach, also suggested by Daniel]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
There's no point in not supporting XML in the cross-gdb.
I mean, come on... ;-)
It's still the responsibility of the user to have the necessary
devel expat packages installed for his/her distro.
Reported-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
For the native-gdb (ie on the target), we unconditionally
need to build expat.
Make it a backend, it makes a litle bit cleaner code.
Reported-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
It should be used only to decide whether we need to download/extract
ncurses, not wheter we should build it or not.
Reported-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Rename those three variables to properly reflect their purpose: decide
whether we need to download/extract gdb/libexpat/libncurses, not whether
we need to build them or not.
This is only a rename for now, subsequent changes will further
fix this mess.
Reported-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
The menu system provides an option to allow a user to request newlib
version 2.0.0. newlib-2.0.0, however, is not available at the download
location currently being used. It is, however, available (as are other
supported versions of newlib) at an alternate location.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Message-Id: <75ab5151c7f5dc9086e3.1362334313@suse64>
Patchwork-Id: 224561
For some architectures, it is legit to have an alternate value in the
'architecture' part of the tuple. For example:
armv5te-*
armv7a8-*
Besides, some packages expect the tuple to reflect the arch variant
(eg. openMPI) to detect the variant's capabilities (eg. atomic
primitives).
This patch adds an option for the user to specify a suffix to be added
to the arch-part of the tuple.
Signed-off-by: Willy Tarreau <w@1wt.eu>
Message-ID: <20130120225822.GS6838@1wt.eu>
Patch-Id: 213994
[yann.morin.1998@free.fr: make it a suffix, not an override]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Toolchains that use the hard-float ABI now are to be denoted by a tuple
ending in *eabihf, while the prevbious *eabi is now an indication that
the toolchain uses the softfloat ABI.
This is purely a cosmetic thing, for distros to differentiate their
hardfloat-ABI ports from their softfloat-ABI ports.
(note: softfloat ABI does not mean that it is using softfloats; it can
be using hardfloat instructions, but using the softfloat ABI).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Well, all eglibc version we support do, and latest glibc versions
we support do.
Not all glibc versions do, but older versions simply ignore the
unrecognised ./configure flags.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Since unrecognised ./configure flags are simply ignored,
we can always pass --enable-obsolete-rpc.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
ppl-0.10.x does not build with gcc-4.6+, as it uses constructs that were
warnings with gcc-4.5 and before, but are now errors with gcc-4.6 and
above.
Fix that by passing -fpermissive in CFLAGS for ppl 0.10.
Reported-by: Jeremy Rosen <jeremy.rosen@openwide.fr>
Reported-by: Peter Korsgaard <jacmet@uclibc.org>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
In gcc-'s core and final passes, do not print 'core' or 'final' in
log messages. We already print it in step messages.
Also, as we use the core backend to build the bare-metal final gcc,
it can be disturbing to read 'core' while we're in fact in 'final'.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
It is used for skipping unnecessary compilation steps when the libc
doesn't need to be compiled (eg. when we do not use a C library).
Signed-off-by: Yann Diorcet <diorcet.yann@gmail.com>
Message-Id: <150eadb0117e697d79aa.1353625025@blackmint>
Patchwork-Id: 201222
Rework binutils in order to provide soon binutils alternative.
Signed-off-by: Yann Diorcet <diorcet.yann@gmail.com>
[yann.morin.1998@free.fr: split up original patch for self-contained changes]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <d3d1d51f399e6d2c1163.1353320546@macbook-smorlat.local>
Patchwork-Id: 199971
On some hosts, and for certain toolchains (eg. toolchain targetting
the upcoming Darwin), it may be necessary to pass arbitrary CFLAGS
and/or LDFLAGS when building the components.
And necessary infrastructure:
- EXTRA_{CFLAGS,LDFLAGS}_FOR_{BUILD,HOST} as config options
- pass those extra flags to components
Fix-up a slight typo in elf2flt at the same time (misnamed cflags).
Signed-off-by: Yann Diorcet <diorcet.yann@gmail.com>
Message-Id: <d24043276c9243a35421.1353077450@macbook-smorlat.local>
Patchwork-Id: 199645
sstrip has been obsoleted for a while now, as it's still broken
for some archs, and there seems to be no incentive to fix it
upstream. Besides, the space gained with sstrip is marginal at
best.
Signed-off-by: Yann Diorcet <diorcet.yann@gmail.com>
Message-Id: <65c8bf534d0647ce52cd.1353320545@macbook-smorlat.local>
Patchwork-Id: 199970
Use the same method as companion tools for providing generic and
extendable companion libs.
Signed-off-by: Yann Diorcet <diorcet.yann@gmail.com>
Message-Id: <515c5c4635d99ebe4877.1353074410@macbook-smorlat.local>
Patchwork-Id: 199613
Replace the 32-bit-only mingw32 with mingw-w64 that is capable
of building toolchains for both 32-bit and 64-bit Windows.
kernel/mingw: replace mingw32 with generic Windows
kernel/windows: New windows kernel supporting 32 and 64 bit arch
libc/mingw: Remove old options
patches: Remove old mingw libc options' patches
Signed-off-by: "Yann Diorcet" <diorcet.yann@gmail.com>
[yann.morin.1998@free.fr: array var in libc/mingw.sh, typos]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <b045ac08fc9eac2e5ee3.1352898499@blackmint>
Patchwork-Id: 198901
While eglibc-2.16 recommends to use TI-RPC instead of the old sunrpc, the
old one can be included using a configure option. Since the user can still
use TI-RPC to override the libc implementation, we enable rpc unconditionally.
Signed-off-by: Johannes Stezenbach <js@sig21.net>
Message-Id: <20121102140404.GA7707@sig21.net>
Patchwork-Id: 196564
We now have the ability to use a custom location, so supporting
snapshots or custom date is no longer needed. Let the user do the
required preparation in this case.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
We now have the ability to use a custom local directory/tarball, so
it no longer makes sense to have the ability to use the CVS repository.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Since we now have the opportunity to use a custom local directory/tarball
as the source for gcc, it no longer makes sense to retrieve gcc ourselves
from its subversion repository.
Cc: Bryan Hundven <bryanhundven@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
That's legacy code that was usefull when ncurses was installed
in the sysroot. Still it's not longer the case (it's installed
in a special dedicated directory), we can remove that piece of
code.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
CUSTOM_LOCATION config options only presented in menuconfig if component
CUSTOM version selected.
Change elf2flt CT_ELF2FLT_VERSION from 'head' to 'cvs' if cvs selected in config
Also remove hardcoded 'cvs-' from elf2flt component name, used in CT_Extract,
CT_Patch and as the CT_SRC_DIR location for the configure stage.
Signed-off-by: "David Holsgrove" <david.holsgrove@xilinx.com>
[yann.morin.1998@free.fr: fix indentation, don't patch custom dir location]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <288db3721a37844defa5.1349931196@localhost.localdomain>
PatchWork-Id: 190789
Currently, extract and patch are skipped as thus:
- using a custom directory of pre-installed headers
- a correctly named directory already exists
Otherwise, extract and patch are done.
The current second condition is wrong, because it allows the following
sequence to happen:
- a non-custom kernel is used
- a previous build only partially extracted the non-custom sources
- that p[revious build broke during extraction (eg. incomplete tarball...)
- a subsequent build will find a properly named directory, and will
thus skip extract and patch, which is wrong
Fix that by following the conditions in this table:
Type | Extract | Patch
----------------------+---------+-------
Pre-installed headers | N | N
custom directory | N | N
custom tarball | Y | N
mainstream tarball | Y | Y
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: David Holsgrove <david.holsgrove@xilinx.com>
Config options remain the same as before, just generalised to be used by other
components also.
Signed-off-by: "David Holsgrove" <david.holsgrove@xilinx.com>
[yann.morin.1998@free.fr: fix indentation, fix comment]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <50674fe47431174aab80.1349931193@localhost.localdomain>
PatchWork-Id: 190786
Previous import from patchwork missed one hunk (in cset #d8feb93b3e49)
Apply it now.
Signed-off-by: "David Holsgrove" <david.holsgrove@xilinx.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Patchwork-Id: 189053
Attempting to ${CT_TARGET}-gcc -print-multi-lib will fail
In do_cc_core_backend, for the final compiler in a canadian cross
baremetal, warn that multi-libs cannot be determined
In do_cc_backend, for either final compiler for a canadian cross,
warn that multi-libs cannot be determined
(Plus fixed CT_PREFIX_DIR in do_cc_backend to be ${prefix})
Signed-off-by: "David Holsgrove" <david.holsgrove@xilinx.com>
Message-Id: <CAM=EW8aQDoNx-CkJHjXBoDP4iTDJ8z5hh3=KhO5UTU6rp3Pj=w@mail.gmail.com>
Patchwork-Id: 189053
--with-expat=yes is unconditionally passed to the gdb configure
stage, instead of respecting the ${do_expat} decision.
Disable if not needed. Prevents error building canadian cross;
configure: error: expat is missing or unusable
Where configure stage fails to find expat on the host compiler.
Signed-off-by: "David Holsgrove" <david.holsgrove@xilinx.com>
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Message-Id: <4c4410a2a8aab24a29c5.1349244128@localhost.localdomain>
PatchWork-Id: 188711
GCC requires m68k arch tuples to be *-*-uclinux-* to support Linux on
no-mmu m68k (ColdFire) cpus.
Blackfin arch tuple must be *-*-linux-uclibc for FD_PIC_ELF toolchains,
so we cannot just switch to uclinux for no-mmu Linux toolchains.
Signed-off-by: "Esben Haabendal" <esben@haabendal.dk>
Message-Id: <876271s1ee.fsf@arh128.prevas.dk>
PatchWork-Id: 186976
build fails to symlink to custom kernel dir when the build is not the first time
because of 'ln -s' without '-f' option.
Signed-off-by: "Jang, Bongseo" <graycells@gmail.com>
Message-ID: <543e2981f2b723ecd850.1348370892@localhost.localdomain>
PatchWork-ID: 186178
Add Microblaze architecture support.
This depends on EXPERIMENTAL, as upstream projects do not yet
include full support to build a modern microblaze compiler.
This is in the process of being updated, but is not currently
publicly accessible.
Signed-off-by: "David Holsgrove" <david.holsgrove@xilinx.com>
Message-Id: <9c93e18b3d68b19303f3.1348113870@localhost.localdomain>
PatchWork-ID: 185305
I took some of the svn functionality from eglibc.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
[yann.morin.1998@free.fr: fix the conditional test in build script]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
That comes from way back when nothing would work as expected, and I would
easily get heated as soon as anything would break. Sigh, those were the
old days.
Apologies.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
For expat, duma, and strace, use the generic url and 302 to the mirror
instead of trying to download a file from a downed mirror and
failing.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Message-Id: <b69ebeb72fef93c04c84.1345364051@flambe.is-a-geek.org>
Whatever the threading model (NPTL, LT...), we build the same
core pass-1 compiler, so there is no need to have a case-esac
construct.
Remove now mis-leading and incorect comment.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Both core pass-1 and -2 compilers are unconditionally built,
so we no longer require a condition variable.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Up until now, all conditions requiring a core pass-1 was when the
threading implementation used was NPTL. So we only built the core
pass-1 when NPTL was used.
Now, things have changed (what? when? Dunno...), and some bare-metal
canadian toolchains fail to build if a core pass-1 is not present.
OTOH, a core pass-1, although not needed for non-NPTL builds, does
no harm at all if it is present.
So, unconditionally build a core pass-1 (but still pass conditional
options to the core backend).
Reported-by: Per Arnold Blaasmo <Per-Arnold.Blaasmo@atmel.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Because we now patch configure.in and configure, the Makefile quicks
in a re-build rule as the source files are now more recent than the
bundled generated files, and that fails because the m4 directory
is missing, although on some systems where aclocal is not installed,
the re-build rule does nothing (except a warning).
Always create tht directory.
Reported-by: Per Arnold Blaasmo <per-arnold.blaasmo@atmel.com>
[Also thanks to Thomas De Schampheleire <patrickdepinguin@gmail.com>
for some digging works on this issue]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
gdbserver >= 7.2 comes with an optional library to use tracepoints, the
In Process Agent (IPA) library, libinproctrace.so.
Currently, we build gdbserver staticaly, but that breaks the build of
the IPA lib.
Add an option to biuld the IPA lib, but not if statically linking.
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
During application development it is desirable to enable malloc
debugging and LD_DEBUG support, but the extensive debug spew from
SUPPORT_LD_DEBUG_EARLY is only useful when working on
uClibc's ld.so.
Signed-off-by: Johannes Stezenbach <js@sig21.net>
Currently, we rely on an existing external cross-compiler targetting
the target, to build the C library.
This can pause quite a few problems if that compiler is different from
the one we are building, because it could introduce some ABI issues.
This patch removes this dependency, by building the core compilers
as we do for standard cross, and also by building the binutils and
gcc, for running on the build machine.
This means we no longer need to offer the cross-sompiler selection in
the menuconfig.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Bizarrely enough, the core gcc are not enough to be able to build a
canadian cross, and a real, full cross compiler is required so that
the canadian cross can be properly built... WTF?!? Sigh...
Add a build-frontend, as was done for the binutils and the complibs.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Do for the final step the same as for the core step: compute the list
of selected langauages from the frontend, not in the backend.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
As the core backend can be used to also build the bare-metal compiler,
we have to tel it what languages to build.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Add a function that prepares the language configure option.
It is needed in at least two places, some commonalisation is needed. ;-)
Unfortunately, it is no longer possible to print warnings about experimental
languages any more. Anyway, the experimental status is clearly indicated
in the menuconfig. so it should not be a surprise if the build breaks. :-/
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
It's easier to have as much as possible stuff in the same place to
ease backup/restore, and make things easier to follow.
Move the host companion libraries install dir as a sub-dir of the
build-tools install dir (but not directly in it, it would break
for canadian or cross-native).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
A few noop fix-ups:
- fix the comments in core pass-1
- commonalise settings that can be
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
In canadian-cross, we need the companion libraries running on the
build machine, to be able to build the two core gcc.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
In canadian-cross, we need binutils running on the build machine to be
able to build the target C library.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Move the actual complibs codes to backend functions that builds the
required combo of build/host/target as requested by a frontend.
This split is currently a no-op, but is required for the upcoming
canadian-cross rework, where we'll be needing to build the complibs
twice, one for build/build, and one for build/host.
This applies to the six companion libraries:
- GMP
- MPFR
- PPL
- Cloog/PPL
- MPC
- libelf
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Move the actual binutils code to a backend function that builds the
required combo of build/host/target as requested by a frontend.
This split is currently a no-op, but is required for the upcoming
canadian-cross rework, where we'll be needing to build two binutils,
one for build/build/target, and one for build/host/target.
This applies to the three binutils:
- GNU binutils
- elf2flt
- sstrip
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The core compilers are used to build the C library, so they
should always run on the build machine, not on the host.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
There really is no good reason to install the core compilers in their
own places, one for each pass. We can install them with the other
build tools.
Also, this implies that:
- there are fewer directories to save/restore
- there are fewer symlinks to create for binutils
- the PATH is shorter
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
When building a canadian-cross, the binutils are not executable on
the build machine, so there is no point in installing the symlinks
in the gcc static/shared install dirs.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
strace upstream location has slightly changed.
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Since anciens.enib.fr has been dead for two months now, without any
hope of recovery, update my e-mail to point to @free.fr instead.
Reported-by: "Bryan Hundven" <bryanhundven@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
The build dir are created depending on the host (host for that specific
backend, not host for the toolchain). Only the frontends know what host
this is, so only the frontends can create non-ambiguous dirs.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The only user of the static core compiler in pass-1 was the newlib
C library. Now that it is build in a later step, we do no longer
need to build a static core compiler in pass-1.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Currently, newlib is built in the start_file step, which is wrong, but was
needed when the baremetal integration was... well, 'unfinished'.
Now that we build the baremetal compiler from the final cc step, and a
proper core gcc in pass-1 and pass-2, we can move the newlib build to the
step do_libc, where it belongs.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
In case we build a baremetal compiler, use the standard passes:
- core_cc is used to build the C library;
- as such, it is meant to run on build, not host;
- the final compiler is meant to run on host;
As the current final compiler step can not build a baremetal compiler,
call the core backend from the final step.
NB: Currently, newlib is built during the start_files pass, so we have
to have a core compiler by then... Once we can build the baremetal
compiler from the final cc step, then we can move the newlib build to
the proper step, and then get rid of the core pass-1 static compiler...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Currently, we issue the bare-metal compiler from the pass_1 & pass_2
core compilers, because the final gcc breaks while doing so.
This implies we have to build some libces during the start_files step,
instead of the standard libc step. This is the case for newlib.
By adding a backend/frontend infra to the final gcc, we can abstract
what backend to call: the standard backend for non-bare-metal gcc,
and the core backend for bare-metal.
This patch is just an no-op, it just adds the final backend and
frontend without changing the way bare-metal is built, to come in a
subsequent patch.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
As the core backend is used to generate the bare-metal compiler,
we need to pass it the host CFLAGS.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Tell the core compiler what host it should run on (instead of
hard-coding runing on CT_HOST).
No functional change so far, switching between CT_HOST and CT_BUILD
will come in a following patch.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Currently, the discrimination on the core compilers prefixes depends on
the type of core compiler to build.
This is not correct, and the caller of the core backend should specify
the prefix.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
In case of canadian-cross, the companion libraries are not the same for
the core cc (they run on 'build') as they are for the final cc (they run
on 'host').
Prepare for this differentiation (coming later), while retaining the
current behavior (to use the same compblibs).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Rename the core backend function to do_cc_core_backend, to
make it explicit it is a backend.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The core backend is going to have more parameters in the upcoming
patches, so it will be a bit complex to handle.
Introduce an array-variable that is filled by the different code-paths
with the required values.
This makes the code easier to read and maintain.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The current construct consumes the parameters while we parse them.
Change this to a construct that does not consume the parameters.
This has no impact on gcc, but is done for homogeneity with other
components (eg. glibc).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Currently, there are two constructs used to parse arguments in
glibc backends, one that consumes args as they are parsed, and
one that does not.
Always use the construct that does not eat args as they are parsed.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
It seems sourceforge changed yet again the way to download files.
This time, no longer use their 'mesh' thingy, and hard-code the
server to use in the URL... Sigh... :-(
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
sim was already disabled for CT_GDB_NATIVE.
Reviewed-by: Michael Hope
Signed-off-by: Zhenqiang Chen <zhenqiang.chen@linaro.org>
[yann.morin.1998@anciens.enib.fr: make it a config option]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
In Ubuntu 11.04 and 11.10, the default options for ld have changed.
--no-copy-dt-needed-entries and --as-needed are now enabled by default, which
causes errors like:
[EXTRA] Checking CLooG/ppl
[DEBUG] ==> Executing: 'make' '-j3' '-s' 'check'
[ALL ] Making check in .
[ALL ] config.status: creating include/cloog/cloog-config.h
[ALL ] config.status: include/cloog/cloog-config.h is unchanged
[ALL ] libtool: link: i686-build_pc-linux-gnu-gcc -Wall -fomit-frame-pointer
-pipe -o cloog cloog.o -L/<snip>/build/static/lib ./.libs/libcloog.a -lm
/<snip>/build/static/lib/libppl_c.a /<snip>/build/static/lib/libpwl.a
/<snip>/build/static/lib/libppl.a /<snip>/build/static/lib/libgmpxx.a
/<snip>/build/static/lib/libgmp.a -lstdc++
[ALL ] /usr/bin/ld: /<snip>/build/static/lib/libppl.a(MIP_Problem.o):
undefined reference to symbol 'sqrt@@GLIBC_2.0'
[ALL ] /usr/bin/ld: note: 'sqrt@@GLIBC_2.0' is defined in DSO
/usr/lib/gcc/i686-linux-gnu/4.6.1/../../../i386-linux-gnu/libm.so so try adding
it to the linker command line
[ALL ] /usr/lib/gcc/i686-linux-gnu/4.6.1/../../../i386-linux-gnu/libm.so:
could not read symbols: Invalid operation
[ALL ] collect2: ld returned 1 exit status
[ERROR] make[2]: *** [cloog] Error 1
[ERROR] make[1]: *** [check-recursive] Error 1
See:
https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition
This patch fixes these errors by placing '-lm' at the right place on the command
line as libppl requires libm when linking cloog.
Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
Installing the gcc test-suite can take a bit of time, so the
progress bar is currently not rotating because there is no
output during the copy. For an unsuspecting user, it could
mean the process hung.
With 'cp -v', the progress bar now rotates.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
When doing multilib, we only need the headers from the default variant,
but we need the startfiles for each variants.
Allow the frontend to specify either one, or both.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
For mutlilib, the C library must be built once for each variants.
Special care must be taken to put the resulting libraries in
the proper places.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
When building a multilib variant, install in a separate directory, to
avoid clutering the default or any other variant.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
When building a multilib, some extra CFLAGS can override the
default config option. This is the case for the endianness
selection.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
When building a multilib, some extra CFLAGS can override the
default config option. This is the case for the floating point
selection.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
When building multilib, we need extra CFLAGS that tell the compiler
to use non-default settings (eg. big/little endian, hard/soft float,
-march/cpu/tune flags, and so on...).
We have to pass these flags to the build.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The caller SHALL explicitly ask for a nmode, and not rely on a default mode.
That's what actually happens, so we can get rid of the default.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
In some cases, it might be desirable to use the system zlib
Eg. because latest gcc seem to be totally borked when it comes
to multilib, and tries to build a multilib host zlib, when it
is *absolutely* *not* needed: we want mulitlib on the target,
not on the host! Sigh... :-(
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The localedef of eglibc 2.14 requires NOT_IN_libc to be defined in order to
compile intl/l10nflist.c.
This is because localedef is built separately from eglibc and uses some parts of
eglibc that don't compile in standalone without this preprocessor definition.
This fixes the following error:
[ALL ] gcc -g -O2 -DNO_SYSCONF -DNO_UNCOMPRESS
-DLOCALE_PATH='"/usr/lib/locale:/usr/share/i18n"'
-DLOCALEDIR='"/usr/lib/locale"' -DLOCALE_ALIAS_PATH='"/usr/share/locale"'
-DCHARMAP_PATH='"/usr/share/i18n/charmaps"'
-DREPERTOIREMAP_PATH='"/usr/share/i18n/repertoiremaps"'
-DLOCSRCDIR='"/usr/share/i18n/locales"' -Iglibc/locale/programs -Iglibc/locale
-I/<snip>/.build/src/eglibc-localedef-2_14/include
-I/<snip>/.build/src/eglibc-localedef-2_14 -I.
-include /<snip>/.build/src/eglibc-localedef-2_14/include/always.h -Wall
-Wno-format -c -o locarchive.o glibc/locale/programs/locarchive.c
[ALL ] glibc/locale/programs/locarchive.c: In function 'enlarge_archive':
[ALL ] glibc/locale/programs/locarchive.c:303:21: warning: variable
'oldlocrectab' set but not used [-Wunused-but-set-variable]
[ALL ] In file included from glibc/locale/programs/locarchive.c:651:0:
[ALL ] glibc/locale/programs/../../intl/l10nflist.c: In function
'_nl_normalize_codeset':
[ERROR] glibc/locale/programs/../../intl/l10nflist.c:342:9: error:
'_nl_C_locobj_ptr' undeclared (first use in this function)
[ALL ] glibc/locale/programs/../../intl/l10nflist.c:342:9: note: each
undeclared identifier is reported only once for each function it appears in
[ALL ] glibc/locale/programs/locarchive.c: In function
'add_locales_to_archive':
[ALL ] glibc/locale/programs/locarchive.c:1450:7: warning: passing argument
1 of '__xpg_basename' discards 'const' qualifier from pointer target type
[enabled by default]
[ALL ] /usr/include/libgen.h:35:14: note: expected 'char *' but argument is
of type 'const char *'
[ERROR] make[1]: *** [locarchive.o] Error 1
Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
Signed-off-by: Zhenqiang Chen <zhenqiang.chen@linaro.org>
[yann.morin.1998@anciens.enib.fr: copy with a single call to 'cp']
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The changeset 2467 #200836977ce6 missed renaming one occurrence of
CT_BINUTILS_EXTRA_CONFIG to CT_BINUTILS_EXTRA_CONFIG_ARRAY, which is fixed by
this patch.
Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
Some longterm versions are not in the usual directory.
Account for these new locations.
Get rid of the mirror location, now that the main kernel site is
(almost) back to normal operations.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
With hard-coded "-O", users can not customize CFLAGS_FOR_TARGET
by CT_TARGET_CFLAGS. If "-O" is needed, users can input it in
CT_TARGET_CFLAGS. By default, "-Os" is enabled.
Signed-off-by: Zhenqiang Chen <zhenqiang.chen@linaro.org>
Signed-off-by: Zhenqiang Chen <zhenqiang.chen@linaro.org>
[yann.morin.1998@anciens.enib.fr: prompt rewording, as suggested by M. Hope]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Otherwise, users have to input --disable-libstdcxx-pch option
when building bare-metal CANADIAN C++ compiler.
Reviewed-by: Michael Hope
Signed-off-by: Zhenqiang Chen <zhenqiang.chen@linaro.org>
Add support for building the HTML and PDF manuals for the major
components. Implement for binutils, GCC, GDB, and GLIBC.
Always build all manuals and install a subset. Be explicit about the
subset to reduce the clutter and to avoid getting copies of common
manuals like bfd from all of the sourceware based components. Downside of
being explicit is that you need to update it when a new component
comes along.
Build the manuals as part of the last GCC build, namely 'cc' for glibc
based ones and cc_core_pass_2 for baremetal.
An example of the output is at:
http://people.linaro.org/~michaelh/incoming/crosstool-NG/
Signed-off-by: Michael Hope <michael.hope@linaro.org>
[yann.morin.1998@anciens.enib.fr: depends on ! remove docs; gold manual install]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
In the early days, cloog-ppl was bizarrely packaged: the first tarball
did not contain the version in the name of the extracted directory, so
we had to play tricks.
Nowadays, however, the first component of the path are stripped when
extracting a tarball, which means that the created directory will
always be properly named. So, our old tricks do no longer work, and
worse, they break the build.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
ncurses 5.9 wants tic to be either one of:
- $TIC_PATH
- /usr/bin/tic
Of course, se do not want the latter, for it can be incompatible if the
ncurses in the build system is too old (eg. RHEL 5.6, Debian Lenny...).
So, force TIC_PATH to the location of our own tic.
Also, install tic alongside the other build tools, not in a sub-dir
of the toolchain installation dir.
Signed-off-by: Willy Tarreau <w@1wt.eu>
[yann.morin.1998@anciens.enib.fr: install in builtools/bin, move TIC_PATH]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Some architectures support a mixed hard/soft floating point, where
the compiler emits hardware floating point instructions, but passes
the operands in core (aka integer) registers.
For example, ARM supports this mode (to come in the next changeset).
Add support for softfp cross compilers to the GCC and GLIBC
configuration. Needed for Ubuntu and other distros that are softfp.
Signed-off-by: Michael Hope <michael.hope@linaro.org>
[yann.morin.1998@anciens.enib.fr: split the original patch]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
With the upcoming softfp support, the case..esac test would become
a bit convoluted if it were to test three different booleans.
Introduce a new blind string config option that defaults to the
selected floating point type used.
Signed-off-by: Michael Hope <michael.hope@linaro.org>
[yann.morin.1998@anciens.enib.fr: split the original patch]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Changeset #7c288c777455 broke the tuple for uClibc-based
powerpc toolchains, by unconditionally forcing CT_TARGET_SYS
to "gnu".
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Tremendously helps when running on at least Ubuntu, with dash as
the system shell (ie. /bin/sh points to dash).
Reported by a few people, of which:
leming, ccct and ccole on IRC
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Add a new option to enable/disable the Python scripting in gdb.
Hide the option (ie. disable it) when statically linking the cross-gdb.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The GOLD linker is written in C++. Pass CT_CFLAGS_FOR_HOST as
CXXFLAGS to configure so that any host specific flags are passed
through.
It feels a bit funny passing CFLAGS as CXXFLAGS, but the PPL and GCC
target rules already do the same.
Signed-off-by: Michael Hope <michael.hope@linaro.org>
Allows using either a tarball or a directory as the custom kernel
source location.
Signed-off-by: Vincent BENOIT <sinseman44@gmail.com>
[yann.morin.1998@anciens.enib.fr: fix space damage, detailed commit message]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Since kernel.org is dead, and there is no announced or known estimated
time or return to normality, it is impossible to download any kernel at
this time.
Add a known-working mirror.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Even if the current process is highly parallel, crosstool-NG spends most
of its time in single-job steps on fast machines (with a 12-CPU system,
I approximate the parallel vs. non-parallel time to be in the order os
1 to 3; that is crostool-NG spends two-thirds of its time running
non-parallel jobs).
Some steps to build gcc can be paralleled, gaining a litle bit of time
on the whole compilation.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Allows to choose if one wants to keep or not the syscalls that are provided with
newlib. It passes the --disable-newlib-supplied-syscalls or
--enable-newlib-supplied-syscalls to the configure script. If one chooses to
disable the builtin syscalls, he/she will have to write his/her own. This can
be usefull to port newlib to a new platform/board.
Signed-off-by: Kévin PETIT <kpet@free.fr>
HOST_OS really is the target OS. Allow setting it for configure
via an environment variable.
libltrace.a should have an index:
Allow ar to be set as an environment variable, and generate
an index in this lib.
Reported-by: "Guylhem Aznar" <crossgcc@guylhem.net>
Signed-off-by: "Titus von Boxberg" <titus@v9g.de>
Because we need our own host tic, we have to build it; and we do build
it statically for now.
But as MacOS/Darwin/Whatever-you-call-it does not support static linking
(what a shame!), it fails.
Anyway, we don't really care it being shared, in the end.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The custom-tarball symlink was created in CT_SRC_DIR, when it
should be created in CT_TARBALLS_DIR.
Reported-by: Guylhem Aznar <crossgcc@guylhem.net>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Simplify the way the custom tarball is handled:
- fake version="custom"
- at download, simply link the custom tarball to:
"linux-custom.${custom_extension}"
- at extract, the above allows to simply extract "linux-${LINUX_VERSION}"
where LINUX_VERISON is set to the fake version="custom"
Not that much convoluted, in fact... :-/
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Although ctor/dtor do not seem strictly required, missing them proves
rather inconvenient, as ld can't link binaries.
Reported-by: John Spencer <maillist-uclibc@barfooze.de> (sh4rm4 on IRC)
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
do_libc_locales_extract() and do_libc_locales() in glibc-eglibc.sh-common have
been overridden for both glibc and eglibc, so they can now be removed, which
this patch does.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
This patch adds partial support for glibc locales.
For now, it only generates the appropriate locales when the host and the target
have the same endianness and uint32_t alignment.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
This patch adds a common glibc/eglibc infrastructure to build and install the
libc locales.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
Someof the mingw32 source tarballs have an appended '-src' after the
version.
Since changeset #6e1412ba8da9 (scripts/functions: force extract folder
to archive basename), it means mingw tarballs get extracted in a directory
ending with '-src'.
Fix that.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Now that we akways extract the tarballs in a sane location (see changeset
#6e1412ba8da9: scripts/functions: force extract folder to archive basename),
the uClibc snapshot dir now has the date (as version) in it, eg.:
uClibc-20100710
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Currently, no --enable-add-ons option is passed to libc configure when
"$(do_libc_add_ons_list ,)" is empty, which makes configure automatically search
for present add-ons. In that case, all present add-ons are built, although
no add-on was selected by the user in the config. Moreover, this can make the
configure fail if some non-standard add-ons like eglibc-localedef are present.
This behavior also leads to an inconsistency from a user point of view between
the following cases:
- LIBC_ADDONS_LIST="", LIBC_GLIBC_USE_PORTS=n and THREADS="none" in the config,
which makes "$(do_libc_add_ons_list ,)" return "", so all present add-ons
are built.
- LIBC_ADDONS_LIST="", LIBC_GLIBC_USE_PORTS=n and THREADS!="none" in the
config, which makes "$(do_libc_add_ons_list ,)" return the add-on supporting
the chosen threading implementation, e.g. "nptl", so only this add-on is
built.
This patch disables the building of all add-ons in that case.
It is still possible to build all present add-ons by adding --enable-add-ons to
LIBC_GLIBC_EXTRA_CONFIG_ARRAY.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
gdb needs to know where to find the libstdc++ helper python script
to do, well, whatever it has to do with it...
We can't install that in the user's ~/.gdbinit, it's too complex to
handle all the cases. Moreover, if the user is using more than one
toolchain, we can't put all that stuff in there...
Just provide a sample config file the user can adapt to his/her
own needs.
Thanks go to Khem RAJ for providing such a hint:
http://sourceware.org/ml/crossgcc/2011-07/msg00026.html
Reported-by: ANDY KENNEDY <ANDY.KENNEDY@adtran.com>
CC: Khem Raj <raj.khem@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
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>
