In 96c3b52132 (package/uacme: don't allow ualpn with mbedTLS), the
preference order moved openssl before mbedtls, because ualpn was not
compatible with mbedtls. That caused the preference order in the .mk to
diverge semantically from the preference order in the Config.in.
Indeed, openssl is only selected when neither gnutls nor mbedtls are
enabled, so openssl is clearly leastpreferred crypto backend. But when
both openssl and mbedtls were enabled, then uacme would use opensslC
because of ualpn.
The ualpn limitation was lifted in 6c7b46945e (package/uacme: allow
ualpn with mbedTLS), but the preference order in the .mk was not
restored to match that of the Config.in.
Restore the order in the .mk so that openssl is again treated as the
least-preferred crypto backend.
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[yann.morin.1998@free.fr:
- split off to its own patch
- write the full commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 192e047fda)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The gcc man page states that specifying Neon as part of the fpu setting
has no effect, unless the -funsafe-math-optimizations is also specified,
because Neon is not compliant with IEEE 754:
```
If the selected floating-point hardware includes the NEON extension
(e.g. -mfpu=neon), note that floating-point operations are not
generated by GCC's auto-vectorization pass unless
-funsafe-math-optimizations is also specified. This is because NEON
hardware does not fully implement the IEEE 754 standard for
floating-point arithmetic (in particular denormal values are treated
as zero), so the use of NEON instructions may lead to a loss of
precision.
```
-funsafe-math-optimizations must be explictly specified per package to
really use NEON as FPU, but it's something that is left to the user as
well as setting BR2_ARM_FPU_NEON_VFPV4. This way the default
BR2_ARM_FPU_VFPV4D16 is used as previously. So let's revert the
offending patch.
This reverts commit aaced92e8c.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 25ecee3f17)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The gcc man page states that specifying Neon as part of the fpu setting
has no effect, unless the -funsafe-math-optimizations is also specified,
because Neon is not compliant with IEEE 754:
```
If the selected floating-point hardware includes the NEON extension
(e.g. -mfpu=neon), note that floating-point operations are not
generated by GCC's auto-vectorization pass unless
-funsafe-math-optimizations is also specified. This is because NEON
hardware does not fully implement the IEEE 754 standard for
floating-point arithmetic (in particular denormal values are treated
as zero), so the use of NEON instructions may lead to a loss of
precision.
```
-funsafe-math-optimizations must be explictly specified per package to
really use NEON as FPU, but it's something that is left to the user as
well as setting BR2_ARM_FPU_NEON_VFPV4. This way the default
BR2_ARM_FPU_VFPV4D16 is used as previously. So let's revert the
offending patch.
This reverts commit 115ee05214.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit d5c1e67d3a)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The gcc man page states that specifying Neon as part of the fpu setting
has no effect, unless the -funsafe-math-optimizations is also specified,
because Neon is not compliant with IEEE 754:
```
If the selected floating-point hardware includes the NEON extension
(e.g. -mfpu=neon), note that floating-point operations are not
generated by GCC's auto-vectorization pass unless
-funsafe-math-optimizations is also specified. This is because NEON
hardware does not fully implement the IEEE 754 standard for
floating-point arithmetic (in particular denormal values are treated
as zero), so the use of NEON instructions may lead to a loss of
precision.
```
-funsafe-math-optimizations must be explictly specified per package to
really use NEON as FPU, but it's something that is left to the user as
well as setting BR2_ARM_FPU_NEON_VFPV4. This way the default
BR2_ARM_FPU_VFPV4D16 is used as previously. So let's revert the
offending patch.
This reverts commit f8528acdfd.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 869fe1fbab)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The gcc man page states that specifying Neon as part of the fpu setting
has no effect, unless the -funsafe-math-optimizations is also specified,
because Neon is not compliant with IEEE 754:
```
If the selected floating-point hardware includes the NEON extension
(e.g. -mfpu=neon), note that floating-point operations are not
generated by GCC's auto-vectorization pass unless
-funsafe-math-optimizations is also specified. This is because NEON
hardware does not fully implement the IEEE 754 standard for
floating-point arithmetic (in particular denormal values are treated
as zero), so the use of NEON instructions may lead to a loss of
precision.
```
-funsafe-math-optimizations must be explictly specified per package to
really use NEON as FPU, but it's something that is left to the user as
well as setting BR2_ARM_FPU_NEON_VFPV4. This way the default
BR2_ARM_FPU_VFPV4D16 is used as previously. So let's revert the
offending patch.
This reverts commit 23329364e2.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 68d0385533)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
netsniff-ng unconditionally uses pthread_spin_lock since its addition in
commit 500d287b07 and
1a9fbac03c
resulting in the following build failure:
/home/autobuild/autobuild/instance-1/output-1/per-package/netsniff-ng/host/bin/../lib/gcc/x86_64-buildroot-linux-uclibc/10.3.0/../../../../x86_64-buildroot-linux-uclibc/bin/ld: netsniff-ng/tprintf.o: in function `tprintf_flush':
tprintf.c:(.text+0x42c): undefined reference to `pthread_spin_lock'
Fixes:
- http://autobuild.buildroot.org/results/ceadbdea8cc35bfd7d601a6d4b18137f81f61406
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit a969e0f63c)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Github repository mripard/sunxi-mali states to use Lima in place of
sunxi-mali because it's deprecated, but this package is still useful in
Buildroot so I want to move the SITE to my Github fork of the original
repository that already contains a patch to fix a build failure showing
up with Linux version >= 5.15.
The upstream patch fixes missing DMA_BUF module inclusion that leads to
build failure. The patch includes DMA_BUF by using:
MODULE_IMPORT_NS(DMA_BUF);
My idea is to continue to maintain this package in parallel to Lima since
it seems to be still useful.
Fixes:
http://autobuild.buildroot.net/results/8f25c26de737c358b3b43a10737609465b4e1398/
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 6dcaa20ca4)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Set CROSS variable otherwise makedumpfile will use it to undefine the
host architecture through -U__$(HOST_ARCH)__ if $(TARGET) is not equal
to $(HOST_ARCH). This will result in the following build failure since
the addition of the package in commit
adb64a97e7 if aarch64_be is cross-compiled
on a aarch64 host for example:
/home/autobuild/autobuild/instance-5/output-1/host/bin/aarch64_be-buildroot-linux-uclibc-gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O3 -g0 -g -O2 -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DVERSION='"1.7.0"' -DRELEASE_DATE='"8 Nov 2021"' -D__aarch64_be__ -U__aarch64__ -DUSELZO -c -o ./print_info.o print_info.c
[...]
makedumpfile.c: In function 'is_kvaddr':
makedumpfile.c:1547:46: error: 'KVBASE' undeclared (first use in this function)
1547 | return (addr >= (unsigned long long)(KVBASE));
| ^~~~~~
Fixes:
- http://autobuild.buildroot.org/results/e4e10364e1a24099ce31bf20eacf5adedf93e5a7
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit b8665e39f1)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit 4dff1be05e (package/libvirt: libvirtd needs C++ for nmap-ncat)
introduce a recursive dependency (really: a circular dependency):
package/busybox/Config.in:33:error: recursive dependency detected!
package/busybox/Config.in:33: symbol BR2_PACKAGE_BUSYBOX_SHOW_OTHERS is selected by BR2_PACKAGE_EBTABLES_UTILS_SAVE
package/ebtables/Config.in:11: symbol BR2_PACKAGE_EBTABLES_UTILS_SAVE depends on BR2_PACKAGE_EBTABLES
package/ebtables/Config.in:1: symbol BR2_PACKAGE_EBTABLES is selected by BR2_PACKAGE_LIBVIRT_DAEMON
package/libvirt/Config.in:44: symbol BR2_PACKAGE_LIBVIRT_DAEMON depends on BR2_PACKAGE_NETCAT_OPENBSD
package/netcat-openbsd/Config.in:1: symbol BR2_PACKAGE_NETCAT_OPENBSD depends on BR2_PACKAGE_BUSYBOX_SHOW_OTHERS
We can't drop the C++ dependency and switch the netcat-openbsd and
nmap-ncat dependencies conditions without adding a glibc dependency.
So always mandate C++ even if is only needed by nmap and not
netcat-openbsd
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit a17c456b2c)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit 'dc7ca780a0 package/gstreamer1/gst1-plugins-good: convert package
type to meson' from 2019 removed the symbol, stating:
Remove BR2_PACKAGE_GST1_PLUGINS_GOOD_ZLIB
Existing configs will already have BR2_PACKAGE_ZLIB selected, so no
legacy entry is needed for BR2_PACKAGE_GST1_PLUGINS_GOOD_ZLIB
So drop the reference to the symbol.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit fa77b1b9f2)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
BR2_sparc_v7 was removed in 2013 in commit '16bcf46a63 arch/sparc: drop
old SUN-specific variants'.
BR2_sparc_sparchfleon and BR2_sparc_sparchfleonv8 were moved to legacy
handling in 2014 in commit '43b78e7285 arch: sparc: Add leon3 cpu type
and remove sparc{s,h}fleon{,v8}' and later removed from legacy handling
in 2020.
So drop the remaining references for these symbols.
Cc: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 5924461994)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
From time to time we have a reference added to the inexistent BR2_nios:
$ git log --oneline -G'BR2_nios\>'
726dcc6eee package/libvncserver: needs dynamic library
8cd840b7e8 package/ffmpeg: fix typo "nios" -> "nios2"
bd2544d3d3 package/ffmpeg: simplify BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS logic
de7523259b libplayer: fix typo on BR2_nios2
615d65d3c6 mplayer: add missing reverse dependencies for nios2 and sh2a
Fix the last commit, from 2019, like it was done before.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 587d69236c)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
BR2_LINUX_KERNEL_CUSTOM_LOCAL was moved to legacy handling during release
2016.11 but does not select BR2_LEGACY.
Add the select, like done by all other symbols in the file.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit e07fcf80bc)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
All other occurrencies in the tree simply do:
select SYMBOL1 if SYMBOL2
instead of
select SYMBOL1 if SYMBOL2=y
So do the same here for consistency.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit b60c17e9be)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This is the only use in the tree without the space.
Do like the other 2k+ uses in the tree and add the space:
-depends on!BR2_...
+depends on !BR2_...
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 25a3085712)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Disable documentation to avoid the following build failure if a non
working asciidoc or a2x is found on the system:
asciidoc -o html/syslinux.html /nvmedata/autobuild/instance-3/output-1/build/syslinux-6.03/txt/syslinux.txt
/nvmedata/autobuild/instance-3/output-1/per-package/syslinux/host/bin/python3: No module named asciidoc
Setting {ASCIIDOC,A2X_XML}_OK to a value different of 0 will disable
html, man, xhtml and text documentation
Fixes:
- http://autobuild.buildroot.org/results/47f876ccb56831cc1bb9e6c2f7dbce423581a0dd
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 375f5dd1bd)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Disable man pages to avoid the following build failure if a non-working
a2x is found on the system raised since bump to version 11 in commit
b72b849ad5:
/usr/bin/a2x -f manpage -D /nvmedata/autobuild/instance-23/output-1/build/jose-11/build /nvmedata/autobuild/instance-23/output-1/build/jose-11/doc/man/jose.1.adoc
/nvmedata/autobuild/instance-23/output-1/host/bin/python3: Error while finding module specification for 'asciidoc.a2x' (ModuleNotFoundError: No module named 'asciidoc')
Fixes:
- http://autobuild.buildroot.org/results/ae69f7fd1258d99a5b08eeb8c67904be53eabf15
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 70db731a79)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This series fixes a fatal error at link time on m68k, xtensa,
and riscv64, caused by a bad upstream elf2flt commit.
Without this patch, m68k, xtensa, and riscv64 would result in
a fatal error:
ERROR: text=0x3bab8 overlaps data=0x33f60 ?
With this patch, qemu_m68k_mcf5208_defconfig,
qemu_riscv64_nommu_virt_defconfig, and
qemu_xtensa_lx60_nommu_defconfig builds properly.
riscv64 and m68k boots to login prompt.
xtensa crashes when loading init, the same behavior as when
reverting the bad upstream elf2flt commit completely.
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 9dd179d43f)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
