Three cases kept a cached answer that no longer held:
A new configure script. A package with an autoreconf fixup regenerates
configure with the staged autoconf, automake and libtool, and a new
version of one of them can change what a cache variable means. The site
script now keeps a checksum of configure beside the cache and drops the
cache when the checksum changes. A new patch to configure is covered too.
A changed precious variable. configure aborts when LIBS, CPP or another
precious variable differs from the value in the cache, and because
nothing removes the cache, it aborts on every later run as well:
configure: error: 'LIBS' was not set in the previous run
configure: error: changes in the environment can compromise the build
The site script now makes the same comparison before configure does and
drops the cache on a difference.
Paths under other names. The libtool answers lt_cv_path_*, acl_cv_path_*
and lt_cv_sys_global_symbol_*, and gmp_cv_prog_m4, hold the path of a
system tool or of the staged sed and m4, and survived a wipe of
staging_dir. The site script now drops them with the ac_cv_path_ answers.
m4 and gmp still configure the same way with a warm cache as they do
without one, and still read it: the m4 configure stage takes 1.5 s warm
against 23 s cold.
Signed-off-by: John Crispin <john@phrozen.org>
A configure run spends its time on the compiler invocations behind its
checks, not on the shell. tools/m4 runs the compiler 633 times and takes
24 seconds. ccache does not help, because it refuses to cache an
autoconf conftest compile at all; it counts these separately as
"Autoconf compile/link" under its uncacheable calls.
A package that sets PKG_CONFIGURE_CACHE or HOST_CONFIGURE_CACHE keeps a
config.cache under tmp/, so a package that is cleaned and built again
reads the answers instead of running the checks. The configure stage of
tools/m4 drops from 24.5 s to 1.5 s. dirclean removes tmp/, so a full
reset of the tree starts from cold answers.
A package has to opt in, because a cache is only correct for a configure
script that keeps its side effects outside the AC_CACHE_VAL body.
ncurses appends -D_XOPEN_SOURCE and -D_DEFAULT_SOURCE to CPPFLAGS inside
that body, so a cached run restores the value, skips the append, and
then fails to compile wcwidth. ncurses_cfg.h is identical in both cases;
the difference is in the generated Makefile.
The path covers everything else that changes an answer. A target package
is keyed on the toolchain directory, which carries the gcc version. A
host package is keyed on the version string of the host compiler,
because autoconf cannot detect a new compiler behind an unchanged name;
gcc 14 turned an implicit function declaration into an error and changed
many answers that way. Both are keyed on a hash of the configure
arguments and the build flags, and autoconf refuses a cache written with
different flags on top of that.
A cached program path outlives a wipe of staging_dir, so ac_cv_path_ and
ac_cv_prog_ answers are dropped when the cache loads and configure
searches PATH again. Without that, a cache written before staging_dir
held sed pins /usr/bin/sed for good. A search runs no compiler, so this
costs nothing that matters.
The cache arrives through a site script rather than --cache-file, so a
hand written configure script never sees a new argument. The site script
removes the file of the previous arguments, so a different configuration
gets a cold cache instead of an autoconf error. It also unsets the
variable, and make exports it for the configure stage alone, so a nested
configure run keeps its own cache.
Set CONFIGURE_CACHE_DIR to keep the cache elsewhere, or to the empty
string to run every check again.
Host builds now read a site script on Linux as well. Before this change
only Darwin had one.
CONFIG_SITE holds one path name: autoconf before 2.70 reads the whole
value as that one name, so a second path would silence both scripts. It
names the cache script alone, and the cache script loads the site script
of the architecture from CONFIG_SITE_BASE.
Signed-off-by: John Crispin <john@phrozen.org>
Add target for Loongson LoongArch64-based boards.
LoongArch is a new RISC ISA developed by Loongson. It's a bit like
MIPS or RISC-V. LoongArch includes both 32-bit and 64-bit versions
(LoongArch32/LoongArch64).
Loongson 3A5000 and 3A6000 are the two existing CPUs of LoongArch64
and is used for PC products. It's BIOS supports ACPI and UEFI-only
boot. These CPUs supports SMP and SMT.
At present only LoongArch64 is supported by linux kernel.
Toolchain requirement:
binutils >= 2.40
gcc >= 13.1
For details, please check the following links:
https://lwn.net/Articles/861951/https://loongson.github.io/LoongArch-Documentation/README-EN.html
Signed-off-by: Weijie Gao <hackpascal@gmail.com>
Revert "mac80211: add new minstrel_ht patches to improve probing on mt76x2" (9861050b85)
Revert "kernel: use bulk free in kfree_skb_list to improve performance" (98b654de2e)
Revert "ramips: add preliminary support for WIO ONE" (085141dc5b)
Revert "ramips: add preliminary support for SGE AP-MTKH7-0006 developer board" (b1db6d0539)
Revert "build: use config.site generated by autoconf-lean, drop hardcoded sitefiles" (363ce4329d)
Revert "toolchain: add autoconf-lean" (fdb30eed03)
Revert "build: allow overriding the filename on the remote server when downloading" (6fa0e07758)
Signed-off-by: Felix Fietkau <nbd@nbd.name>
This includes binutils, gcc, gdb and uClibc-ng.
Latest release of ARC gcc (as of today it is "arc-2015.06")
is based on upstream gcc 4.8.4.
Sources are available on GitHub, see:
https://github.com/foss-for-synopsys-dwc-arc-processors/gcc
Latest release of ARC binutils (as of today it is "arc-2015.06")
is based on upstream binutils 2.23.
Sources are available on GitHub, see:
https://github.com/foss-for-synopsys-dwc-arc-processors/binutils-gdb/releases/tag/arc-2015.06
Latest release of ARC GDB (as of today this is "arc-2015.06-gdb")
is based on upstream gdb 7.9.1.
Sources are available on GitHub, see:
https://github.com/foss-for-synopsys-dwc-arc-processors/binutils-gdb/releases/tag/arc-2015.06-gdb
Note that for binutils and gdb that come from unified git repository
(which is the case for upstream binutils/gdb today) we need to disable
building of gdb in binutils and binutils in gdb hence in binutils:
------>8------
--disable-sim
--disable-gdb
------>8------
and in gdb:
------>8------
--disable-binutils
--disable-ld
--disable-gas
------>8------
Also in gdb we disable sim because if the following breakage while
building with it:
------------>8------------
/usr/bin/env bash ./../common/genmloop.sh -shell /usr/bin/env bash \
-mono -fast -pbb -switch sem5-switch.c \
-cpu a5f -infile ./mloop5.in \
-outfile-suffix 5
unknown option: bash
Makefile:699: recipe for target 'stamp-5mloop' failed
make[7]: *** [stamp-5mloop] Error 1
------------>8------------
Cc: Felix Fietkau <nbd@openwrt.org>
Cc: John Crispin <blogic@openwrt.org>
Cc: Jonas Gorski <jogo@openwrt.org>
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
SVN-Revision: 47438
John Crispin
Aleksey Vasilenko
Philip Prindeville
Weijie Gao
Zoltan HERPAI
Daniel Golle
Felix Fietkau
Florian Larysch
Felix Fietkau
Florian Fainelli
Jo-Philipp Wich
Daniel Dickinson
Nicolas Thill
Imre Kaloz