On the architectures that supports libsanitizer (part of gcc), the
build is currently failing with BR2_TIME_BITS_64=y. This is because
some code in libsanitizer unsets _FILE_OFFSET_BITS, but building code
with _FILE_OFFSET_BITS unset, but _TIME_BITS set isn't legal.
To fix this, this commit backports two changes:
- One change to also unset _TIME_BITS in
sanitizer_platform_limits_posix.cpp. This change is upstream in
LLVM, and already part of GCC 14.x, so we only bringing it to GCC
12.x and GCC 13.x.
- A second change doing the same modification, but in
sanitizer_procmaps_solaris.cpp, which as crazy as it might sound,
also gets compiled on Linux platforms (but to basically an empty
file). This change has been submitted upstream to both LLVM and gcc.
Notes:
- the special PowerPC SPE version of GCC cannot be affected, as only
uClibc-ng is used for this architecture, and uClibc-ng doesn't use
_TIME_BITS=64 (but now default to 64-bit time_t on 32-bit
architectures, like musl does).
- the special ARC version doesn't need patching because libsanitizer
doesn't support the ARC architecture, so it doesn't get built
Fixes:
http://autobuild.buildroot.net/results/ff2dbfdabf0bb6a0d82ea8a80122ab97fd75bd3f/https://gitlab.com/buildroot.org/buildroot/-/issues/16
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The build of gcc with Fortran support is broken on gcc 12.x and gcc
13.x, it fails with:
../../../libgfortran/generated/bessel_r8.c: In function 'bessel_yn_r8':
../../../libgfortran/generated/bessel_r8.c:178:1: internal compiler error: in gen_reg_rtx, at emit-rtl.cc:1167
This issue has been fixed in gcc 14.x, which builds a Microblaze
Fortran-capable toolchain successfully.
Since we're not really interested in figuring out the commit that
fixed the problem, let's simply disallow the selection of Fortran with
gcc12/13 on Microblaze.
Fixes:
http://autobuild.buildroot.net/results/5b4eee1d9b119c9f923f9518618f45a6482ddc85/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Our Bugzilla is so slow and unstable that it has become
unusable. Let's switch to using the Gitlab issue tracker instead.
There are still lots of references to the Bugzilla bug tracker in our
News page at https://buildroot.org/news.html, but these are for older
news.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr: don't needlessly re-flow]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Commit 69cb625947 ("package/gcc: enable
obsolete nios2 target") added some handling of nios2 with gcc 14.x,
duplicated between gcc-initial and gcc-final. Let's deduplicate this
logic into the common package/gcc/gcc.mk code.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
GCC 14.1.0 deprecated NIOS2 so we need to enable it explicitely.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Now that gcc 14 was added, we can remove the oldest version of gcc.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
In preparation for the upgrade of glibc to version 2.39, we need to
backport some gcc patches. Indeed glibc 2.39 drops libcrypt, causing a
build failure of libsanitizer (part of gcc) as it has code to
intercept crypt() and crypt_r() calls. This has been fixed in gcc
master, but we need to backport the fix for gcc 11.x, 12.x and 13.x.
gcc 8.x doesn't need to be fixed because (1) its libsanitizer does not
have an interceptor for crypt()/crypt_r() and (2) we only allow gcc
8.x for PowerPC SPE, for which we only support uClibc-ng, so this
issue with crypt/crypt_r going away from glibc is not relevant.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Since the ARC-special GCC version was bumped from gcc 10.x to gcc 13.x
in commit 045ab73702 ("toolchain: bump
ARC toolchain components to arc-2023.09-release"), the
BR2_GCC_VERSION_ARC option definition is not entirely correct: it
selects BR2_TOOLCHAIN_GCC_AT_LEAST_10, while it should select
BR2_TOOLCHAIN_GCC_AT_LEAST_13. This commit fixes this.
Cc: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Shortly before GCC 10.4.0 was dropped in d37a8f3a2, commit 4ce0dacb6 was
merged and introduced a patch to 10.4.0 that was not accounted for by
the patch that dropped 10.4.0 support.
Fixes: d37a8f3a2 ("package/gcc: remove gcc 10.x")
Signed-off-by: Vincent Fazio <vfazio@gmail.com>
Reviewed-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
With [1], [2] & [3] we made sure Buildroot packages get built with
proper MMU page size assumed. This was done nicely through insertion of
required flags into the toolchain wrapper so that there's no need to
pass these flags to each and every package separately - toolchain
wrapper used for real building has all set internally and so proper
flags are implicitly used.
But there's yet another corner case which is not handled that way -
these are binaries or rather libraries which are being used as a part of
GCC compilation: libgcc_s.so.1 and libstdc++.so.
And so to make sure both the libraries get built properly we need to
set TARGET_CFLAGS (cures libgcc_s.so) & TARGET_LDFLAGS (cures
libstdc++.so).
In case of ARM by defaut 64 KiB page size seems to be used, as w/o
that patch we see the following for BR2_ARM64_PAGE_SIZE_4K=y:
--------------------------->8----------------------------
$ ./output/host/bin/aarch64-linux-readelf -l ./output/target/lib/libgcc_s.so.1
Elf file type is DYN (Shared object file)
Entry point 0x0
There are 6 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000013d1c 0x0000000000013d1c R E 0x10000
LOAD 0x000000000001fd98 0x000000000002fd98 0x000000000002fd98
0x0000000000000438 0x00000000000005c8 RW 0x10000
DYNAMIC 0x000000000001fdb8 0x000000000002fdb8 0x000000000002fdb8
0x0000000000000200 0x0000000000000200 RW 0x8
$ ./output/host/bin/aarch64-linux-readelf -l ./output/target/usr/lib/libstdc++.so.6.0.32
Elf file type is DYN (Shared object file)
Entry point 0x0
There are 7 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x00000000001d3462 0x00000000001d3462 R E 0x10000
LOAD 0x00000000001d5760 0x00000000001e5760 0x00000000001e5760
0x000000000000e528 0x0000000000012de8 RW 0x10000
DYNAMIC 0x00000000001deef0 0x00000000001eeef0 0x00000000001eeef0
0x0000000000000240 0x0000000000000240 RW 0x8
--------------------------->8----------------------------
Note alignment of 0x10000 in sections marked for loading.
And with the patch applied we get expected alignment of 0x1000 (4
KiB):
--------------------------->8----------------------------
$ ./output/host/bin/aarch64-linux-readelf -l ./output/target/lib/libgcc_s.so.1
Elf file type is DYN (Shared object file)
Entry point 0x0
There are 6 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000013d1c 0x0000000000013d1c R E 0x1000
LOAD 0x0000000000013d98 0x0000000000014d98 0x0000000000014d98
0x0000000000000438 0x00000000000005c8 RW 0x1000
DYNAMIC 0x0000000000013db8 0x0000000000014db8 0x0000000000014db8
0x0000000000000200 0x0000000000000200 RW 0x8
$ ./output/host/bin/aarch64-linux-readelf -l ./output/target/usr/lib/libstdc++.so.6.0.32
Elf file type is DYN (Shared object file)
Entry point 0x0
There are 7 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x00000000001d3462 0x00000000001d3462 R E 0x1000
LOAD 0x00000000001d3760 0x00000000001d4760 0x00000000001d4760
0x000000000000e528 0x0000000000012de8 RW 0x1000
DYNAMIC 0x00000000001dcef0 0x00000000001ddef0 0x00000000001ddef0
0x0000000000000240 0x0000000000000240 RW 0x8
--------------------------->8----------------------------
A nice side effect is that we can get rid of the special handling of
"-matomic" as it's already part of ARCH_TOOLCHAIN_WRAPPER_OPTS.
[1] https://git.buildroot.net/buildroot/commit/?id=3cc2c6d19ab2e1bb4634f26f9318da9b07df5fff
[2] https://git.buildroot.net/buildroot/commit/?id=dcb74db89e74e512e36b32cea6f574a1a1ca84c4
[3] https://git.buildroot.net/buildroot/commit/?id=5e52c28397b79f8c4c99552217cbe95202166626
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Vladimir Isaev <VVIsaev@gmail.com>
Signed-off-by: Pavel Kozlov <kozlov@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
gcc.mk attempts to disable building the documentation by setting
MAKEINFO=missing, but it is not working. If makeinfo is installed
and recent enough, gcc still uses it. This can be checked easily:
grep BUILD_INFO='info' host-gcc-initial-*/build/gcc/config.log
It happens because the root ./configure script will check
$MAKEINFO --version (aka 'missing --version') and will overwrite it with
MAKEINFO='missing makeinfo' because the version does not match.
Having MAKEINFO='missing makeinfo' is a problem because
'missing makeinfo' will actually attempt to run 'makeinfo' before
failing with an error message. If makeinfo is installed on the host,
then 'missing makeinfo' will successfully run makeinfo anyway.
Many gcc subprojects will check $MAKEINFO --version and enable building
the documentation if it is recent enough. This patch overrides these
checks by forcing gcc_cv_prog_makeinfo_modern=no.
Building the GCC documentation can fail with the wrong makeinfo version.
It happened at least when building GCC 11.3.0 with makeinfo 7.1.
Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Fixes:
http://autobuild.buildroot.net/results/98f/98fedf4969c260f73a01b937b9625e66dcd86b3c
When BR2_TOOLCHAIN_HAS_LIBATOMIC is "n", there is no gcc libatomic.so
library to install. For configurations with such settings, compilation
fails as gcc-final.mk unconditionally adds libatomic as an installation
target. This error, for instance, shows for all Canaan K210 riscv
configs, as they all use uclibc flat binary format which disabled
libatomic:
Fix this by modifying package/gcc/gcc-final/gcc-final.mk to add
libatomic to GCC_FINAL_LIBS only for configurations that have
BR2_TOOLCHAIN_HAS_LIBATOMIC set to "y".
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In commit 0c82f3f635 (package/gcc: remove powerpc conditional patching
logic), the macro defining the conditional patch was removed, but it was
still referenced and expanded in the apply-patches hook.
Drop that now.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In commit
55e83008fc ("package/gcc/gcc-final:
rework installation of libgcc_s/libatomic"), we reworked the libgcc_s
installation. In the previous code, libgcc_s was installed to
STAGING_DIR/TARGET_DIR unconditionally, but a "-cp" command was used,
which means that any failure was ignored. As we are now more picky, it
has become clear that this in fact wasn't entirely correct: libgcc_s
only exists for shared builds. For static builds, only libgcc.a is
available, but it doesn't need to be installed to STAGING_DIR (for
some reason, and as it was never installed by Buildroot, it has always
worked without libgcc.a in STAGING_DIR).
So long story short: we change the code to only install libgcc_s when
BR2_STATIC_LIBS is disabled. This fixes the following build failure on
BR2_STATIC_LIBS=y builds:
cp -dpf /home/thomas/buildroot/buildroot/output/host/arm-buildroot-linux-uclibcgnueabi/lib*/libgcc_s* /home/thomas/buildroot/buildroot/output/host/arm-buildroot-linux-uclibcgnueabi/sysroot/lib/
cp: cannot stat '/home/thomas/buildroot/buildroot/output/host/arm-buildroot-linux-uclibcgnueabi/lib*/libgcc_s*': No such file or directory
Reported-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit adds the licensing information for the host-gcc-initial,
host-gcc-final and gcc-final packages.
For host-gcc-initial and host-gcc-final, instead of duplicating the
information, we use common variables coming from gcc.mk.
Of course for the target gcc-final, we use a different license than
for host-gcc-final, as it's the whole point of this series: be able to
describe that the target side of gcc is GPL-3.0 with linking
exception.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
This commit adds a target package "gcc-final", which is a target
package responsible for installing the gcc runtime libraries to
STAGING_DIR and TARGET_DIR. This task was so far done by the host
gcc-final package.
The motivation for splitting it up into a target package is to be able
to properly handle the licensing situation of GCC, where the host part
of GCC (the compiler itself) is under GPLv3, but the runtime libraries
on the target are under GPLv3-with-exception. So far, we were not
handling at all the license of gcc.
So what this commit does is:
* Add a gcc-final target package, which is depended on by the
toolchain-buildroot package, and which depends on
host-gcc-final.
* Moves to gcc-final the logic for installing target/staging
libraries
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
The HOST_GCC_FINAL_M68K_LIBGCC_FIXUP hook is tweaking the staging
directory. In preparation for additional rework, let's move it further
down in the file so that the diff of the rework will be easier to look
at.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Right now the library installation was split between installation of
static libs vs. shared libs. In preparation for additional rework, it
makes more sense to split it between target installation and staging
installation.
For staging installation we simply install $(lib)* so that both static
and shared libraries are copied.
For target installation, we only install when shared libraries are
used, and we copy $(lib).so*
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
This provides better error handling, and is more in line with our
current coding style. We also replace ";" by "&&" for the same reason
of proper error handling.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
We typically don't define empty variables in Buildroot, and the
comment is a bit useless, so drop both.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
The installation of libgcc_s/libatomic (which have to go in /lib) is
handled differently than all the other libraries (which go in
/usr/lib). For consistency, and in preparation for additional changes
in this area, handle both in a more consistent manner, with a new
HOST_GCC_FINAL_LIBS that looks like HOST_GCC_FINAL_USR_LIBS.
Consequently, the hook HOST_GCC_FINAL_INSTALL_USR_LIBS is renamed to
HOST_GCC_FINAL_INSTALL_LIBS, and made unconditional rather than being
conditional on ifneq ($(HOST_GCC_FINAL_USR_LIBS),). Indeed, we now
need to install libraries in /lib unconditionally, and if
HOST_GCC_FINAL_USR_LIBS is empty, the loops will simply not iterate on
any element, and they will not install anything in /usr/lib.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Since it was introduced in 5a6087d62e (toolchain: add powerpc SPE ABI
support), the CLASSIC vs. SPE choice for the ABI was never really a
choice: CPU without SPE could only use the CLASSIC ABI, while CPUs with
SPE could only use the SPE ABI.
Commit b4c824562b (powerpc: add BR2_POWERPC_CPU_HAS_SPE to replace
adhoc deps/checks) added a blind option that CPUs with SPE would select
rather than duplicate the ad-hoc dependencies in both CLASSIC and SPE
ABI options. Since then, it was even more obvious that the ABI choice
was really not a choice, as the two options have mutually exclusive
conditions.
Drop the useless choice, and directly use the blind option as selected
by the specific CPUs.
We don't need legacy handling, because the situation fixes itself.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Joel Stanley <joel@jms.id.au>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
gcc 13.2 is around, gcc 12.3 is the default version, so drop
10.4 in order to reduce the gcc choice.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since gcc 11 [1] the sparc architecture is disabled since
it produce a non working image. Buildroot now provide gcc
13.x, 12.x and 11.x and we are going to remove gcc 10
that was the last working release (thanks to a local patch).
We have to disable the internal toolchain backend for sparc
before removing gcc 10. While at it, remove !BR2_sparc
dependency for gcc 11.x, 12.x and 13.x.
[1] 2ab88dac29
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Even if gcc 11 is still maintained for some time, switch to gcc 12.x
since it has been released since 2022-05-06 and gcc 13.x is available
since 2023-04-26.
We have been having toolchains in the autobuilders with gcc
12.x for a while, so the vast majority of the problems should have
already been solved.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
When building with BR2_REPRODUCIBLE the toolchain wrapper passes
-fdebug-prefix-map for all packages that are built. But this doesn't
affect the target libraries (like libgcc) built by GCC's build system.
GCC 4.3 added a configure option to set the debug prefix map for these
libraries, which is used here to avoid encoding potentially
non-reproducible build paths into the debug data.
Signed-off-by: John Keeping <john@metanate.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Romain Naour