The current mechanism to check if static linking is possible, and the mesage
displayed on failure, can be puzzling to the unsuspecting user.
Also, the current implementation is not using the existing infrastructure,
and is thus difficult to enhance with new tests.
So, switch to using the standard CT_DoExecLog infra, and use four tests to
check for the host compiler:
- check we can run it
- check it can build a trivial program
- check it can statically link that program
- check if it statically link with libstdc++
That should cover most of the problems. Hopefully.
(At the same time, fix a typo in a comment)
Signed-off-by: Daniel Price <daniel.price@gmail.com>
[yann.morin.1998@free.fr: split original patch for self-contained changes]
[yann.morin.1998@free.fr: use steps to better see gcc's output]
[yann.morin.1998@free.fr: commit log]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <163f86b5216fc08c672a.1353459722@nipigon.dssd.com>
Patchwork-Id: 200536
Signed-off-by: Daniel Price <daniel.price@gmail.com>
[yann.morin.1998@free.fr: split original patch for self-contained changes]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <163f86b5216fc08c672a.1353459722@nipigon.dssd.com>
Patchwork-Id: 200536
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
The extra CFLAGS override the product defaults, causing the product to
be built without optimisation or debug. Be explicit and add these in.
Reported-by: Johannes Stezenbach <js@sig21.net>
Signed-off-by: Michael Hope <michael.hope@linaro.org>
Message-Id: <CANLjY-=3Gbio6nzUPhhevDHV7cUN=6Vigooe9nSf-RnGCqnjog@mail.gmail.com>
Patchwork-Id: 198808
Add an option that, when a command fails:
- starts an interactive shell with the failed command's environment
- attempts re-execution of the failed command, continues, or aborts
at user's whim.
Before starting the debug-shell, the backtrace is printed.
When exiting for an abort, the standard error message is printed.
Based on an idea and a patch from: Johannes Stezenbach <js@sig21.net>
http://sourceware.org/ml/crossgcc/2012-09/msg00144.html
Signed-off-by: Johannes Stezenbach <js@sig21.net>
[yann.morin.1998@free.fr: integrate in the fault handler]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: Johannes Stezenbach <js@sig21.net>
Patchwork-Id: 191571
Patchwork-Id: 191668
Avoid error when commands in scripts/crosstool-NG.sh fail
before CT_BUILD_DIR is set.
So we need to remove the backtrace marker of a potential previous
build. Previously, it was implicitly removed because we did remove
the directory it was in, which is no longer the case.
Signed-off-by: Johannes Stezenbach <js@sig21.net>
[yann.morin.1998@free.fr: remove backtrace marker on start of build]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <20121015094615.GA18673@sig21.net>
Patchwork-Id: 191498
It's been a long time the default work-dir changed its name
from 'target' to '.build'.
Change the left-over.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
If either LIBRARY_PATH or LPATH is set, even to the empty string,
the gcc build breaks.
Fix that by bailing-out rather than re-setting.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
These environment variables set search path for gcc at link time, which can break the build.
Signed-off-by: Erik Inge Bolsø <knan-ct@anduin.net>
Message-Id: <alpine.BSF.2.00.1205130131550.21551@anduin.net>
PatchWork-Id: 186872
POSIX 1003.1-2008 does not say whether "set -e" should catch a sub-shell
that exits with !0 (it has a list of conditions to catch, but no list of
conditions not to catch, and this situation is not listed).
bash-3 does not catch such a failure, but bash-4 does. That why, on my
Squeeze system I did not see the issue, while Thomas did on is Lenny chroot.
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
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>
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>
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>
The tools found by the new autostuff configure can contain arguments,
for example: grep -E
This needs separating the paths set for the Makfile from the paths
set for the scripts.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Some distributions (eg. openSUSE 12.1) systematically export
the CONFIG_SITE environment variable to point to a custom
script setting misc paths for ./configure.
This can, and does, break when cross-compiling for architectures
that are not supported by this script.
The simple workaround is to unset this variable.
NB: buildroot has a similar fix:
http://git.buildroot.org/buildroot/commit/?id=12c9f7dd6dee9c6029b4f9a12d6aac1516911ab4
Reported-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
"${CT_SYSROOT_DIR}/usr/include" is only for "${CT_USE_SYSROOT}" = "y".
We should also mkdir when "${CT_USE_SYSROOT}" != "y".
"${CT_HEADERS_DIR}" can support both cases.
Signed-off-by: Zhenqiang Chen <zhenqiang.chen@linaro.org>
CT_SHELL is undefined.
Thus, the generated wrapper scripts are not executable by the kernel
because they do not contain a valid interpreter.
Use CT_CONFIG_SHELL instead.
Signed-off-by: "Titus von Boxberg" <titus@v9g.de>
CT_EXTRA_FLAGS_FOR_HOST needs a preceding space to separate it from
any other options that have already been set.
Signed-off-by: Michael Hope <michael.hope@linaro.org>
Currently, we check host feature in ./configure. This works only for
cross toolchains, but not for canadian toolchains. ./configure has
absolutely no way to know what the host for the toolchain will be;
only the build scripts know.
So, move the headers & libraries checks from ./configure to the build
scripts, early enough in the build, but not before we know the host
compiler and other tools.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
To avoid variable leakage from one step to another, isolate the
steps from each others by running them in their own sub-shell.
This avoids variables leaking from one step to the others.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Allow the user to configure extra flags to pass to the host compiler
at build time. Applies to both C and C++.
Useful on Ubuntu to turn off the stack protector and fortify defaults
so the program stands a better chance of running on other distros.
Signed-off-by: Michael Hope <michael.hope@linaro.org>
[yann.morin.1998@anciens.enib.fr: put the custom flags at the end]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
When CT_PARALLEL_JOBS is -1, set the number of parallel jobs to the
number of online CPUs + 1. Update documentation to match.
I find this useful when building in the cloud. You can use the same
.config file and have the build adapt to the number of processors
available. Limited testing shows that NCPUS+1 is faster than NCPUS+0
or NCPUS+2.
Signed-off-by: Michael Hope <michael.hope@linaro.org>
The sysroot prefix dir was broken in #4960f5d9f829 due to a mishap
when making the out-of-sysroot lib/ symlink: the './' was mistakenly
changed into a single '.' .
Although Jonathan suggested restoring the missing '/' to restore it to
normal operation, I prefered using an explicit pushd/popd to be extra
sure of the symlink location and target, along with a fix in the sysroot
relative directory calculation.
Reported-by: Jonathan Grundon <JGrundon@xos.com>
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>
In case there's one lingering around (whether the previous build was
successful, or failed), we have to remove the buildtools directory
as well as the toochain build dir.
This should also fix the case where out makeinfo wrapper calls
itself recursively.
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>
Transfrom array variables from pure strings (in the kconfig output)
into proper bash arrays declarations, for feeding to the build scripts.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
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>
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>
Users tend to look for the build log in the current working directory,
rather than in the toolchain's installation dir. While bundling the build
log in the toolchain installation dir is nice for distribution and review,
it can be easier to have the build log readily available in the working
directory, as it is quicker to get to it.
So, the build log stays in the working directory until the toolchain is
completely and successfully built, and then a (compressed) copy is made.
Reported-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Consider the buildtools install directory as a prefix directory,
that is, install buildtools in prefix/bin/, not in prefix/.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
There is absolutely *no* reason for the buildtools (wrappers to gcc, g++,
as, ld... for the local machine) to be in the toolchain directory. Moreover,
they are removed after the build completes.
Move them out of the toolchain directory, and into the build directory (but
yet the part specific to the current toolchain). This means we no longer
need to explicitly remove them either, BTW, but we need to save/restore them
for the restart feature.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Currently, the buildtools are installed relative to ${CT_PREFIX_DIR}.
Change that by introducing ${CT_BUILDTOOLS_DIR}, which is
still set relative to ${CT_PREFIX_DIR}, but which will make it easy
to change in the future.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
If we set PATH to the tools wrappers before we create the
makeinfo wrapper, then we may well wrap an existing wrapper
from a previous run.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
In certain circumstances, removing the destination/installation directory
is a bad idea. For example, when the build environment is already taking
care of sanitising the build tree, and pre-installs stuff in there, it is
a very bad idea to remove the destination directory.
This happens now in buildroot, as the crostool-NG backend now installs the
toolchain in the common host-tools directory, and pre-install there a few
host-utilities (eg. host-automake and host-gawk).
Provide a config knob to turn on/off the removal of the destination
directory, defaulting to 'y' (previous behavior), and forced to 'n' when
used as a backend.
Reported-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Computed paths may contain double slashes.
This is not an issue but it is just ugly to look at.
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>
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>
On some systems, we also need to overide LANG as well as LC_ALL.
Reported-by: Geoffrey Lee <geoffl@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Unconditionally create the lib32 -> lib/ and lib64 -> lib/ symlinks.
This is reportedly a fix to build a toolchain for a 32-bit target on
a 'pure' 64-bit host (eg. on Fedora FC12, host libs are in lib64/,
and there is no lib -> lib64 symlink, as we can see on other distors,
as Debian). As gcc only puts static host lib in lib64/ (along with
target files in subdirs), we can safely create the symlinks.
Also note that the symlinks are summarily removed at the end
of the build.
Signed-off-by: Anthony Foiani <anthony.foiani@gmail.com>
[Yann E. MORIN: fix a comment, rephrase the commit log]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
