This reverts commit 658f5e574f, which
was made without any justification, and prevents using crosstool-ng
even in decently recent distributions like Ubuntu 20.04 (which has
autoconf 2.69).
We have tested that ./bootstrap && ./configure --enable-local works
fine on Ubuntu 18.04, which uses autoconf 2.69 and automake 1.15, so
the existing requirements were enough.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
https://sourceware.org/pipermail/binutils/2022-August/122246.html
Add binutils 2.39 and regenerate patches.
0008-binutils-2.38-vs.-ppc32-linux-kernel.patch is dropped as it has
been applied upstream. Add a milestone for 2.39 which will be handy for
Loongarch.
Binutils now requires bison >= 3.0.4 to build gprofng for x86/aarch64 so
we build our own bison when the host bison does not meet that
requirement (which appears to be the case on macOS).
Signed-off-by: Chris Packham <judge.packham@gmail.com>
It appears that noyywrap is actually what is needed for kconfig.
Particularly on arclinux where the default flex installation does not
provide the yywrap function.
Fixes#1790
Fixes 015d039e ("AC_PROG_LEX set to yywrap")
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Make the requirement for bison harder (but not strict). The system bison
will be used to build kconf. If the system bison is not GNU bison 2.7 or
later crosstool-ng will build GNU bison as a companion tool if necessary
(for glibc 2.29 or newer).
Fixes#1621
Signed-off-by: Chris Packham <judge.packham@gmail.com>
BSD patch does not support --no-backup-if-mismatch. When we detect patch
check that it supports the option we use.
Fixes: #1577
Signed-off-by: Chris Packham <judge.packham@gmail.com>
As of Linux v5.3 rsync is used as part of the build process. Add Linux
5.3 as a milestone, configure detection of rsync and a dependency on
rsync for Linux 5.3 and newer. Add a comment in so that users can tell
why they can't select a newer version.
Fixes#1628
Signed-off-by: Chris Packham <judge.packham@gmail.com>
This adds support for using picolibc instead of newlib on embedded
systems.
Signed-off-by: Keith Packard <keithp@keithp.com>
v2:
Add check for meson and ninja
Sync option default values with current picolibc defaults
Remove xtensa sys header file install as those aren't in picolibc
... unless one retrofits it with a decent compiler instead of stock
GCC 4.4.
While here, sync up the ax_*.m4 with autoconf-archive.
Signed-off-by: Alexey Neyman <stilor@att.net>
- 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>
Ideally, we should just skip the archives for which we don't have the
utilities; let's leave it until I convert the "trivial checks" part of
crosstool-NG.sh into a separate configure script.
Signed-off-by: Alexey Neyman <stilor@att.net>
glibc build requires GNU bison >= 2.7 but Apple ships bison 2.3. If we
provide an override for GNU bison it should be possible to use a version
from homebrew.
Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
As we support CentOS, for example, we have a problem there
automake: warnings are treated as errors
kconfig/Makefile.am:26: warning: compiling 'lxdialog/checklist.c' in subdir requires 'AM_PROG_CC_C_O' in
'configure.ac'
autoreconf: automake failed with exit status: 1
Automake does not allow us to place the hooks before its generated actions,
and does not allow us to check MAKECMDGOALS, and does not support a mechanism
for disabling make install (such as noinst_SUBDIRS, requested a few times
on automake mailing list). The only way I could preserve the current behavior
is to have a GNUmakefile wrapper that will convert MAKECMDGOAL into a variable
unknown to automake - which seems too convoluted a solution for the problem
being solved.
Hence the approach is to not override anything for --enable-local. It is now
fully handled by selecting different values for CT_xxx_DIR in ct-ng.in; but
at the build-system level, all the variables remain the same. We just don't
support 'make install' in that case anymore; but the ct-ng in the working
copy can be used after a regular 'make' (or 'make all').
Help message for --enable-local updated accordingly.
Signed-off-by: Alexey Neyman <stilor@att.net>
Instead, just honor CFLAGS/CPPFLAGS/LDFLAGS as they're passed down from
configure. This brings the build process in compliance with the
recommended practices.
Signed-off-by: Alexey Neyman <stilor@att.net>
They don't make sense - using same ct-ng won't work with different versions,
so they cannot coexist in the same prefix.
Also localize other configure variables so that their usage is easier to track.
Signed-off-by: Alexey Neyman <stilor@att.net>
