When using precompiled headers, changing any macros defined on the
command line will invalidate the precompiled header. With
toolchain-wrapper adding __DATE__ and __TIME__, any commits to Buildroot
will invalidate incremental builds regardless of whether the precompiled
header actually uses those values (affecting _OVERRIDE_SRCDIR).
GCC-7 and later support SOURCE_DATE_EPOCH and use it to define __DATE__
and __TIME__ internally, avoiding any impact on precompiled headers.
Disable the custom handling in toolchain-wrapper if GCC is version 7 or
newer.
Signed-off-by: John Keeping <john@metanate.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 408bc354a9)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When booting, a Raspberry Pi will load the appropriate start files,
depending on the provided configuration. For example, if the config.txt
file contains ’gpu_mem=16’ the board will automatically load the
cut-down startup files (start_cd.elf and fixup_cd.dat on non-Rpi4).
Unfortunately, even when the appropriate version is selected in the
configuration menu, if the rpi-firmware makefile takes the good files,
it renames them to non-qualified, i.e. start.elf and fixup.dat. But as
these are not the files searched by the Raspberry Pi, the board will not
start.
This patch will set the names of the files to load as constant in the
config.txt file. This guarantees that the rpi firmware blobs do not take
any other corner-case decision based on any other as-yet unknown
conditions.
This eases the maintenance, as only the names of the source files
matter; the destination filenames are constants, and so are the
filenames in config.txt.
Fixes: #13026
Signed-off-by: Stéphane Veyret <sveyret@gmail.com>
[yann.morin.1998@free.fr:
- very minor fix in commit title
- drop the non-conditional macro and move its content into
RPI_FIRMWARE_INSTALL_IMAGES_CMDS
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 1bdc0334ff)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
BSD style locks such as implemented by flock are translated to POSIX
advisory file locks (implemented by the fcntl system call on Linux). It
is not possible to lock a directory using POSIX advisory file locks.
Hence, the lock strategy used by Buildroot doesn't work when used over
NFS.
Using flock on a simple file works correctly though, so use a '.lock'
file inside the download directory instead. If the lockfile does not
exist, flock will create it (in a race-free fashion).
Tested using NFS v4.2 and Linux 5.4.43.
Signed-off-by: Maxim Cournoyer <maxim.cournoyer@savoirfairelinux.com>
[yann.morin.1998@free.fr:
- slightly expand commit log about creation of the lockfile
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 2e9d6565fc)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
CVE-2020-8177: curl overwrite local file with -J.
CVE-2020-8169: Partial password leak over DNS on HTTP redirect.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 8370769d4a)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This patch fix the irrlicht makefile which contains the paths
that point to the host system libraries that are not used and
are not available in Buildroot what's unsafe for cross-compilation.
In addition it fixes linking to the X11 libraries and the following errors:
/home/bartekk/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-gnueabihf/9.2.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld: /home/bartekk/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libIrrlicht.so: undefined reference to `XSetSelectionOwner'
/home/bartekk/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-gnueabihf/9.2.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld: /home/bartekk/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libIrrlicht.so: undefined reference to `glXGetProcAddress'
/home/bartekk/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-gnueabihf/9.2.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld: /home/bartekk/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libIrrlicht.so: undefined reference to `glXMakeCurrent'
/home/bartekk/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-gnueabihf/9.2.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld: /home/bartekk/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libIrrlicht.so: undefined reference to `XF86VidModeSetViewPort'
/home/bartekk/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-gnueabihf/9.2.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld: /home/bartekk/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libIrrlicht.so: undefined reference to `XF86VidModeSwitchToMode'
/home/bartekk/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-gnueabihf/9.2.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld: /home/bartekk/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libIrrlicht.so: undefined reference to `glClearDepth'
/home/bartekk/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-gnueabihf/9.2.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld: /home/bartekk/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libIrrlicht.so: undefined reference to `XGetVisualInfo'
/home/bartekk/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-gnueabihf/9.2.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld: /home/bartekk/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libIrrlicht.so: undefined reference to `XGrabKeyboard'
/home/bartekk/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-gnueabihf/9.2.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld: /home/bartekk/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libIrrlicht.so: undefined reference to `glMatrixMode'
Signed-off-by: Bartosz Bilas <b.bilas@grinn-global.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 98c57af89d)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issue:
* CVE-2020-13777: It was found that GnuTLS 3.6.4 introduced a
regression in the TLS protocol implementation. This caused the TLS
server to not securely construct a session ticket encryption key
considering the application supplied secret, allowing a MitM
attacker to bypass authentication in TLS 1.3 and recover previous
conversations in TLS 1.2
Release announcement:
https://lists.gnupg.org/pipermail/gnutls-help/2020-June/004648.html
Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com>
[yann.morin.1998@free.fr: two spaces in hash file]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 16ea3ee784)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The LICENSE file is MIT, not BSD. The confusion comes from the license info
in setup.py, which stated BSD until (post-0.14.2):
669129a3d3
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit d682a3aeb9)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit 1ebb35ee5f changed the libopenssl
target architecture to 'linux-generic64' for 64-bit archs based on
BR2_ARCH_IS_64. However, MIPS64n32 has BR2_ARCH_IS_64 set, but is a 32-bit
ABI. On such board, libopenssl needs to be configured with linux-generic32
to function properly.
One symptom of this problem is that ssh-keygen hangs on key generation,
waiting for more random bits. See [1] for the discussion with openssl
upstream.
Thanks to Ronny Meeus for investigating the issue and kudos to the openssl
community for their responsive and helpful interaction!
Reported-by: Ronny Meeus <ronny.meeus@nokia.com>
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
[1] https://mta.openssl.org/pipermail/openssl-users/2020-June/012565.html
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 42718e13d2)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issues:
- bpo-40121: Fixes audit events raised on creating a new socket
- bpo-38576: Disallow control characters in hostnames in http.client,
addressing CVE-2019-18348. Such potentially malicious header injection
URLs now cause a InvalidURL to be raised.
- bpo-39503: CVE-2020-8492: The AbstractBasicAuthHandler class of the
urllib.request module uses an inefficient regular expression which can be
exploited by an attacker to cause a denial of service. Fix the regex to
prevent the catastrophic backtracking. Vulnerability reported by Ben
Caller and Matt Schwager.
For more details, see the changelog:
https://docs.python.org/release/3.8.3/whatsnew/changelog.html#security
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 5ff01eb31f)
[Peter: mention security impact]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
By default, open-plc-utils installs all of the compiled binaries to
/usr/local/bin which is not in the default path provided by Buildroot.
Passing BIN="$(TARGET_DIR)/usr/bin" to make install forces open-plc-utils to
install the compiled binaries to /usr/bin.
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 35bbcde75c)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This is a crucial bugfix release that fixes a backward incompatible ABI
change introduced in 1.3.2.
Also drop patches that are now applied upstream.
Signed-off-by: Titouan Christophe <titouan.christophe@railnova.eu>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 57053f29b7)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Buildroot currently installs openjdk-bin to $(HOST_DIR)/ instead of the more
traditional (for java installations) $(HOST_DIR)/usr/lib/jvm.
As described in https://bugs.busybox.net/show_bug.cgi?id=13001
"Openjdk-bin provides it's own libfreetype.so and places it into
$(HOST_DIR)/lib/. This library causes build failures with the
host-xapp_mkfontscale package due to the overwritten libfreetype.so.
mkfontscale.o: In function `doDirectory':
mkfontscale.c:(.text+0x1a80): undefined reference to `FT_Get_BDF_Property'
collect2: error: ld returned 1 exit status
Reproducing the error is done by repeating the following steps.
make host-freetype
make host-openjdk-bin
make host-xapp_mkfontscale"
There are two options for fixing this problem:
1) add host-freetype and host-lksctp-tools as dependencies to host-openjdk-bin
and then remove the provided libfreetype.so and libsctp.so libraries
in a post_extract_hook.
2) change the installation directory from $(HOST_DIR)/ to
$(HOST_DIR)/usr/lib/jvm just like the target OpenJDK package and
copy the entire source directories contents to the above location.
The second option provides the following advantages:
- the directory structure is consistent with how we handle the target OpenJDK.
- the HOST_OPENJDK_BIN_INSTALL_CMDS step is simplified.
- packages such as Maven require directories of which we are currently not
copying. These missing directories cause programs such as Maven to crash
when running with an error such as
"Can't read cryptographic policy directory: unlimited."
- does not miss any other libraries that solution 1 would not cope with
(e.g. libzip.so from host-libzip, or libnet.so from not-yet existing
host-libnet, or libsctp.so from not-yet existing host-lksctp-tools)
Because the second option is both simple, easier to implement, is low-impact,
and fixes the problems described above wholly, it is the best to implement.
To implement the above changes, we must also modify the following files in the
same patch to match the host's new directory paths:
- openjdk.mk
- openjdk-jni-test.mk
- openjdk-hello-world.mk
To avoid having to change all those packages in the future, expose two
new variables, HOST_OPENJDK_BIN_ROOT_DIR which contains the path where
the openjdk-bin was installed in, and JAVAC, which contains the path to
the javac compiler (modeled after the way the autoconf et al. variables
are set and exposed).
Tested with:
./support/testing/run-tests -o out -d dl tests.package.test_openjdk.TestOpenJdk
Fixes: https://bugs.busybox.net/show_bug.cgi?id=13001
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
[yann.morin.1998@free.fr:
- introduce HOST_OPENJDK_BIN_ROOT_DIR and JAVAC
- expand and tweak the commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit e9a02417f3)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Older versions of git store the absolute path of the submodules'
repository as stored in the super-project, e.g.:
$ cat some-submodule/.git
gitdir: /path/to/super-project/.git/modules/some-submodule
Obviously, this is not very reproducible.
More recent versions of git, however, store relative paths, which
de-facto makes it reproducible.
Fix older versions by replacing the absolute paths with relative ones.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 8fe9894f65)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
All systemd binaries depend on libsystemd-shared and need their RPATH
fixed. Use a glob to catch them all.
We can't use $(wildcard ...) because this is expanded before any file
may exist (it's in the same rule that install those file, and the
expansion in Makefile is done once at the beginning of the recipe).
We need to test each file:
1. to ignore files that were not build (e.g. because the host is
missing some dependencies (in which case we don't care; we're only
interested in systemctl, and that one is already built)
2. to ensure the glob was expanded (in case no file would match
systemd-*)
Signed-off-by: Norbert Lange <nolange79@gmail.com>
[yann.morin.1998@free.fr:
- don't use 'set -e', use the more traditional '|| exit 1'
- don't cd into HOST_DIR/bin, but use $(addprefix ...)
- use positive logic in the test
- expand commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 9f1a9ee932)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
- Fix CVE-2020-12740: tcprewrite in Tcpreplay through 4.3.2 has a
heap-based buffer over-read during a get_c operation. The issue is
being triggered in the function get_ipv6_next() at common/get.c.
- Update indentation in hash file (two spaces)
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 25168d220a)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, GNU Make expands the Python SYSCONFIGDATA_NAME variable;
however, when building with per-package directories, this variable is
not set because the evaluation of this variable occurs before buildroot
creates the per-package directories of a given package.
This can be easily demonstrated with that trivial Makefile:
$ cat Makefile
BLA = $(wildcard bla)
all:
@echo 'BLA=$(BLA)'
@touch bla
@echo 'BLA=$(BLA)'
$ make
BLA=
BLA=
$ make
BLA=bla
BLA=bla
I.e. the variables are evaluated at the beginning of a recipe, not for
each line of the recipe.
There are two solutions to fix this problem:
- add a step between "patch" and "configure," which would evaluate all
of the variables after creating the per-package directories;
- evaluate SYSCONFIGDATA_NAME via a shell expansion instead of
Makefile, to postpone the effective ex[ansion to until after the
file has been created.
Even though the first option is semantically the best solution, this is
also very intrusive, especially since python3 is so far the only case
where we would need it. The second option however is more expedient, adn
so this is what we're doing here.
We introduce PKG_PYTHON_SYSCONFIGDATA_PATH to avoid duplication and to
make the following line easier to read.
Then PKG_PYTHON_SYSCONFIGDATA_NAME is actually defined as a back-tick
shell expansion (although back-ticks have their drawbacks, using $(...)
in Makefile is not trivial either):
- we test that the file does exist, to cover the python2 and python3
cases: with python2, the file does not exist, so we want to expand
to an empty string; 'basename' only works on the filename, and does
not check the file actually exists;
- if the file exist, we get its basename without the .py extension,
and this makes our expansion;
- the "|| true" is added to ensure the old behavior of returning an
empty string if the file does not exist still works, when the
expansion is attempted in a shell where 'set -e' is in effect (the
test would fail with python2, but this is not an error).
Fixes: https://bugs.busybox.net/show_bug.cgi?id=12941
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
[yann.morin.1998@free.fr: slight rewording in commit log]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 2158c87206)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The error is misleading: it reports that no name was provided,
when in fact the external.desc file is missing.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>p
Reviewed-by: Romain Naour <romain.naour@gmail.com>
(cherry picked from commit c62e78a85b)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When a br2-external tree has an issue, e.g. a missing file, or does not
have a name, or the name uses invalid chars, we report that condition by
setting the variable BR2_EXTERNAL_ERROR.
That variable is defined in the script support/scripts/br2-external,
which outputs it on stdout, and checked by the Makefile.
Before d027cd75d0, stdout was explicitly redirected to the generated
.mk file, with exec >"${ofile}" as the Makefile and Kconfig
fragments were generated each with their own call to the script, and
the validation phase would emit the BR2_EXTERNAL_ERROR variable in the
Makefile fragment.
But with d027cd75d0, both the Makefile and Kconfig fragments were now
generated with a single call to the script, and as such the semantics of
the scripts changed, and only each of the actual generators, do_mk and
do_kconfig, had their out put redirected. Which left do_validate with
the default stdout. Which would emit BR2_EXTERNAL_ERROR on stdout.
In turn, the stdout of the script would be interpreted by as part of the
Makefile. But this does not end up very well when a br2-external tree
indeed has an error:
- missing a external.desc file:
Makefile:184: *** multiple target patterns. Stop.
- empty external.desc file:
Config.in:22: can't open file "output/.br2-external.in.paths"
So we must redirect the output of the validation step to the
Makefile fragment, so that the error message is correctly caught by the
top-level Makefile.
Note that we don't need to append in do_mk, and we can do an overwrite
redirection: if we go so far as to call do_mk, it means there was no
error, and thus the fragment is empty.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Tested-by: Romain Naour <romain.naour@gmail.com>
(cherry picked from commit 0ac7dcb73e)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
- Fix CVE-2020-12049: An issue was discovered in dbus >= 1.3.0 before
1.12.18. The DBusServer in libdbus, as used in dbus-daemon, leaks file
descriptors when a message exceeds the per-message file descriptor
limit. A local attacker with access to the D-Bus system bus or another
system service's private AF_UNIX socket could use this to make the
system service reach its file descriptor limit, denying service to
subsequent D-Bus clients.
- Also update indentation in hash file (two spaces)
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 7cee9d2659)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
A gcc compiler, which was configured with
--with-gcc-major-version-only, will only return a single
number. (debian does this for example).
A simple modification allows the check to work with both
single numbers (eg. '9') and full versions (eg. '9.2.1').
Signed-off-by: Norbert Lange <nolange79@gmail.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 5303e72a80)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since cf75d7da98 we have a build failures when
building libgbm.so when valgrind package is selected because --static is always
passed to pkg-config even for shared build.
Even if -Dvalgrind=false on meson command line to build mesa, the valgrind
libraries come from pkg-config libdrm...
output/host/bin/pkg-config libdrm --libs --static
-L[...]/sysroot/usr/lib -ldrm -lm -L[...]/sysroot/usr/lib/valgrind
-lcoregrind-arm64-linux -lvex-arm64-linux -lgcc
... and break the build.
See initial discussions:
http://lists.busybox.net/pipermail/buildroot/2020-June/284543.html
This is due to a wrong condition test added by the patch
0004-mesonbuild-dependencies-base.py-add-pkg_config_stati.patch.
Indeed, pkg_config_static is a string, not a boolean; it is set to
either 'true' or 'aflse' by our meson package infra. Since the returned
object is a string, do not pass a boolean, but pas None (we only want to
test against the 'true' string, so we don't care what we get back when
it is not set, which never happens in Buildroot).
Before this patch, the issue can be reproduced using the following defconfig:
BR2_aarch64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_PACKAGE_VALGRIND=y
BR2_PACKAGE_MESA3D=y
BR2_PACKAGE_MESA3D_DRI_DRIVER_SWRAST=y
Fixes:
http://autobuild.buildroot.net/results/1b5/1b58d73ecbbe1af2c3e140563d696cf32d1c4a5a/build-end.log
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: James Hilliard <james.hilliard1@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[yann.morin.1998@free.fr: slightly reword the commit log]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 6ae1932e71)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes (on startup):
$ usr/libexec/iwd
Wireless daemon version 1.7
Failed to initialize D-Bus
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
[yann.morin.1998@free.fr:
- move MMU dependency first
- split long line in comment dependencies
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 6f5f6bcd89)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
