Support for the AVX512FP16 instructions was added in binutils
2.38. See the binutils 2.38 releases notes [0] that state:
X86:
[...]
* Add support for Intel AVX512_FP16 instructions.
[0] https://sourceware.org/pipermail/binutils/2022-February/119721.html
It turns out that when building GCC 12.x, some of these AVX512FP16
instructions are now used, and therefore when binutils < 2.38 is used,
the build fails as the assembler does not recognize those
instructions:
/tmp/ccChzL2g.s: Assembler messages:
/tmp/ccChzL2g.s:20: Error: no such instruction: `vmovw 24(%esp),%xmm2'
/tmp/ccChzL2g.s:21: Error: no such instruction: `vmovw 28(%esp),%xmm3'
/tmp/ccChzL2g.s:22: Error: no such instruction: `vmovw 32(%esp),%xmm4'
/tmp/ccChzL2g.s:23: Error: no such instruction: `vmovw 36(%esp),%xmm5'
/tmp/ccChzL2g.s:30: Error: no such instruction: `vcvtsh2ss %xmm2,%xmm6,%xmm6'
/tmp/ccChzL2g.s:36: Error: no such instruction: `vcvtsh2ss %xmm3,%xmm6,%xmm6'
/tmp/ccChzL2g.s:42: Error: no such instruction: `vcvtsh2ss %xmm4,%xmm7,%xmm7'
/tmp/ccChzL2g.s:48: Error: no such instruction: `vcvtsh2ss %xmm5,%xmm1,%xmm1'
/tmp/ccChzL2g.s:80: Error: no such instruction: `vcvtss2sh (%esp),%xmm1,%xmm1'
/tmp/ccChzL2g.s:96: Error: no such instruction: `vcvtss2sh (%esp),%xmm0,%xmm0'
/tmp/ccChzL2g.s💯 Error: no such instruction: `vucomish %xmm1,%xmm1'
/tmp/ccChzL2g.s:103: Error: no such instruction: `vucomish %xmm0,%xmm0'
/tmp/ccChzL2g.s:122: Error: no such instruction: `vucomish %xmm2,%xmm2'
The same issue does not occur with GCC 11.x, but nothing prevents
other packages than GCC to use those instructions, so the problem
really lies on the binutils side missing the support for those
instructions.
Also, in Buildroot, we do not distinguish AVX512 in general from
AVX512FP16 specifically, so our only option is to make binutils 2.37
unavailable for AVX512 systems even if some of them perhaps don't
support AVX512FP16 anyway. This seems like a reasonable trade-off, as
binutils 2.38 is anyway already the default in Buildroot, and
AVX512-capable systems are fairly recent, and therefore using a recent
binutils version should not be a problem on these platforms.
Fixes:
http://autobuild.buildroot.net/results/eb6e28c934654e6d714973415a2fb452f9580279/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Commit 7ff21f8d4b (package/binutils: handle gprofng as an optional
feature) introduced the typo. Although it was noticed, the commit was
not amended before being pushed...
Fix that now...
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
binutils 2.39 added support for gprofng, a new profiler (see
https://www.phoronix.com/news/GNU-Profiler-gprofng).
This new profiler is enabled by default, but it requires bison on the
host.
In order to handle this, this commit:
- Adds a new option BR2_BINUTILS_GPROFNG, which allows to
enable/disable gprofng in host-binutils
- Unconditionnally disables gprofng for the target binutils, based on
the idea that in a Buildroot context the analysis of profiling data
is generally done on the host system. This can of course always be
revisited later by adding a new option to the target binutils
package.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Currently, this option doesn't do anything. It only adds
--enable-plugins --enable-lto to the configure flags, but doesn't
disable them if it is not set. Since both of these default to enabled,
plugins and lto are effectively always enabled.
There really is no need to make this configurable: it adds a bit of size
and build time to host-binutils, but we don't care about that for host
tools. It's still up to individual builds to enable the LTO options.
Therefore, remove the option entirely. For clarity, explicitly pass
--enable-plugins --enable-lto to configure.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Now that recent versions of binutils work with FLAT binaries, we can
drop the old 2.32 version, which was kept only to keep support FLAT
binaries.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Thanks to the bump of elf2flt to version 2021.08, the issue with
recent versions of binutils has been fixed, so we can re-enable using
the recent binutils versions.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
See:
https://sourceware.org/pipermail/binutils/2022-February/119721.html
i386-Allow-GOT32-relocations-against-ABS-symbols.patch is not required
as it is in release.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
In BINUTILS_INSTALL_TARGET_CMDS (target!), libiberty is installed
to STAGING_DIR.
This is not necessary since libiberty is already unconditionally
installed to staging in BINUTILS_INSTALL_STAGING_CMDS. Furthermore
the presence of STAGING_DIR path in TARGET_CMDS is confusing and
incorrect.
Moreover libiberty is static only. Static libraries are only used at
build time, not at run time so we do not need to install libiberty in
target.
This commit removes the incorrect libiberty install in TARGET_CMDS and
adds a comment to clarify why we do not see libiberty installed on
target.
Signed-off-by: Jonathan Borne <jborne@kalray.eu>
[yann.morin.1998@free.fr:
- reword comment, move it toward the _INSTALL_TARGET_CMDS
- rewrap and slightly reword commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
After fixing binutils bug 21464, bug 28735 showed up. It got fixed very
soon after my request:
https://sourceware.org/pipermail/binutils/2022-January/119078.html
So let's add patch and backported patches to all binutils versions to make
Buildroot free from bug 28735. Unfortunately Bootlin toolchains have just
been rebuilt and will fail for this bug. This happened because libgeos
has been bumped few time ago and was masked by bug 21464 dependency that
prevented to build.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
When binutils 2.37 was introduced in commit
62f0232980 ("package/binutils: add
version 2.37"), the patch
0008-or1k-fix-pc-relative-relocation-against-dynamic-on-P.patch was
not properly updated. Indeed, between binutils 2.36 and 2.37, binutils
has switched to using the standard "bool" type, so instead of using
TRUE/FALSE, true/false must be used.
With this change, the binutils patch matches the one that was merged
upstream.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
As found out by Yann [1], binutils will use its bundled copy of zlib,
whether it is already provided by the system or not, and unless
explicitly told to use the system zlib with --with-system-zlib, which
is available since version 2.21 and
700d40ca16
This will fix the following build failure with oprofile when compiling
in a static configuration where zlib is not enabled:
checking for bfd_openr in -lbfd... no
checking for compress in -lz... no
configure: error: libz library not found; required by libbfd
As found out by Arnout [1], this fails infrequently because static is
already pretty rare, but in addition zlib is almost always selected by
some other package.
Fixes:
- http://autobuild.buildroot.org/results/0e1d16dfbb455a08db80ac5d35613908c3b4163f
[1] https://patchwork.ozlabs.org/project/buildroot/patch/20211030214734.2154583-1-fontaine.fabrice@gmail.com/
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[yann.morin.1998@free.fr:
- reword the explanations about the system zlib
- extend the oprofile example with static and !zlib
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Binutils is the last part of the csky toolchain fork.
The csky support has been merged in binutils 2.32 [1].
[1] https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=9d24df82ece4e87a0328173d6bd31cb9ff558bb4
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Guo Ren <ren_guo@c-sky.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Asked-by: Guo Ren <guoren@kernel.org>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Now that we have 2.35, 2.36 and 2.37, with 2.36 as the default, we can
remove 2.34.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Now that we have added version 2.37, it's time to use the 2.36.x
series as the default version.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[Arnout: also update default in binutils.mk]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
State of the patches:
- 0001-sh-conf.patch
Refreshed
- 0002-poison-system-directories.patch
Refreshed, but needed some adaptations as the bfd_boolean type no
longer exists, and the standard "bool" type is now used instead.
- 0003-or1k-Fix-issue-with-plt-link-failure-for-local-calls.patch
Drop, present in 2.37, merged upstream as
a76ef689b60405e494cb99e198acf3c82f467f7d
- 0004-or1k-Implement-relocation-R_OR1K_GOT_AHI16-for-gotha.patch
Drop, present in 2.37, merged upstream as
0b3e14c90283c5d234884d0ebe8510bc3c9bc687
- 0005-or1k-Avoid-R_OR1K_GOT16-overflow-failures-in-presenc.patch
Drop, present in 2.37, merged upstream as
3c3de29b048bca6b4aa4235c647b9328e71801b6
- 0006-or1k-Support-large-plt_relocs-when-generating-plt-en.patch
Drop, present in 2.37, merged upstream as
284a1309021a0ef4c29f198470d95652f02b13f0
- 0007-bfd-elf32-or1k-fix-building-with-gcc-version-5.patch
Refreshed
- 0008-or1k-fix-pc-relative-relocation-against-dynamic-on-P.patch
Refreshed
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Add patches to fix building on hosts that provide gcc version < 5
(i.e. 4.9), otherwise they fail due to missing default '-std=gnu11' option
on variable declaration inside for loops.
The patch is pending upstream:
https://sourceware.org/pipermail/binutils/2021-June/116884.html
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
When building openal we were seeing the assert failure:
/home/buildroot/autobuild/run/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: CMakeFiles/OpenAL.dir/al/source.cpp.o:
pc-relative relocation against dynamic symbol alSourcePausev
/home/buildroot/autobuild/run/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: CMakeFiles/OpenAL.dir/al/source.cpp.o:
pc-relative relocation against dynamic symbol alSourceStopv
/home/buildroot/autobuild/run/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: CMakeFiles/OpenAL.dir/al/source.cpp.o:
pc-relative relocation against dynamic symbol alSourceRewindv
/home/buildroot/autobuild/run/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: CMakeFiles/OpenAL.dir/al/source.cpp.o:
pc-relative relocation against dynamic symbol alSourcePlayv
collect2: error: ld returned 1 exit status
So add patches to fix this binutils assert link failure on OpenRisc.
It's been suggested upstream and it's pending here:
https://sourceware.org/pipermail/binutils/2021-July/117334.html
Fixes:
http://autobuild.buildroot.net/results/c96/c96f2600f227d6c76114b9fbc41f74a57e40415a/
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Add upstream backported patches that allows using -mcmodel=large gcc option
that in order allows fixing build failure due to binutils bug 21464:
https://sourceware.org/bugzilla/show_bug.cgi?id=21464
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
[Arnout: remove the PATCH M/N parts - cfr. check-package]
Actual patches are stubs suggested but now they are available as upstream.
So let's substitute them since they make part of a or1k patchset and next
patch will add the others.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
[Arnout: remove the PATCH M/N parts - cfr. check-package]
Release notes:
We are very sorry to have to report that a problem was found with the
GNU Binutils 2.36 release. It turns out that it contained a small
portion of code that was not covered by an FSF copyright assignment.
So we have created a replacement release - 2.36.1 - with that code
removed.
In addition we found that a fix for a theoretical security
vulnerability[1] was itself broken and could result in the archiver
program "ar" misbehaving. So we have chosen to revert the fix from
the 2.36.1 release whilst the problem is properly resolved.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Now that 2.36.x has been added, that 2.35.x is the default version,
drop support for 2.33.x.
Note that we keep binutils 2.32.x as it is the latest version that
works for FLAT binaries (used on noMMU platforms).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Now that 2.36 has been released, let's use 2.35.x as the default
binutils version.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
https://git.buildroot.net/buildroot/commit/?id=0791abfba0227803b19895ea22326f4e17ac93dc
bumped
* Binutils 2.34.50 with additional ARC patches
* GCC 10.0.2 with additional ARC patches
* GDB 10.0.50 with additional ARC patches
but forgot to update the version numbers stored in option descriptions.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit bumps ARC toolchain to arc-2020.09-release.
ARC GNU tools of version arc-2020.09-release bring some quite significant
changes like:
* Binutils 2.34.50 with additional ARC patches
* GCC 10.0.2 with additional ARC patches
* GDB 10.0.50 with additional ARC patches
Signed-off-by: Evgeniy Didin <Evgeniy.Didin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: arc-buildroot@synopsys.com
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since version 2.34 binutils enables debuginfod support by default if the
debuginfod library is found to be available at build time.
On Fedora 32, libdebuginfod may be present on the system, and the
dependency chain of interest is then:
libdebuginfod.so
-> libcurl.so
-> libk5crypto.so
-> libcrypto.so
If the Buildroot configuration ever needs to build host-openssl, which
may happen when building the kernel to sign modules for example, this
leads to an inconsistency between the system-provided libcrypto and
ours, leading to missing symbols:
$ make defconfig
$ make host-binutils
$ ./output/host/bin/i686-buildroot-linux-uclibc-objdump --help
[--snip some help text--]
$ make host-openssl
$ ./output/host/bin/i686-buildroot-linux-uclibc-objdump --help
./output/host/bin/i686-buildroot-linux-uclibc-objdump: symbol lookup
error: /lib64/libk5crypto.so.3: undefined symbol: EVP_KDF_ctrl, version
OPENSSL_1_1_1b
EVP_KDF_ctrl comes from libcrypto:
$ nm -D /usr/lib64/libcrypto.so.1.1 |grep EVP_KDF_ctrl
0000000000176000 T EVP_KDF_ctrl
$ nm -D output/host/lib/libcrypto.so.1.1 |grep EVP_KDF_ctrl
[--empty--]
So, if host-binutils tools, like objdump et al., are called after our
host-openssl is built, then when run, the system-provided libk5crypto.so
is used, but our libcrypto.so is used, because of the RPATH we set on
our host tools.
And boom.
Note that there is also a latent similar issue if we were to build our
host-libcurl too...
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
[yann.morin.1998@free.fr: rewrite commit log with a bit more info]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Now that binutils 2.35.1 has been released, it is time to move to
binutils 2.34 as the default binutils version, instead of 2.33.1.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Now that binutils 2.34 has been introduced, and we have moved to
2.33.1 as the default version, it is time to drop support for binutils
2.31.1.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Now that binutils 2.34 has been released, it is time to move to
binutils 2.33.1 as the default binutils version, instead of 2.32.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
A few conflicts had to be resolved:
- Version number and hash for mesa3d-headers/mesa3d
- Patches added in qemu, and the qemu version number
- The gnuconfig README.buildroot
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This commit bumps ARC toolchain to arc-2020.03-release.
ARC GNU tools of version arc-2020.03-release bring some quite significant
changes like:
* Binutils 2.34 with additional ARC patches
* GCC 9.3 with additional ARC patches
* glibc 2.30 with additional ARC patches
* GDB 10-prerelease with additional ARC patches
Signed-off-by: Evgeniy Didin <Evgeniy.Didin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: arc-buildroot@synopsys.com
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
libopcodes was installed in staging/ in commit 6a508d9361 (binutils:
Also install libopcodes in staging), but was not installed in target/
Starting with linux-5.6, perf (linux-tools) will link to libopcodes when
it is present. Since it is available in staging, the build succeeds.
However, libopcodes missing in target, perf fails at runtime:
perf: ...libopcodes-2.33.1.so: cannot open shared object file
Install libopcodes to target as well.
Signed-off-by: Lecopzer Chen <lecopzer@gmail.com>
[yann.morin.1998@free.fr: reword commit log]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Fix for xtensa PR ld/25861 introduced a regression in handling negative
symbol differences resulting in linker performing incorrect relaxation
or failing to link. Fix XTENSA_NDIFF relocation handling.
Backported from:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=d548f47df4d2e3d117d504a4c9977982c78a0556
Fixes: f0291ef4ab ("package/binutils: fix xtensa PR ld/25861")
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Tested-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
xtensa ld fails with the following message
ld: BFD (GNU Binutils) 2.31.1 internal error, aborting at
elf32-xtensa.c:3283 in elf_xtensa_finish_dynamic_sections
during domoticz package build. It happens because of mismatch between
the size allocated for dynamic relocations in the executable image and
the number of PLT relocations actually written to the image. The
mismatch is caused by the fact that undefined weak symbol is treated as
dynamic (and thus needing PLT relocation), but xtensa linker not
expecting that.
Fixes: http://autobuild.buildroot.net/results/7885705f1b1c0f31cf21b464150f5509929c1906/
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Backported from: e15a8da9c71336b06cb5f2706c3f6b7e6ddd95a3
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The patch added by [1] to fix a segfault with elf2flt when binutils
2.33.1 is used on ARM, introduce a regression with previous binutils
version on m68k and ARM.
Theses issues has been reported upstreme [2] [3].
For now, disable binutils >= 2.33.1 for configurations using
BR2_BINFMT_FLAT.
[1] 2b064f86b6
[2] https://github.com/uclinux-dev/elf2flt/pull/16
[3] https://github.com/uclinux-dev/elf2flt/issues/12
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>