- Fix CVE-2024-1544, CVE-2024-5288, CVE-2024-5991 and CVE-2024-5814
- Disable option checking which is enabled by default since
412447ac41https://github.com/wolfSSL/wolfssl/releases/tag/v5.7.2-stable
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit f13e0014a548244cd0e617ab60b47c68c872f823)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
User may get confused when they see the current hint, and take that as
the proper replacement, while we're only reporting the stem of the
variable name:
.../foo.mk:16: possible typo: BLA -> *FOO*
There is usually no easy way to actually suggest the proper variable
name, though, so let's make it a little bit more obvious that we meant
the variable was improperly prefixed:
.../foo.mk:16: possible typo, variable not properly prefixed: BLA -> *FOO_XXX*
And while at it, throw in the URL to the corresponding manual entry.
Adapt the test accordingly.
Reported-by: "Frager, Neal" <neal.frager@amd.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Ricardo Martincoski <ricardo.martincoski@datacom.com.br>
Reviewed-by: Neal Frager <neal.frager@amd.com>
[Arnout: also update new test, scoped -> prefixed]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit 5836b797626db56958fec09810e16af1c75d2b4c)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, when a package defines an unprefixed variable, but its value
contains a properly prefixed expansion (or even just the name of a
variable), there is not error reported (e.g. with the recently fixed
composer issue):
BASE_SITE = https://getcomposer.org/download/$(COMPOSER_VERSION)/composer.phar
The reason is that he check is done on the whole line, rather than on
the variable that is being set.
We fix that by really looking at the variable we found, instead of
looking in the whole line.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Ricardo Martincoski <ricardo.martincoski@datacom.com.br>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit b0964df557bedd88db1a223491fba615c995484f)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Newer 32bit architectures like RISCV32 and ARC are using 64bit time_t
from the get go unlike other 32bit architectures, therefore aliasing
__NR_futex to __NR_futex_time64 avoids the build error mentioned
in cb6fd050.
Fixes:
- http://autobuild.buildroot.org/results/c0f4168575fa85af933539441eea95a3b10dac91
Signed-off-by: Steffen Persvold <spersvold@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit a4ae4122936306952109865006d055a112a111f1)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This reverts (partial) commit
e39ad96136, and
26642e4cc0, but also fixed additional
sites where the !BR2_RISCV_32 dependency is no longer needed, thanks
to the recently added
0001-src-xshmfence_futex.h-fix-build-on-32-bit-architectu.patch in
xlib_libxshmfence.
Signed-off-by: Thomas Devoogdt <thomas@devoogdt.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit f30da3dc2181f157c25b742e6785b4b79f5deedf)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In preparation to revert e39ad96136,
and (partial) 26642e4cc0.
xshmfence_futex.h: In function 'sys_futex':
xshmfence_futex.h:58:24: error: 'SYS_futex' undeclared (first use in this function); did you mean 'sys_futex'?
58 | return syscall(SYS_futex, addr1, op, val1, timeout, addr2, val3);
| ^~~~~~~~~
| sys_futex
Fixes:
- e39ad96136
Signed-off-by: Thomas Devoogdt <thomas@devoogdt.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 36c7b1f08607c92186b849bd395fb2529942a6f9)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
There was an error in the pkg-cmake infra file regarding the selection
of the ASM compiler. Now that this has been fixed, overwriting the
ASM compiler selection is no longer necessary.
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit 638474478093831d76ab70e0cb3bd2d65d4a4511)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
CMAKE_ASM_COMPILER is supposed to point to a compiler wrapper (i.e.
gcc), _not_ to as directly. If it is not set, it will use the value of
CMAKE_C_COMPILER. That's exactly what we want, so there is no need to
set CMAKE_ASM_COMPILER at all.
For target, we don't set CMAKE_ASM_COMPILER either.
Setting CMAKE_ASM_COMPILER leads to build failures for any package that
actually tries to build .S files for the host - like llvm. This is why
llvm has an override for it.
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit 22af5f2939089b996aeda9ce072ab2f9b3ee6c2d)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
To give us a chance to catch runtime issues (such as missing
dependencies) more easily, add a test that writes a sample PDF file,
read it back and verify the text that was read.
Like similar packages that lead to a big
rootfs (e.g. python-botocore), this test requires a separate ext2
rootfs to avoid filling the default amount of RAM available
entirely (which would cause missing files from the root filesystem and
in turn, test failures).
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 115e9493b8e3b50cd56b93c47d669319d02698a7)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Now that the mandatory dependency of MuPDF on X.org, we can also drop
this dependency from python-pymupdf.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit edfa6f29785e618b75739b702fc863ee2410908d)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
It turns out that python-pymupdf doesn't require zlib directly, but it
does require the zlib python module.
This fixes the following runtime error:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python3.11/site-packages/fitz/__init__.py", line 22, in <module>
File "/usr/lib/python3.11/site-packages/fitz/fitz.py", line 3402, in <module>
File "/usr/lib/python3.11/gzip.py", line 9, in <module>
ModuleNotFoundError: No module named 'zlib'
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit ba6baa019b8b0146d053f310ddd2bc96cb9465a5)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The X11 support in mupdf is actually optional, and it does require
libXext in addition to libX11, so adjust the packaging accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 2c0d7b72c0993a55c8dcb7b38d85792e1bf6e8bc)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Now that MUPDF_CFLAGS and MUPDF_LDFLAGS are just TARGET_CFLAGS and
TARGET_LDFLAGS, drop them.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 90f0a484671098f9a94ce66b8f8af94e106ae106)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
By default mupdf generates static libraries, shared libraries must be
enabled explicitely.
Also, when building shared libraries, mupdf's Makefile properly passes
-fPIC, so adding it manually to MUPDF_CFLAGS is not needed.
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 401162d4a947184654d8202392425a625d000172)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This variable might have been needed in the very distant past to help
mupdf find libraries, but mupdf's Makefile now properly uses
pkg-config to find the 5 libraries freetype2, gumbo, harfbuzz, libjpeg
and zlib, so our code has become redundant: drop it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit f7deaa1330baad303afb76a7711faeeb1ddfee5d)
Signed-off-by: Peter Korsgaard <peter@korsgaard.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>
(cherry picked from commit 41f25676184fdbb3243c3709b925369679e7423a)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In commit 809fdb3a7a ("package/gdb:
remove gdb 10.x") and
030497be18 ("package/gdb: remove support
for GDB 11.x"), we forgot to drop the no longer needed hashes from
gdb.hash. Let's do this now.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit 538a99a33a2729b829ee07394de1a19dd955814a)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix the following build failure raised since bump to version
1.4.2-168-ged3039c in commit 2e330dff6a:
/home/buildroot/autobuild/run/instance-1/output-1/host/lib/gcc/arm-buildroot-linux-musleabihf/12.3.0/../../../../arm-buildroot-linux-musleabihf/bin/ld: attempted static link of dynamic object `libfdt/libfdt-1.6.1.so'
Fixes:
- http://autobuild.buildroot.org/results/6788d86c10d551b3d617e33c85083b817eb5d0b2
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit e167800979b48a449c168c229448e7069d2045e7)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
https://gcc.gnu.org/gcc-12/changes.html describes the changes of gcc
12.4 as follows:
This is the list of problem reports (PRs) from GCC's bug tracking
system that are known to be fixed in the 12.4 release. This list
might not be complete (that is, it is possible that some PRs that
have been fixed are not listed here).
With a link to
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=12.4
There are 654 relevant commits (ignoring the "daily bumps") between
gcc 12.3.0 and 12.4.0, which is too much to list exhaustively here.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit b4454720908e79252ea98bcbe4de86e4bbd4de77)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The patch removes one of the two occurrences of libnfc from the list of
packages managed by Simon Dawson.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 673d371cf22262509e8f764615864be31b3e146e)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The ESI feature is now disabled by default. Use --enable-esi if needed.
See here for other changes:
https://github.com/squid-cache/squid/commits/v6
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 4c1a85a87d5aabfc2a4ec99da7c48df9f1884797)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
libressl doesn't support all architectures since bump to version 3.8.2
in commit 21eca49ed5 and
b98c56fd5e71ce0b8c3e:
In file included from /home/autobuild/autobuild/instance-4/output-1/build/libressl-3.8.2/crypto/rc4/rc4_enc.c:61:
/home/autobuild/autobuild/instance-4/output-1/build/libressl-3.8.2/crypto/../include/openssl/rc4.h:75:9: error: unknown type name 'RC4_INT'
75 | RC4_INT x, y;
| ^~~~~~~
Fixes:
- http://autobuild.buildroot.org/results/1f6ac121b3771ccc4b0e846c061b7002ccb63963
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 080f2d94b7ac6e8ed5aef99000ec35a001186ed9)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
cdrkit.org no longer works, and there is no obvious homepage for this
dead project. Use the Wikipedia page as a replacement.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit aa549fb95f8409c2b364cd1d8257f92a1b693720)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
similar to previous problems with nios2 and not-available atomic ints
the build for Boost.Atomics also fails for ARC Targets which don't
have the ATOMICS_EXT flag set.
according to [0] "Boost.Atomic has a hard requirement of the native
atomic operations on bytes". The same tests mentioned there fail for
ARC without the atomic extension.
Disable BR2_TOOLCHAIN_SUPPORTS_ALWAYS_LOCKFREE_ATOMIC_INTS for BR2_arc
without BR2_ARC_ATOMIC_EXT.
Fixes:
http://autobuild.buildroot.net/results/4ca54a85672d7b9328b1909b457e548c6032a493
[0] https://github.com/boostorg/atomic/issues/42#issuecomment-734130348
Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
[Arnout: add to BR2_TOOLCHAIN_SUPPORTS_ALWAYS_LOCKFREE_ATOMIC_INTS
instead of updating all packages]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit ad71b415c1bdf1bbf4c37b04c772dc3104187b58)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
make "gcc --help -v" display all the options, some packages depend on this
https://bugs.busybox.net/show_bug.cgi?id=15231
Signed-off-by: Sagi Mor <sagimor6@gmail.com>
[Arnout: move the handling to the beginning and directly call execv]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit 9954315fc5b2026552a0f0175307ec8784b51578)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The build logic in source/cmake/FindNeon.cmake caused the x265 build
system to always think that the CPU supports neon: it was looking in
/proc/cpuinfo, which of course is wrong when cross-compilation, but
then the sequence of grep was interacting badly with CMake, causing
the build system to always conclude that the CPU supports NEON.
This causes runtime issues on ARMv6.
Setting -DCROSS_COMPILE_ARM=1 fixes this, as it tells the x265 build
system we are cross-compiling and it skips its bogus NEON check. So
for ARMv6, we pass -DCROSS_COMPILE_ARM=1.
But then, we still want NEON for ARMv7 processors with NEON, so this
commit adds a patch that allows to explicitly specify whether the CPU
supports NEON, in the -DCROSS_COMPILE_ARM=1 case, and we use this
option when BR2_ARM_CPU_HAS_NEON.
For those wondering why -DCROSS_COMPILE_ARM=1 is not passed for all
ARM platforms: it's because from the perspective of x265, only ARM >=
v6 is ARM: it has assembly code that needs at least ARMv6. Earlier ARM
platforms are not detected as ARM by the x265 build logic, and
therefore fallback on generic code.
This has been build-tested on:
- ARMv5: generic code is used, no assembly
- ARMv6: assembly code is used, but not with NEON support
- ARMv7 with NEON: assembly code is used, with NEON support
Reported-by: David Barbion <davidb@230ruedubac.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 1fbd26f83169a206bdf9c36c85510a33c0e7a864)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
As we're about to do some other fixes in x265 ARM build, let's replace
the patch fixing gcc option by:
- A patch generated by git format-patch now that x265 upstream uses
Git
- Is re-submitted upstream
- Only drops the flags, and does not add bogus ARM architecture
aliases that don't exist in the CMake world.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 9d62687d0024f7e3bac68157f1250970ef45abff)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
GNU Octave supports the --with-sndfile configure option since v4.0.0.
For reference, commit 40ea68b4b2 "package/octave: new package"
introduced the package at v7.1.0.
This commits adds this optional support.
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit a5ce48fe456d790612c9b63990f0a4f3e2faa554)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The btrfs-progs homepage [1] show a banner:
OBSOLETE CONTENT
This wiki has been archived and the content is no longer updated.
NOTE: this wiki is archived and not updated anymore (02/2023).
Contents will be migrated to https://btrfs.readthedocs.io
This commit updates the URL to the new one at [2].
[1] https://btrfs.wiki.kernel.org/index.php/Main_Page
[2] https://btrfs.readthedocs.io
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 91cd9488005e7f0fce7ead126f1e637deefcaf02)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
A lot has been changed in 2.44.0, please consult the announcement [1], what's new [2],
and the security advisory [3] for more details.
Specific to this bump:
- Libegl is now mandatory [4] and the USE_OPENGL_OR_ES flag has been dropped.
While at it, also explicitly add the libepoxy dependency which is now selected
by libgtk3.
- The WPE renderer has been dropped [2], so drop the wpebackend-fdo dependency.
- JPEG2000 has been dropped [2], so drop the OpenJPEG dependency.
- GTK4 is now the default, so turn it off, since buildroot has no GTK4 support
yet [2].
- USE_LIBBACKTRACE has been added [5], so select it properly.
- Support for ENABLE_WEB_CODECS has been added, which will now be enabled
together with audio and video support.
- ENABLE_WEBASSEMBLY is forbidden when ENABLE_C_LOOP [6], so disable it when
compiling for MIPS r6, ARMv5, and ARMv6.
In the meantime, a follow-up 2.44.1 and 2.44.2 release has been announced [7][8],
which contains a bunch of patches that were accepted upstream. Including build
fixes for 32-bit devices, and disabling video.
[1]: https://webkitgtk.org/2024/03/16/webkitgtk2.44.0-released.html
[2]: https://webkitgtk.org/2024/03/27/webkigit-2.44.html
[3]: https://webkitgtk.org/security/WSA-2024-0002.html
[4]: https://commits.webkit.org/271345@main
[5]: https://commits.webkit.org/268579@main
[6]: https://commits.webkit.org/271347@main
[7]: https://webkitgtk.org/2024/04/09/webkitgtk2.44.1-released.html
[8]: https://webkitgtk.org/2024/05/16/webkitgtk2.44.2-released.html
Signed-off-by: Thomas Devoogdt <thomas@devoogdt.com>
Acked-by: Adrian Perez de Castro <aperez@igalia.com>
Tested-by: Adrian Perez de Castro <aperez@igalia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit d5ff56ef06c46bc870cc677d34cec2639852c823)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This allows uvw to be again in sync with the libuv package, following
the bump of libuv to v1.48 in commit
bd2f99246c ("package/libuv: security
bump to version 1.48")
The hash of the license file has changed due to a copyright year
update.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit c54134bf6914593caaa9ed4aa11cbe3a17c59eca)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issue:
net/http: denial of service due to improper 100-continue handling
The net/http HTTP/1.1 client mishandled the case where a server responds to
a request with an "Expect: 100-continue" header with a non-informational
(200 or higher) status. This mishandling could leave a client connection in
an invalid state, where the next request sent on the connection will fail.
An attacker sending a request to a net/http/httputil.ReverseProxy proxy can
exploit this mishandling to cause a denial of service by sending "Expect:
100-continue" requests which elicit a non-informational response from the
backend. Each such request leaves the proxy with an invalid connection, and
causes one subsequent request using that connection to fail.
Thanks to Geoff Franks for reporting this issue.
This is CVE-2024-24791
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When build host has a many CPUs (more that 20) and GNU Make 4.4
(included for example in Fedora 40), fwts can randomly fail to build.
This commit adds a package patch to fix the issue.
Fixes:
mv: cannot stat 'dtcompilerparser.tab.c': No such file or directory
mv: cannot stat 'prparser.tab.c': No such file or directory
See also:
https://github.com/fwts/fwts/issues/7
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit f6d9fa3692b0e5dd75bb1fee5d151fe58da7800d)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In order for systemd-oomd to run CONFIG_PSI and CONFIG_MEMCG must be
enabled in the kernel config.
See:
e7b3f1a6c3aa329b8922
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit be5f14657a5540fdabb03ba8b5ff64c0da804e32)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
check was failing to build on noMMU configurations due to mistake in
the build conditionals of the code around the HAVE_FORK macro. This
commit brings a patch, submitted upstream, that fixes those issues.
Fixes:
http://autobuild.buildroot.net/results/1509108aa111da706d544eb67e1ae2c2b34bd4e4/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit d10bee42012103fe7974c5e20be3af81e3c1c250)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The build system of check was unconditionally building a shared
library, even when BUILD_SHARED_LIBS=OFF. This commit brings a patch,
submitted upstream, which fixes this issue, and allows to fix the
build in BR2_STATIC_LIBS=y configurations.
Fixes:
http://autobuild.buildroot.net/results/d4a1c6d49dd15ce6b73cfade2557d49733e9318b/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 526b89b981cb3fa3da7644482d1f140f1fb25e27)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add bsdunzip option to avoid the following build failure raised since
bump to version 3.7.1 in commit 7991d2c48a and
c157e4ce8e:
CCLD bsdunzip
/home/autobuild/autobuild/instance-4/output-1/host/lib/gcc/powerpc-buildroot-linux-musl/12.3.0/../../../../powerpc-buildroot-linux-musl/bin/ld: cannot find -lz: No such file or directory
By handling it explicitly, we can specify whether the dynamic or static
library should be used, according to what we actually have available.
Fixes:
- http://autobuild.buildroot.org/results/aaf7fdefa0b7bd7e5ac743487c197544c1a2ce6f
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Tested-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit bbc08b15ae60c3008fb8cbff59dc329d8357c563)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This issue was introduced back in 2009 with commit
e11fe847b2 that created the generic
package infrastructure.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit bd0d5498ea00c29b22bb8c87b8f593b356deb469)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When a shared build is used, we can use getauxval and no ARM only
instuctions are in use.
When a static build is used, we need to override CFLAGS to use
arm instructions, as uClibc-ng only supports getauxval for shared case.
Fixes:
- http://autobuild.buildroot.net/results/3b5/3b5c5519a3e5ee490308bc1a1b9579ce13417235
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit 408352207c18084c331b23aa739cde98cd52d000)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Ntpsec unconditionally uses PIE to compile code.
This breaks compilation for at least microblaze-uclibc and
m68k-uclibc toolchains.
Also in Buildroot context, PIE should anyway be governed by BR2_PIC_PIE.
It would be better to add a configure option to allow to disable pie
support, but this is something for a waf expert.
Fixes:
- http://autobuild.buildroot.net/results/77f/77f4e4065874d022a2ae98d82508242f551e224c
- http://autobuild.buildroot.net/results/e45/e45b65f2aa323df075d54ff43b0401b5ac7c6eb5
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit a5327724686a1ba719d37caff5986f241993b500)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When BR2_SHARED_LIBS=y (shared libraries only) and BR2_PIC_PIE=y
(Build code with PIC/PIE), the toolchain-wrapper will try to enable
position-independent code/executables. See [1]. This configuration
is a common default.
Xvisor was likely tested only with RISC-V gcc from [2], which will
not enable PIE by default. Since Xvisor is a Type 1 hypervisor, it
needs the same kind of special treatment as U-Boot or Kernel.
This commit adds a patch to explicitly force static linking and
disable PIE for RISC-V architecture.
[1] https://git.buildroot.org/buildroot/tree/toolchain/toolchain-wrapper.c?h=2023.05.1#n392
[2] https://github.com/riscv-collab/riscv-gnu-toolchain
Signed-off-by: Julien Olivain <ju.o@free.fr>
[Arnout: renumber patch]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit 28925c6c86c41f2539c057f1a67267e58b5b2057)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Integrate a patch, which was submitted upstream, to work-around an
issue with the SPARC kernel headers. The kernel headers have been
fixed in the upstream kernel (in the to-be-released 6.10 kernel), but
we need a workaround for the older toolchains, until we believe 6.10
is "old" enough to be able to drop the workaround.
Fixes:
http://autobuild.buildroot.net/results/272c464ed4f9392535fa3b7613218dbd03acf901/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit b162aab7c6da6b45dc5ba9ad30b59b4362e2dc2e)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Although the asciidoc toolchain accepts any number of ~ to delimit a
listing block (i.e. a code block), it is actually specified to be
exactly four, i.e. ~~~~. Currently, a mix of diffrent numbers of ~ are
being used - sometimes even a different number at the beginning and at
the end of the block.
Normalize this to always use exactly four ~ for the delimiter.
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit 447fa1fca425e629cc65cd0a8261a4c09ddf67d2)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently the text for each package infra that mentions the usage of
variables already provided by the generic infra diverge from each other:
- some (golang, kconfig, python) add a cross-referece to the generic
infra chapter;
- kconfig does not list any example;
- some mention _LICENSE as an example, others don't;
- some (cargo, golang, python) add an 'etc.' at the end of the examples,
giving the idea that can be more symbols provided by the generic
infra than the ones listed;
- most have the text 'works by defining a number of variables before
calling the +<macro-name>+ macro', except golang and kconfig;
- some actually list 'A few additional variables' but keep using some
old reference as 'An additional variable';
- some say 'First, all the package metadata' and other only 'All the
package metadata';
- most mention _SUBDIR as an example of variable supported by the
generic infra, even the generic infra manual not mentioning it.
Improve the correctness for the manual by standardizing the text among
the package infras:
- use the same text "All the package metadata information variables that
exist in the generic package infrastructure also exist in the
<name> infrastructure:" for all of them;
- add the cross-reference for all of them;
- remove the examples of variables inherited from the generic infra -
this also solves the _SUBDIR problem, there no longer is any reference
to _SUBDIR;
- wrap the modified text at 80 columns;
- add "macro" to golang and luarocks infra;
- use "A few additional variables" for qmake and waf.
At same time, add a missing format on golang manual for
BR2_PACKAGE_HOST_GO_HOST_ARCH_SUPPORTS.
Cc: Eric Le Bihan <eric.le.bihan.dev@free.fr>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
[Arnout:
- remove the examples;
- add "the" where "macro" was added;
- rewrite the preceding paragraphs for kconfig to make it more
consistent.
]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit 4286c89f9d987f5f3bcbb14dfd58ba440944f4c2)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Each linux tool uses a fragment of a .mk file, named, for instance:
package/linux-tools/linux-tool-cpupower.mk.in
So currently check-package does not check these files.
Add the support in check-package script.
At the same time, factor out a function to derive package prefix from
the filename being checked, so the fix (calling os.path.splitext twice)
can be applied in a single place.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
[Arnout: add docstring and explain double splitext to
get_package_prefix_from_filename]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit ccc12c0f244de23672300b5837b473292c8db931)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
