While building a canadian toolchain for windows host (any target),
the build failed for m4 host companion_tool with a recent mingw-w64
(at least 7.0.0).
m4 needs stack smashing protection which is not part of mingw-w64 c
library and an explicit trigger to link w/ libssp is needed.
Signed-off-by: Florent Valette <florent.valette@gmail.com>
- Force building make as a companion tool if host make is older than
4.0 (CentOS 7 currently has 3.82)
- Disable 2.29 as a choice if host python is older than 3.4
(CentOS 7 has 2.6 unless python from EPEL is installed)
- Python2 emits its version information to STDERR. Ugh.
While there, also use the detected host Python for GDB configuration.
Signed-off-by: Alexey Neyman <stilor@att.net>
make's configure uses pkg-config to detect if Guile should be enabled;
on ArchLinux, this picks up Guile from build machine's pkgconfig and then
it fails to compile.
A better solution might be to create a ${CT_HOST}-pkg-config in
buildtools/bin that would report "unsupported" for all packages.
However a quick grep only showed pkg-config being used by GCJ
(not sure if it will build in canadian cross - we don't have any
samples with GCJ) and Blackfin simulator in GDB (Blackfin is not
currently supported by crosstool-ng). Hence, leave such pkg-config
implementation and testing for another day.
Signed-off-by: Alexey Neyman <stilor@att.net>
Allow selection of make/m4/... version. Support imports of new versions
via addToolVersion.sh. Import newest versions of the companion tools.
One non-trivial change is the handling of make versions. Existing code
was not handling make companion tool as described (see the previous
commit). However, since most modern systems have make 4.x, that previous
commit made crosstool-ng always build make as a companion tool.
This traces back to the commit dd15c93 from 2014. That commit's log message
says that actually it was 3.81 which broke the build for certain component
(it was originally breaking eglibc, but I noticed it was breaking current
glibc on powerpc64), and introduced an option to force using 3.81 by
"components that really need it". It looks like in 2.5 years we haven't
seen any such components that really need make 3.81, and (given that make
has already had a few releases since 3.81) we're unlikely to see them
in the future.
Hence, the configure check is changed from "exactly 3.81" to "3.81 or newer".
In its current form, configure will accept make 3.80+, and will not require
make as a companion tool for 3.81+. We might want to bump the latter check
to even newer version given the claim from dd15c93. Killed
COMP_TOOLS_make_3_81_NEEDED.
Anyway, I retained 3.81 just in case; ditto for m4 1.14.3, autoconf 2.65
and automake 1.11.1.
Signed-off-by: Alexey Neyman <stilor@att.net>
The referenced commit replaced 'make' with '${make}' everywhere. This is
wrong for at least the utilities that we may build as companion tools
(make, libtool): this will always invoke the version detected by configure
by supplying the absolute path. In other words, the wrappers in
.build/tools/bin are not fallbacks - they are either temporary (in case
a respective companion tool is built) or permanent redirectors.
This is the reason why the PATH= has .build/*/buildtools/bin at higher
precedence than .build/tools/bin; the latter has the versions detected by
configure and the former has the versions built as companion tools.
Revert the rest of the gang (grep/sed/...) for consistency. After all,
we may decide to supply some of them as well (awk, for instance).
Signed-off-by: Alexey Neyman <stilor@att.net>
Commit 6f8e89cb5c broke that option.
Since ${make} points to /usr/bin/make, making the symlink from gmake
to /usr/bin/make is obviously the wrong decision. gmake should link to
our (old-versioned) self-built make.
Signed-off-by: Bernhard Walle <bernhard@bwalle.de>
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>
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>
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>
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>
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>
I ran into some minor difficulties looking through the build log for a
particular file: I wasn't interested in seeing it unpacked, but only
when it is built or installed. Adding these two levels allows me to
differentiate between those cases.
[Yann E. MORIN: Those are blind log levels, and are used only to search
in the build-log afterward.]
Signed-off-by: Anthony Foiani <anthony.foiani@gmail.com>
Initial version of adding autoconf as a companion tool.
Signed-off-by: Richard Strand <richard.strand@icomera.com>
[yann.morin.1998@anciens.enib.fr: use generic overide tools dir]
[yann.morin.1998@anciens.enib.fr: update menu entries]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
