New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Buildroot 2019.11 with GCC 9.2 build fails with "xgcc: No such file or directory" #108
Comments
I'm also having this issue with buildroot 2020.02 (not from your repo). I could fix it by deleting the out/build/ directory and running make again. Had to do this evry time I build, so I used binutils 2.32, I assume some build variables are set wrong at first build, so when I started build again after deleting the dir, some variables other builds set aren't set anymore. |
Just apply this patch to gcc:
|
Thank you! |
As reported by several Buildroot users [1][2][3], the gcc build may fail while running selftests makefile target. The problem only occurs when ccache is used with gcc 9 and 10, probably due to a race condition. While debuging with "make -p" we can notice that s-selftest-c target contain only "cc1" as dependency instead of cc1 and SELFTEST_DEPS [4]. s-selftest-c: cc1 While the build is failing, the s-selftest-c dependencies recipe is still running and reported as a bug by make. "Dependencies recipe running (THIS IS A BUG)." A change [5] in gcc 9 seems to introduce the problem since we can't reproduce this problem with gcc 8. As suggested by Yann E. MORIN [6], move SELFTEST_DEPS before including language makefile fragments. With the fix applied, the s-seltest-c dependency contains SELFTEST_DEPS value. s-selftest-c: cc1 xgcc specs stmp-int-hdrs ../../gcc/testsuite/selftests [1] http://lists.busybox.net/pipermail/buildroot/2020-May/282171.html [2] http://lists.busybox.net/pipermail/buildroot/2020-May/282766.html [3] cirosantilli/linux-kernel-module-cheat#108 [4] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/c/Make-lang.in;h=bfae6fd2549c4f728816cd355fa9739dcc08fcde;hb=033eb5671769a4c681a44aad08a454e667e08502#l120 [5] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=033eb5671769a4c681a44aad08a454e667e08502 [6] http://lists.busybox.net/pipermail/buildroot/2020-May/283213.html Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: Ben Dakin-Norris <ben.dakin-norris@navtechradar.com> Cc: Maxim Kochetkov <fido_max@inbox.ru> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
As reported by several Buildroot users [1][2][3], the gcc build may fail while running selftests makefile target. The problem only occurs when ccache is used with gcc 9 and 10, probably due to a race condition. While debuging with "make -p" we can notice that s-selftest-c target contain only "cc1" as dependency instead of cc1 and SELFTEST_DEPS [4]. s-selftest-c: cc1 While the build is failing, the s-selftest-c dependencies recipe is still running and reported as a bug by make. "Dependencies recipe running (THIS IS A BUG)." A change [5] in gcc 9 seems to introduce the problem since we can't reproduce this problem with gcc 8. As suggested by Yann E. MORIN [6], move SELFTEST_DEPS before including language makefile fragments. With the fix applied, the s-seltest-c dependency contains SELFTEST_DEPS value. s-selftest-c: cc1 xgcc specs stmp-int-hdrs ../../gcc/testsuite/selftests [1] http://lists.busybox.net/pipermail/buildroot/2020-May/282171.html [2] http://lists.busybox.net/pipermail/buildroot/2020-May/282766.html [3] cirosantilli/linux-kernel-module-cheat#108 [4] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/c/Make-lang.in;h=bfae6fd2549c4f728816cd355fa9739dcc08fcde;hb=033eb5671769a4c681a44aad08a454e667e08502#l120 [5] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=033eb5671769a4c681a44aad08a454e667e08502 [6] http://lists.busybox.net/pipermail/buildroot/2020-May/283213.html Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: Ben Dakin-Norris <ben.dakin-norris@navtechradar.com> Cc: Maxim Kochetkov <fido_max@inbox.ru> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> (cherry picked from commit 58ecbbc) Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Squashed commit of the following: commit 5382d50c2b59002d13d29e0298452163318feb32 Merge: dd36674066 6306cf35c5 Author: Frank Schütte <fschuett@gymhim.de> Date: Fri Jul 3 08:12:15 2020 +0200 Add 'buildroot/' from commit '95fdb33f71f8a2d6a6e86fa3c6eb2968b6440b88' git-subtree-dir: buildroot git-subtree-mainline: dd36674066bb6bde1b38ce14f5c81ddbd6b5bcb2 git-subtree-split: 95fdb33f71f8a2d6a6e86fa3c6eb2968b6440b88 commit dd36674066bb6bde1b38ce14f5c81ddbd6b5bcb2 Author: Frank Schütte <fschuett@gymhim.de> Date: Fri Jul 3 08:10:50 2020 +0200 remove old buildroot branch commit 6306cf35c5936184c09fa1f5678c3381e330fe2b Author: Peter Korsgaard <peter@korsgaard.com> Date: Mon Jun 1 23:11:33 2020 +0200 Update for 2020.05 Signed-off-by: Peter Korsgaard <peter@korsgaard.com> commit e0f5cc8f66c44088cc858ab97e460e7f4d06faf3 Author: Peter Korsgaard <peter@korsgaard.com> Date: Mon Jun 1 22:41:56 2020 +0200 {linux, linux-headers}: bump 4.{4, 9, 14, 19}.x / 5.{4, 6}.x series Signed-off-by: Peter Korsgaard <peter@korsgaard.com> commit 050abf7677a015bbb0b382d79b4a64aff02f7df6 Author: Fabrice Fontaine <fontaine.fabrice@gmail.com> Date: Mon Jun 1 11:54:32 2020 +0200 package/wampcc fix build with musl 1.2.0 Fixes: - http://autobuild.buildroot.org/results/da996e189220499b85efbdb541a891ac18db38c6 Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com> commit 9740b9bcdd9167195498393098e89915ee564691 Author: Matt Weber <matthew.weber@rockwellcollins.com> Date: Mon Jun 1 07:30:36 2020 -0500 DEVELOPERS: cleanup rockwellcollins.com maintainers Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com> commit 8f3d361f5ccbb43270f9e69bf6ac472698d3722e Author: Fabrice Fontaine <fontaine.fabrice@gmail.com> Date: Sun May 31 10:49:02 2020 +0200 package/glib-networking: security bump to version 2.62.4 - Fix CVE-2020-13645: In GNOME glib-networking through 2.64.2, the implementation of GTlsClientConnection skips hostname verification of the server's TLS certificate if the application fails to specify the expected server identity. This is in contrast to its intended documented behavior, to fail the certificate verification. Applications that fail to provide the server identity, including Balsa before 2.5.11 and 2.6.x before 2.6.1, accept a TLS certificate if the certificate is valid for any host. - Update indentation in hash file (two spaces) Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> [Peter: bump to 2.62.4 rather than 2.64.3] Signed-off-by: Peter Korsgaard <peter@korsgaard.com> commit 3a9261ddd917007e19b56b4bfe48ccc0861dd716 Author: Fabrice Fontaine <fontaine.fabrice@gmail.com> Date: Sun May 31 16:16:23 2020 +0200 package/libusb-compat: set LIBUSB_1_0_SONAME LIBUSB_1_0_SONAME is detected since version 0.1.6 and https://github.com/libusb/libusb-compat-0.1/commit/b6f5a2fe12ca19d658d7180e106254b31cf1f8f5 The detection mechanism is based on sed, here are the more relevant parts: shrext_regexp=`echo "$shrext_cmds" | sed 's/\./\\\\./'` [...] [AS_VAR_SET([ac_Lib_SONAME], [`ldd conftest$ac_exeext | grep 'lib[$2]'$shrext_regexp | sed 's/^@<:@ \t@:>@*lib[$2]'$shrext_regexp'/lib[$2]'$shrext_regexp'/;s/@<:@ \t@:>@.*$//'`])]) However, this mechanism is broken with sed 4.7 and will return the following 'silent' error: checking for SONAME of libusb-1.0... sed: -e expression #1, char 40: Invalid back reference unknown Moreover, it also raises the following build failure on one of the autobuilder because an empty line is added to LIBUSB_1_0_SONAME: checking for SONAME of libusb-1.0... checking libusb-1.0.so.0 checking for GNU extensions of errno.h... no configure: WARNING: cache variable au_cv_lib_soname_LIBUSB_1_0 contains a newline checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating libusb.pc config.status: creating libusb-config config.status: creating Makefile config.status: creating libusb/Makefile config.status: creating examples/Makefile config.status: creating config.h config.status: executing depfiles commands config.status: executing libtool commands config.status: executing default commands configure: WARNING: unrecognized options: --disable-gtk-doc, --disable-gtk-doc-html, --disable-doc, --disable-docs, --disable-documentation, --with-xmlto, --with-fop, --enable-ipv6, --disable-nls configure: WARNING: cache variable au_cv_lib_soname_LIBUSB_1_0 contains a newline [7m>>> libusb-compat 0.1.7 Building[27m PATH="/usr/lfs/hdd_v1/rc-buildroot-test/scripts/instance-0/output-1/host/bin:/usr/lfs/hdd_v1/rc-buildroot-test/scripts/instance-0/output-1/host/sbin:/accts/mlweber1/bin:/accts/mlweber1/libexec/git-core:/accts/mlweber1/usr/bin:/accts/mlweber1/usr/local/bin:/accts/mlweber1/bin:/accts/mlweber1/libexec/git-core:/accts/mlweber1/usr/bin:/accts/mlweber1/usr/local/bin:/accts/mlweber1/bin:/accts/mlweber1/libexec/git-core:/accts/mlweber1/usr/bin:/accts/mlweber1/usr/local/bin:/accts/mlweber1/bin:/accts/mlweber1/libexec/git-core:/accts/mlweber1/usr/bin:/accts/mlweber1/usr/local/bin:/accts/mlweber1/bin:/accts/mlweber1/libexec/git-core:/accts/mlweber1/usr/bin:/accts/mlweber1/usr/local/bin:/accts/mlweber1/bin:/accts/mlweber1/libexec/git-core:/accts/mlweber1/usr/bin:/accts/mlweber1/usr/local/bin:/accts/mlweber1/bin:/accts/mlweber1/libexec/git-core:/accts/mlweber1/usr/bin:/accts/mlweber1/usr/local/bin:/accts/mlweber1/bin:/accts/mlweber1/libexec/git-core:/accts/mlweber1/usr/bin:/accts/mlweber1 /usr/local/bin:/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin" /usr/bin/make -j8 -C /usr/lfs/hdd_v1/rc-buildroot-test/scripts/instance-0/output-1/build/libusb-compat-0.1.7/ make[1]: Entering directory `/usr/lfs/hdd_v1/rc-buildroot-test/scripts/instance-0/output-1/build/libusb-compat-0.1.7' Makefile:284: *** missing separator. Stop. We could patch patch m4/au_check_lib_soname.m4 to fix the mechanism however this is difficult without reproducing the autobuilder failure and upstream seems dead so just set LIBUSB_1_0_SONAME Fixes: - http://autobuild.buildroot.org/results/12d771d85d30594929cfe3e1c783fc70857e7f5f Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> [yann.morin.1998@free.fr: extract the actual SONAME from the library] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> commit d25a5724c02a79049b9cf17a24c5f5c0ff010b2a Author: Yann E. MORIN <yann.morin.1998@free.fr> Date: Wed May 13 19:48:09 2020 +0200 package/linux-headers: add support for CIP kernel versions with same-as-kernel When the linux-headers are configured to use the same source as the kernel (BR2_KERNEL_HEADERS_AS_KERNEL), and the kernel is configured to be one of the two CIP versions (BR2_LINUX_KERNEL_LATEST_CIP_VERSION or BR2_LINUX_KERNEL_LATEST_CIP_RT_VERSION), the build fails if the kernel sources are not already downloaded: $ cat defconfig BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_LATEST_CIP_VERSION=y $ make defconfig BR2_DEFCONFIG=$pwd)/defconfig $ make linux-headers-source >>> linux-headers 4.19.118-cip25 Downloading --2020-05-13 19:28:44-- https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.19.118-cip25.tar.xz Resolving cdn.kernel.org (cdn.kernel.org)... 2a04:4e42:1d::432, 151.101.121.176 Connecting to cdn.kernel.org (cdn.kernel.org)|2a04:4e42:1d::432|:443... connected. HTTP request sent, awaiting response... 404 Not Found 2020-05-13 19:28:45 ERROR 404: Not Found. make[1]: *** [package/pkg-generic.mk:171: /home/ymorin/dev/buildroot/O/build/linux-headers-4.19.118-cip25/.stamp_downloaded] Error 1 make: *** [Makefile:23: _all] Error 2 We fix that by adding yet another duplication of information out of the linux.mk, to use the CIP-specific git tree where to get the archives as snapshots. Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> commit 40e0bf4c0c36970f8e94591fdb0a5a8910bf9859 Author: Yann E. MORIN <yann.morin.1998@free.fr> Date: Tue May 12 22:33:53 2020 +0200 linux: forcibly disable use of gcc plugins The soon-to-be-released linux 5.7 has changed the way it detects the ability of gcc to use plugins, when it dropped support for gcc 4.7 or older [0]. To detect the ability to use gcc plugins, the kernel has to check whether the host gcc is capable enough to build them. When we call one of the configurator for the Linux kernel, we explicitly pass a value of HOSTCC=$(HOSTCC_NOCCACHE), because there might be a discrepancy between the ncurses headers and libraries as found by the Linux kconfig build [1] [2]. But then, when we build the kernel, we pass another value to use [3] HOSTCC="$(HOSTCC) $(HOST_CFLAGS) $(HOST_LDFLAGS)" which boils down to roughly: gcc -I.../host/include -L.../host/lib -Wl,-rpath,.../host/lib This is needed so that at build time, the kernel can build host tools that link with our openssl et al. So, the two HOSTCC we pass to the kernel may have different behaviours. For example, on a machine where gmp is missing in the system, it is available in $(O)/host/ when using an internal toolchain (and under a few other conditions). In that case, when configuring the kernel, it decides that the host compiler can't build plugins, so the dependencies of CONFIG_GCC_PLUGINS are not met, and that option is not present in the linux' .config file (neither as "=y" nor as "is not set"). But then, when we build the kernel, the host compiler suddenly becomes capable of building the plugins, and the internal syncconfig run by the kernel will notice that the dependencies of CONFIG_GCC_PLUGINS are now met, and that the user shall decide on its value. And this blocks a build on an interactive console (abbreviated): * Restart config... * GCC plugins GCC plugins (GCC_PLUGINS) [Y/n/?] (NEW) _ But most problematic is the behaviour when run in a shell that is not interactiove (e.g. a CI job or such) (abbreviated): * Restart config... * GCC plugins GCC plugins (GCC_PLUGINS) [Y/n/?] (NEW) Error in reading or end of file. Generate some entropy during boot and runtime (GCC_PLUGIN_LATENT_ENTROPY) [N/y/?] (NEW) Error in reading or end of file. Randomize layout of sensitive kernel structures (GCC_PLUGIN_RANDSTRUCT) [N/y/?] (NEW) Error in reading or end of file. * Memory initialization Initialize kernel stack variables at function entry > 1. no automatic initialization (weakest) (INIT_STACK_NONE) 2. zero-init structs marked for userspace (weak) (GCC_PLUGIN_STRUCTLEAK_USER) (NEW) 3. zero-init structs passed by reference (strong) (GCC_PLUGIN_STRUCTLEAK_BYREF) (NEW) 4. zero-init anything passed by reference (very strong) (GCC_PLUGIN_STRUCTLEAK_BYREF_ALL) (NEW) choice[1-4?]: Error in reading or end of file. Poison kernel stack before returning from syscalls (GCC_PLUGIN_STACKLEAK) [N/y/?] (NEW) Error in reading or end of file. Enable heap memory zeroing on allocation by default (INIT_ON_ALLOC_DEFAULT_ON) [N/y/?] n Enable heap memory zeroing on free by default (INIT_ON_FREE_DEFAULT_ON) [N/y/?] n The most obvious and simple solution would be to unconditionally disable gcc plugins altogether, in the KCONFIG_FIXUP hook. But that can't work either, because after applying the fixups, we call olddefconfig (or the likes) with the incapable HOSTCC, so the disabled option would be removed anyway, and we'd be back to square one. So, in addition to the above, we also forcibly hack the same call just before actually building the kernel. Note that the two are needed: the one in the fixups is needed for those that have a system that already allows building gcc plugins, and the second is needed in the other case, where the system does not allow it but would work with our additional headers and libs in $(O)/host/. The two ensure there is a very similar experience in the two situations. Forcibly disabling the use of gcc plugins is not a regression on our side: it has never been possible to do so so far. We're now making sure that can't work by accident. Reported-by: Ganesh <ganesh45in@gmail.com>, Reported-by: Heiko Thiery <heiko.thiery@gmail.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Michael Walle <michael.walle@kontron.com> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Arnout Vandecappelle <arnout@mind.be> Tested-by: Heiko Thiery <heiko.thiery@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> commit f9548114d861289e7490594a704fff32f65559b3 Author: Romain Naour <romain.naour@gmail.com> Date: Sun May 24 17:58:18 2020 +0200 package/qt5/qt5webengine: don't link with libstdc++.a on the host While cross-compiling, qt5webengine is building a host tool, 'gn', and by default wants to link it statically with libstdc++, when the tool is otherwise dynamically linked with other libraries: $ ldd 3rdparty/gn/out/Release/gn linux-vdso.so.1 (0x00007ffc1c999000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f48a3c06000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f48a3be4000) libc.so.6 => /lib64/libc.so.6 (0x00007f48a3a1b000) /lib64/ld-linux-x86-64.so.2 (0x00007f48a3c53000) Not all ditributions have the static libraries installed by default; for example, on Fedora, libstdc++-static is not installed on a fresh system, leading to build issues: [185/185] LINK gn FAILED: gn /usr/bin/g++ -O3 -fdata-sections -ffunction-sections -Wl,--gc-sections -Wl,-strip-all -Wl,--as-needed -static-libstdc++ -pthread -o gn -Wl,--start-group tools/gn/gn_main.o base.a gn_lib.a -Wl,--end-group -ldl /usr/bin/ld : unable to find -lstdc++ [...] Project ERROR: GN build error! The root cause is the addition in [0] of a command line option to the build of gn, that requests static linking with libstdc++ by default. Explicitly pass that option now, to avoid static linking with libstdc++ and get a fully dynamicallty linked executable: $ ldd 3rdparty/gn/out/Release/gn linux-vdso.so.1 (0x00007ffd3f160000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f68138e7000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f68138c5000) libc.so.6 => /lib64/libc.so.6 (0x00007f68136fc000) libm.so.6 => /lib64/libm.so.6 (0x00007f68135b6000) /lib64/ld-linux-x86-64.so.2 (0x00007f6813b13000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f681359c000) [0] https://github.com/qt/qtwebengine-chromium/commit/cfab9198a9917f42cf08b1caf84ab9b71aac1911#diff-905c8f054808213577c0a92d1b704615 Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: Gaël Portay <gael.portay@collabora.com> [yann.morin.1998@free.fr: - rewrite the commit log with extra details and explanations ] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> commit 58ecbbc3ef18c43ae1c02a5c4bf30aa7ef2d8092 Author: Romain Naour <romain.naour@gmail.com> Date: Thu May 21 18:53:45 2020 +0200 package/gcc/9.3.0: fix host-gcc-final when ccache is used As reported by several Buildroot users [1][2][3], the gcc build may fail while running selftests makefile target. The problem only occurs when ccache is used with gcc 9 and 10, probably due to a race condition. While debuging with "make -p" we can notice that s-selftest-c target contain only "cc1" as dependency instead of cc1 and SELFTEST_DEPS [4]. s-selftest-c: cc1 While the build is failing, the s-selftest-c dependencies recipe is still running and reported as a bug by make. "Dependencies recipe running (THIS IS A BUG)." A change [5] in gcc 9 seems to introduce the problem since we can't reproduce this problem with gcc 8. As suggested by Yann E. MORIN [6], move SELFTEST_DEPS before including language makefile fragments. With the fix applied, the s-seltest-c dependency contains SELFTEST_DEPS value. s-selftest-c: cc1 xgcc specs stmp-int-hdrs ../../gcc/testsuite/selftests [1] http://lists.busybox.net/pipermail/buildroot/2020-May/282171.html [2] http://lists.busybox.net/pipermail/buildroot/2020-May/282766.html [3] https://github.com/cirosantilli/linux-kernel-module-cheat/issues/108 [4] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/c/Make-lang.in;h=bfae6fd2549c4f728816cd355fa9739dcc08fcde;hb=033eb5671769a4c681a44aad08a454e667e08502#l120 [5] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=033eb5671769a4c681a44aad08a454e667e08502 [6] http://lists.busybox.net/pipermail/buildroot/2020-May/283213.html Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: Ben Dakin-Norris <ben.dakin-norris@navtechradar.com> Cc: Maxim Kochetkov <fido_max@inbox.ru> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> commit 1a14a838eaa88ae683bf8c0cb0ae6cc7e1d10d49 Author: Heiko Thiery <heiko.thiery@gmail.com> Date: Wed May 27 09:11:13 2020 +0200 package/sysrepo: fix SysV init script The current script (S51sysrepo-plugind) is not able to stop the daemon. Possible options to fix the problem: A) By adding the "-m -p $PIDFILE" option to start the pid file will be created but it will not contain the correct PID used by the daemon. This is obviously because the daemon forks. B) By not starting the daemon in background (sysrepo-plugind -d) and let do it by start-stop-daemon with "-b" option. But then the log messages of the daemon will not longer ends in the syslog but to stderr. C) Start the daemon without a pidfile and stop the daemon with the "-x" option. The only valid option is C to fix that. Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com> [yann.morin.1998@free.fr: introduce EXECUTABLE] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> commit ae417368f52518735dfce6c83d8e064298e6d0dd Author: Carlos Santos <unixmania@gmail.com> Date: Fri May 29 17:32:04 2020 -0300 DEVELOPERS: remove Carlos Santos Goodbye! Signed-off-by: Carlos Santos <unixmania@gmail.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> commit 0caabc8cda933b32660867b270151451f77b6e14 Author: Fabrice Fontaine <fontaine.fabrice@gmail.com> Date: Sat May 30 14:25:32 2020 +0200 package/xen: security bump to version 4.13.1 - Fix CVE-2020-11739: An issue was discovered in Xen through 4.13.x, allowing guest OS users to cause a denial of service or possibly gain privileges because of missing memory barriers in read-write unlock paths. The read-write unlock paths don't contain a memory barrier. On Arm, this means a processor is allowed to re-order the memory access with the preceding ones. In other words, the unlock may be seen by another processor before all the memory accesses within the "critical" section. As a consequence, it may be possible to have a writer executing a critical section at the same time as readers or another writer. In other words, many of the assumptions (e.g., a variable cannot be modified after a check) in the critical sections are not safe anymore. The read-write locks are used in hypercalls (such as grant-table ones), so a malicious guest could exploit the race. For instance, there is a small window where Xen can leak memory if XENMAPSPACE_grant_table is used concurrently. A malicious guest may be able to leak memory, or cause a hypervisor crash resulting in a Denial of Service (DoS). Information leak and privilege escalation cannot be excluded. - Fix CVE-2020-11740: An issue was discovered in xenoprof in Xen through 4.13.x, allowing guest OS users (without active profiling) to obtain sensitive information about other guests. Unprivileged guests can request to map xenoprof buffers, even if profiling has not been enabled for those guests. These buffers were not scrubbed. - Fix CVE-2020-11741: An issue was discovered in xenoprof in Xen through 4.13.x, allowing guest OS users (with active profiling) to obtain sensitive information about other guests, cause a denial of service, or possibly gain privileges. For guests for which "active" profiling was enabled by the administrator, the xenoprof code uses the standard Xen shared ring structure. Unfortunately, this code did not treat the guest as a potential adversary: it trusts the guest not to modify buffer size information or modify head / tail pointers in unexpected ways. This can crash the host (DoS). Privilege escalation cannot be ruled out. - Fix CVE-2020-11742: An issue was discovered in Xen through 4.13.x, allowing guest OS users to cause a denial of service because of bad continuation handling in GNTTABOP_copy. Grant table operations are expected to return 0 for success, and a negative number for errors. The fix for CVE-2017-12135 introduced a path through grant copy handling where success may be returned to the caller without any action taken. In particular, the status fields of individual operations are left uninitialised, and may result in errant behaviour in the caller of GNTTABOP_copy. A buggy or malicious guest can construct its grant table in such a way that, when a backend domain tries to copy a grant, it hits the incorrect exit path. This returns success to the caller without doing anything, which may cause crashes or other incorrect behaviour. - Fix CVE-2020-11743: An issue was discovered in Xen through 4.13.x, allowing guest OS users to cause a denial of service because of a bad error path in GNTTABOP_map_grant. Grant table operations are expected to return 0 for success, and a negative number for errors. Some misplaced brackets cause one error path to return 1 instead of a negative value. The grant table code in Linux treats this condition as success, and proceeds with incorrectly initialised state. A buggy or malicious guest can construct its grant table in such a way that, when a backend domain tries to map a grant, it hits the incorrect error path. This will crash a Linux based dom0 or backend domain. https://xenproject.org/downloads/xen-project-archives/xen-project-4-13-series/xen-project-4-13-1 Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> commit 9b91147545ab24c7fd23f9b052d95f0813f22d1c Author: Fabrice Fontaine <fontaine.fabrice@gmail.com> Date: Sat May 30 11:51:15 2020 +0200 package/mp4v2: fix build with gcc <= 5 Fixes: - http://autobuild.buildroot.org/results/14937c96a82fb3d10e5d83bd7b2905b846fb09f9 Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> [yann.morin.1998@free.fr: expand the patch' commit log] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> commit 36c0a0c65647bebe1050a2f9a7005fb44c24cf56 Author: Romain Naour <romain.naour@gmail.com> Date: Sat May 30 19:07:05 2020 +0200 boot/arm-trusted-firmware: ignore licencing check for user defined official version The commit [1] "licensing info is only valid for v1.4" fixed the legal-info issues when a custom ATF tarball or a version from git is used. But we need to ignore licencing for a used defined official ATF version. Althougt the ATF version are licensed under BSD-3-Clause, the license file can be updated between version (for example between v1.4 and v2.0). Ignore the licencing check if the user provide a custom official version. [1] d1a61703f728340ec894c367398d2a3a394a3360 Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: Yann E. MORIN <yann.morin.1998@free.fr> [yann.morin.1998@free.fr: use positive logic with the _LATEST option] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> commit 3bfe849189881d4872b5949739f91b1ed01b6622 Author: Yann E. MORIN <yann.morin.1998@free.fr> Date: Wed May 27 17:47:34 2020 +0200 package/{fmc,fmlib}: change repository location Now that Freescale has been wholly swallowed into NXP, the public-facing git repositories that were hosting those two packages are no longer available. Fortunately, they had been mirrored on Code Aurora forge (a Linux Foundation project, so relatively stable and trustworthy), which has the tags we need, and that generates the exact same archives. Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Matthew Weber <matthew.weber@rockwellcollins.com> Reviewed-by: Matthew Weber <matthew.weber@rockwellcollins.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> commit e118415151052365c5967687bce152a2c971ef7e Author: Peter Korsgaard <peter@korsgaard.com> Date: Fri May 29 22:45:33 2020 +0200 Update for 2020.05-rc3 Signed-off-by: Peter Korsgaard <peter@korsgaard.com> commit 0a860f21e1b8004ee937c20d54d29a5e66f96651 Author: Fabrice Fontaine <fontaine.fabrice@gmail.com> Date: Fri May 15 23:13:27 2020 +0200 package/mp4v2: security bump to version 4.1.3 - Switch site to an active fork - Send patch upstream - Update indentation in hash file (two spaces) - Fix the following CVEs: - CVE-2018-14054: A double free exists in the MP4StringProperty class in mp4property.cpp in MP4v2 2.0.0. A dangling pointer is freed again in the destructor once an exception is triggered. Fixed by https://github.com/TechSmith/mp4v2/commit/f09cceeee5bd7f783fd31f10e8b3c440ccf4c743 - CVE-2018-14325: In MP4v2 2.0.0, there is an integer underflow (with resultant memory corruption) when parsing MP4Atom in mp4atom.cpp. Fixed by https://github.com/TechSmith/mp4v2/commit/e475013c6ef78093055a02b0d035eda0f9f01451 - CVE-2018-14326: In MP4v2 2.0.0, there is an integer overflow (with resultant memory corruption) when resizing MP4Array for the ftyp atom in mp4array.h. Fixed by https://github.com/TechSmith/mp4v2/commit/70d823ccd8e2d7d0ed9e62fb7e8983d21e6acbeb - CVE-2018-14379: MP4Atom::factory in mp4atom.cpp in MP4v2 2.0.0 incorrectly uses the MP4ItemAtom data type in a certain case where MP4DataAtom is required, which allows remote attackers to cause a denial of service (memory corruption) or possibly have unspecified other impact via a crafted MP4 file, because access to the data structure has different expectations about layout as a result of this type confusion. Fixed by https://github.com/TechSmith/mp4v2/commit/73f38b4296aeb38617fa3923018bb78671c3b833 - CVE-2018-14403: MP4NameFirstMatches in mp4util.cpp in MP4v2 2.0.0 mishandles substrings of atom names, leading to use of an inappropriate data type for associated atoms. The resulting type confusion can cause out-of-bounds memory access. Fixed by https://github.com/TechSmith/mp4v2/commit/51cb6b36f6c8edf9f195d5858eac9ba18b334a16 Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com> commit e1af92592ec591270ef7f86a56562d119f2a46e1 Author: Fabrice Fontaine <fontaine.fabrice@gmail.com> Date: Sat May 2 21:54:38 2020 +0200 package/matio: add upstream security fixes Fix the following CVEs: - CVE-2019-17533: Mat_VarReadNextInfo4 in mat4.c in MATIO 1.5.17 omits a certain '\0' character, leading to a heap-based buffer over-read in strdup_vprintf when uninitialized memory is accessed. - CVE-2019-20017: A stack-based buffer over-read was discovered in Mat_VarReadNextInfo5 in mat5.c in matio 1.5.17. - CVE-2019-20018: A stack-based buffer over-read was discovered in ReadNextCell in mat5.c in matio 1.5.17. - CVE-2019-20020: A stack-based buffer over-read was discovered in ReadNextStructField in mat5.c in matio 1.5.17. - CVE-2019-20052: A memory leak was discovered in Mat_VarCalloc in mat.c in matio 1.5.17 because SafeMulDims does not consider the rank==0 case. Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com> commit 75e82c42c6a4612c7385a32dcb82ca9cb5d866bd Author: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Date: Tue May 26 23:27:54 2020 +0200 package/gnupg: fix build with gcc 10 This commit backports an upstream patch made for gnupg2 into gnupg, in order to fix build failures with gcc 10 due to the use of -fno-common. Due to the code differences between upstream gnupg2 and the old gnupg 1.x, the backport is in fact more a rewrite than an actual backport. Fixes: http://autobuild.buildroot.net/results/496a18833505dc589f7ae58f2c7e5fe80fe9af79/ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> commit a96277a93d36a1828de87b011022ae389a549cbd Author: Romain Naour <romain.naour@gmail.com> Date: Tue May 26 23:04:43 2020 +0200 package/qt5/qt5declarative: fix parallel install Installing qt5declarative examples on fast/fast/multicore machines sometimes failes with a variation of the following error messages: - Cannot touch [...]/chapter5-listproperties/app.qml: No such file or directory - Error copying [...]/chapter2-methods/app.qml: Destination file exists Fix it by using OTHER_FILES instead of a seperate qml files install target to fix the race between install_target, install_qml and install_sources. Fixes: - https://gitlab.com/buildroot.org/buildroot/-/jobs/565470221 Signed-off-by: Romain Naour <romain.naour@gmail.com> [Reworked patch and commit log] Signed-off-by: Peter Seiderer <ps.report@gmx.net> Reviewed-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> commit fa96dfa6288652fedf650b1f6e39b4b1de0ef51b Author: Heiko Thiery <heiko.thiery@gmail.com> Date: Mon May 18 08:43:21 2020 +0200 package/efl: fix -fno-common build failure Added upstream patch for fixing build failure when using GCC10 as a host compiler (-fno-common is now default). Fixes: http://autobuild.buildroot.net/results/47f/47fcf9bceba029accdcf159236addea3cb03f12f/ Cc: Romain Naour <romain.naour@gmail.com> Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> commit 73f4ad304f8a654dd3359e73f33ed463389218fa Author: Heiko Thiery <heiko.thiery@gmail.com> Date: Sun May 17 23:34:26 2020 +0200 package/erlang: fix -fno-common build failure Added upstream patch for fixing build failure when using GCC10 as a host compiler (-fno-common is now default). Cc: Romain Naour <romain.naour@gmail.com> Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> commit bec3cab8344072eed2b2ed1050f724e0325eb945 Author: Yegor Yefremov <yegorslists@googlemail.com> Date: Wed May 27 11:49:11 2020 +0200 linux: fix COPYING file hash In version 5.6 a minor change was made to this file, stating tht "[a]ll contributions to the Linux Kernel are subject to this COPYING file", and hence the hash changed. We can update the hash, because the licensing information is only accounted for the "latest" version, so the hash change will not impact older kernel versions as the user would have to switch to a non-latest kernel. Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> commit f9666a9892c01510a0fa59dd4449e41253805809 Author: Fabrice Fontaine <fontaine.fabrice@gmail.com> Date: Sat May 23 21:21:55 2020 +0200 package/gerbera: fix static linking with libmagic This patch was wrongly removed when bumping the version to 1.4.0 in commit 6976f312fa84d4a9c4bbf99ed3b173085780dcd9 Fixes: - http://autobuild.buildroot.org/results/7a53a59dd08c043f371bea967c3b450a7bddcde8 Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> commit 7d804aba66fbed7df6cf0caa845b6c52f7ff1f7e Author: Fabio Estevam <festevam@gmail.com> Date: Tue May 26 18:01:19 2020 -0300 board/freescale: increase the vfat size The default iamge size is 32MiB, which is quite low by today's standards. Besides, the AArch64 kernels are relatively big, which leaves not much room, if at all, for users to experiment on the default image. Increase the vfat size to a more reasonable 64MiB. Note that users who derive an in-tree defconfig for their own case will allways hit any arbitarary size we put here, so they will anyway have to also derive this template for their own use-cases. Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> commit 10454598a0c14054e4d52fafacdff5864db76cef Author: Romain Naour <romain.naour@gmail.com> Date: Mon May 11 23:47:43 2020 +0200 package/uboot-tools: tools/env/fw_env.h: remove env.h As reported by Nicolas Carrier on the Buildroot mailing list [1], there is a new build issue while building a program which interacts with the u-boot environment. This program uses the headers of the ubootenv library provided by uboot-tools. This is an upstream change from uboot [2] adding "#include <env.h>" to fw_env.h. Adding env.h require a board configuration to build. But only fw_env.h header is installed in the staging directory by uboot-tools package, but since it now include env.h the build is broken because env.h is missing from the staging directory. It's seems an upstream bug since env_set() is not used in fw_env tool. Nicolas removed env.h from fw_env tool and fixed it's build issue. This problem is present since uboot v2019.10, so the uboot version present in Buildroot 2020.02 is affected. It's probably not a problem for upstream uboot but it's a problem for uboot-tools package that build uboot tools without a board configuration for the target. [1] http://lists.busybox.net/pipermail/buildroot/2020-April/280307.html [2] https://gitlab.denx.de/u-boot/u-boot/-/commit/9fb625ce05539fe6876a59ce1dcadb76b33c6f6e Reported-by: Nicolas Carrier <nicolas.carrier@orolia.com> Signed-off-by: Romain Naour <romain.naour@gmail.com> [yann.morin.1998@free.fr: add URL to upstream commit] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> commit e7323e9d54ee9fc8a0c4af5f4198ac6024cc6b53 Author: Heiko Thiery <heiko.thiery@gmail.com> Date: Mon May 18 07:43:32 2020 +0200 package/audit: fix -fno-common build failure Added upstream patch for fixing build failure when using GCC10 as a host compiler (-fno-common is now default). Fixes: http://autobuild.buildroot.net/results/c4b/c4bba80e9fc476247c7ba28850831c6a8edd559f/build-end.log Cc: Romain Naour <romain.naour@gmail.com> Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> commit a26d6338fb47765de6e20fdead044ed6e69cc7ae Author: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Date: Mon May 18 07:22:02 2020 +0200 package/leveldb: fix detection of the snappy library Pull a patch pending in an upstream pull request to fix the detection of the snappy library when we are in static linking configurations. Fixes: https://bugs.busybox.net/show_bug.cgi?id=12671 Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> commit 39ef24f8bbe44d7850179f10fe0ab7e08e06059d Author: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Date: Mon May 18 07:22:01 2020 +0200 package/leveldb: turn snappy into an optional dependency snappy is not a mandatory dependency to build leveldb. Back when it was introduced in Buildroot, as of version 1.18, the build logic already made snappy an optional dependency. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> commit 00c1a8c34f7340c2db6eee82cd8d3f5e6ea62577 Author: James Hilliard <james.hilliard1@gmail.com> Date: Tue May 26 14:24:37 2020 -0600 package/mesa3d: propagate missing libdrm-freedreno deps Libdrm freedreno depends on BR2_arm || BR2_aarch64 || BR2_aarch64_be as such we need to propagate those dependencies to mesa's gallium freedreno driver. Signed-off-by: James Hilliard <james.hilliard1@gmail.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> commit fa84c176c2148a60103e850204180f86aa5baa73 Author: James Hilliard <james.hilliard1@gmail.com> Date: Sun May 24 20:50:53 2020 -0600 package/prosody: use correct bit32 package According to https://prosody.im/doc/depends#bitop the correct bitop package to use with prosody for Lua 5.1 is: https://luarocks.org/modules/siffiejoe/bit32 As such replace BR2_PACKAGE_LUABITOP with BR2_PACKAGE_LUA_BIT32 Signed-off-by: James Hilliard <james.hilliard1@gmail.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> commit 1e6e67a82569093a9f2c59a3a94e874bba93fea6 Author: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Date: Tue May 26 21:53:15 2020 +0200 docs/website/sponsors.html: show 2020 sponsors So far in 2020, Logilin and Tap2Open made some financial donations to the Buildroot Association, so let's thank them on our sponsors page. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> commit b6aaed0cee95e61fc7714215199b6e344ba8c409 Author: Fabrice Fontaine <fontaine.fabrice@gmail.com> Date: Tue May 26 07:34:12 2020 +0200 package/lrzip: fix hash Hash was not updated by commit 18079e20a712c4a7d539ead52b0a0c725ec7f7e2 Fixes: - http://autobuild.buildroot.org/results/0f7179ed4706f05551af330d7f12b3efaeffd278 Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com> commit 8a12ddaa295ee4919bf294900b96362ee8cb4f78 Author: Peter Korsgaard <peter@korsgaard.com> Date: Mon May 25 18:26:31 2020 +0200 {linux, linux-headers}: bump 4.{4, 9, 14, 19}.x / 5.{4, 6}.x series Signed-off-by: Peter Korsgaard <peter@korsgaard.com> commit 9ff7b6170561dde1ea01f94cf765abe73140029b Author: Heiko Thiery <heiko.thiery@gmail.com> Date: Sun May 24 23:28:29 2020 +0200 package/pkg-generic.mk: enable hash checks for svn tarbals With commit 89f5e989323ace815a32fced27eaefee2f4666de support for reproducible archives was added. Thus archives generated from svn do no longer needs to be added to BR_NO_CHECK_HASH_FOR. Cc: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> commit 18079e20a712c4a7d539ead52b0a0c725ec7f7e2 Author: Fabrice Fontaine <fontaine.fabrice@gmail.com> Date: Sat May 23 10:36:23 2020 +0200 package/lrzip: bump to 7f3bf46203bf45ea115d8bd9f310ea219be88af4 This bump contains only one commit that fix a build failure with asm: https://github.com/ckolivas/lrzip/commit/844b8c057c8c7372ca41ad2efdbf849f45c24506 Fixes: - http://autobuild.buildroot.org/results/800d8a97966ef75dbf20e85ec8a02766ba02cc76 Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com> commit 58af9a70cc0f195116dedb3fd0e2ca5b4fec9e70 Author: Romain Naour <romain.naour@gmail.com> Date: Sat May 23 01:22:12 2020 +0200 package/qemu: remove csky fork We have a qemu fork for csky cpus [1] but since qemu version bump to 4.2.0 [2] and libssh2/libssh change the csky build is broken. The csky fork is based on Qemu 3.0.0 but unlike autotools packages any unknown option is handled as error. Since we don't want to support all options from previous qemu release and the github repository has been removed [3] and the only remaining archive is located on http://sources.buildroot.net, remove the qemu csky fork as suggested by [4]. [1] https://git.buildroot.net/buildroot/commit/?id=f816e5b276f1ef15840bec6667f1e8219717ab7d [2] https://git.buildroot.net/buildroot/commit/?id=0ea17054ce7dfc54efca5634133cef786445e7b1 [3] https://github.com/c-sky/qemu [4] http://lists.busybox.net/pipermail/buildroot/2020-May/281885.html Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: Guo Ren <ren_guo@c-sky.com> Cc: Peter Korsgaard <peter@korsgaard.com> [Peter: move patches out of 4.2.0 subdir] Signed-off-by: Peter Korsgaard <peter@korsgaard.com> commit 90dd7803914ec2d817e39b20bc88f09b0f04f54f Author: Yann E. MORIN <yann.morin.1998@free.fr> Date: Sun May 24 22:26:51 2020 +0200 package/wiringpi: remove The author has completely ripped off the git tree, so the sources are no longer available, with that message: "Please look for alternatives for wiringPi" And indeed there is a better alternative, using the kernel GPIO subsystem and drivers. Note that queezelite looses that functionality now, but upstream squeezelite has done changes to do without wiringpi (hint for an upgrade?). Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Peter Seiderer <ps.report@gmx.net> Cc: Hiroshi Kawashima <kei-k@ca2.so-net.ne.jp> Signed-off-by: Peter Korsgaard <peter@korsgaard.com> commit 97551eb176cd75419e3520ea94f184e3220980cd Author: Yann E. MORIN <yann.morin.1998@free.fr> Date: Sun May 24 10:58:00 2020 +0200 package/speexdsp+tremor: switch to new git repository The original git server on git.xiph.org died, and the Xiph project has now moved on to host their repositories on gitlab.comn instead. Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com> commit fb57a54cf8d56fb9a32a3d632346c58eb58177b4 Author: Yann E. MORIN <yann.morin.1998@free.fr> Date: Sun May 24 10:57:21 2020 +0200 package: don't use BR2_KERNEL_MIRROR for git downloads The git repositories are not served on the kernel.org CDN: fatal: repository 'https://cdn.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git/' not found Switch to explicitly use the git.kernel.org server. Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Matt Weber <matthew.weber@rockwellcollins.com> Cc: Cyril Bur <cyrilbur@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com> commit c5e932613eaed02d983af1889d2280f493b1a20e Author: Bernd Kuhls <bernd.kuhls@t-online.de> Date: Fri May 22 22:37:36 2020 +0200 package/ffmpeg: bump version to 4.2.3 Removed patch included in upstream release, reformatted hashes. Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de> Signed-off-by: Peter Korsgaard <peter@korsgaard.com> commit 39bfd504102dce2166e9d9e1377744debde64b38 Author: Fabrice Fontaine <fontaine.fabrice@gmail.com> Date: Fri May 22 22:10:41 2020 +0200 package/wireshark: security bump to version 3.2.4 Fix CVE-2020-13164: In Wireshark 3.2.0 to 3.2.3, 3.0.0 to 3.0.10, and 2.6.0 to 2.6.16, the NFS dissector could crash. This was addressed in epan/dissectors/packet-nfs.c by preventing excessive recursion, such as for a cycle in the directory graph on a filesystem. Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com> commit 2e0beffb74efd6a0a1bd4fd1e631b5a757d7c61b Author: Fabrice Fontaine <fontaine.fabrice@gmail.com> Date: Sat May 23 19:20:36 2020 +0200 package/fio: fix build on sh4 Fixes: - http://autobuild.buildroot.org/results/6dc82572ae1369aa5c9954b6e61777766c5aa3b4 Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com> commit de2b78143c4316c6a6a07d44d74298d307609dd2 Author: Joachim Nilsson <troglobit@gmail.com> Date: Sat May 23 16:05:03 2020 +0200 docs/manual: new chapter on release engineering Describe release engineering and development phases of the project. Signed-off-by: Joachim Nilsson <troglobit@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com> commit 982728364141c4369003b1dbdc24e51428be6b39 Author: Yann E. MORIN <yann.morin.1998@free.fr> Date: Sun May 24 22:39:25 2020 +0200 package/ltrace: directly use s.b.o to fetch the archive During the migration from alioth to gitlab, the git repository for ltrace was not migrated. There is a repository on gitlab.com, owned by the debian maintainer, but that repository does not contain the sha1 we know of: https://gitlab.com/cespedes/ltrace s.b.o. is the only known location so far to host the archive, so switch to it. Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com> commit 89a5d2162762490727c515692baa1257ba73179e Author: Peter Korsgaard <peter@korsgaard.com> Date: Mon May 25 08:15:28 2020 +0200 package/bind: security bump to version 9.11.19 Fixes the following security issues: - (9.11.18) DNS rebinding protection was ineffective when BIND 9 is configured as a forwarding DNS server. Found and responsibly reported by Tobias Klein. [GL #1574] - (9.11.19) To prevent exhaustion of server resources by a maliciously configured domain, the number of recursive queries that can be triggered by a request before aborting recursion has been further limited. Root and top-level domain servers are no longer exempt from the max-recursion-queries limit. Fetches for missing name server address records are limited to 4 for any domain. This issue was disclosed in CVE-2020-8616. [GL #1388] - (9.11.19) Replaying a TSIG BADTIME response as a request could trigger an assertion failure. This was disclosed in CVE-2020-8617. [GL #1703] Also update the COPYRIGHT hash for a change of copyright year and adjust the spacing for the new agreements. Signed-off-by: Peter Korsgaard <peter@korsgaard.com> commit 26c32d933eb4d841b7fbe9c1e0b61cef89665b15 Author: Jérémy Rosen <jeremy.rosen@smile.fr> Date: Fri May 22 18:59:29 2020 +0200 packages/systemd: fix double getty on console When selecting "console" for the automatic getty, the buildroot logic would collide with systemd's internal console detection logic, resulting in two getty being started on the console. This commit fixes that by doing nothing when "console" is selected and letting systemd-getty-generator deal with starting the proper getty. Note that if something other than the console is selected * Things will work properly, even if the selected terminal is also the console * A getty will still be started on the console. This is what systemd has been doing on buildroot since the beginning. it could be disabled but I left it for backward compatibility Fixes: #12361 Signed-off-by: Jérémy Rosen <jeremy.rosen@smile.fr> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> commit 03fbb81b8bab7bad135b59267533be7688babe39 Author: Fabrice Fontaine <fontaine.fabrice@gmail.com> Date: Fri May 22 15:58:08 2020 +0200 package/dovecot: security bump to version 2.3.10.1 - Fix CVE-2020-10957: In Dovecot before 2.3.10.1, unauthenticated sending of malformed parameters to a NOOP command causes a NULL Pointer Dereference and crash in submission-login, submission, or lmtp. - Fix CVE-2020-10958: In Dovecot before 2.3.10.1, a crafted SMTP/LMTP message triggers an unauthenticated use-after-free bug in submission-login, submission, or lmtp, and can lead to a crash under circumstances involving many newlines after a command. - Fix CVE-2020-10967: In Dovecot before 2.3.10.1, remote unauthenticated attackers can crash the lmtp or submission process by sending mail with an empty localpart. - Drop first patch (already in version) and so autoreconf - Update indentation in hash file (two spaces) Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com> commit 6d7df70016d51c4813c77095705cf8a0e3e1c09e Author: Fabrice Fontaine <fontaine.fabrice@gmail.com> Date: Fri May 22 15:58:07 2020 +0200 package/dovecot: drop first patch First patch is not needed since version 2.3.0 and https://github.com/dovecot/core/commit/08259c1f206026ca9b9f4b4e97603943c6093def Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com> commit 796cc10fa0b7986cfe818df8743fe0ca1f87db98 Author: Stefan Ott <stefan@ott.net> Date: Fri May 22 03:40:26 2020 +0200 package/unbound: bump version to 1.10.1 for security fixes Fixes the following security vulnerabilities: CVE-2020-12662: Unbound can be tricked into amplifying an incoming query into a large number of queries directed to a target. CVE-2020-12663: Malformed answers from upstream name servers can be used to make Unbound unresponsive. Signed-off-by: Stefan Ott <stefan@ott.net> Signed-off-by: Peter Korsgaard <peter@korsgaard.com> commit 497e3dff7e13d0651b1e9db7b232b13da37f0108 Author: Peter Korsgaard <peter@korsgaard.com> Date: Fri May 22 11:53:24 2020 +0200 Update for 2020.05-rc2 Signed-off-by: Peter Korsgaard <peter@korsgaard.com> commit cb6eb5db792016751ab01b5dda04536ec65169c3 Author: Fabrice Fontaine <fontaine.fabrice@gmail.com> Date: Thu May 21 16:39:57 2020 +0200 package/freerdp: security bump to version 2.1.1 >From ChangeLog: - CVE: GHSL-2020-100 OOB Read in ntlm_read_ChallengeMessage - CVE: GHSL-2020-101 OOB Read in security_fips_decrypt due to uninitialized value - CVE: GHSL-2020-102 OOB Write in crypto_rsa_common - Enforce synchronous legacy RDP encryption count (#6156) - Fixed some leaks and crashes missed in 2.1.0 - Removed dynamic channel listener limits - Lots of resource cleanup fixes (clang sanitizers) https://github.com/FreeRDP/FreeRDP/blob/2.1.1/ChangeLog Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com> commit a00db9f80819982348e64834f76048c2c8381f40 Author: Fabrice Fontaine <fontaine.fabrice@gmail.com> Date: Thu May 21 16:43:40 2020 +0200 DEVELOPERS: remove python-pycrypto Commit 7ef76ed32fcd447391e26d33a555ff5dab6dc48e forgot to remove python-pycrypto entry from DEVELOPERS Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> commit bcc02f5fe53be4021509c9361e69141491d458f3 Author: Fabrice Fontaine <fontaine.fabrice@gmail.com> Date: Mon May 18 18:15:25 2020 +0200 package/libpam-tacplus: fix build when time_t is 64 bits Fixes: - http://autobuild.buildroot.org/results/874433d8cb30d21332f23024081a8b6d7b3254ae Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> commit 19f726b9888f1bc4bb6284f2bcc417f5598c7723 Author: Heiko Thiery <heiko.thiery@gmail.com> Date: Tue May 19 08:53:21 2020 +0200 package/vboot-utils: fix -fno-common build failure Added upstream patch for fixing build failure when using GCC10 as a host compiler (-fno-common is now default). Fixes: http://autobuild.buildroot.net/results/aca662d9fd7052f3b361b731cd266edb3b6c41b0 http://autobuild.buildroot.net/results/6546b284cf306a2fde3c69d67daf9aacffa9e143 http://autobuild.buildroot.net/results/db20bb3c11a1a9558a5d8021015c6915f99097c8 Cc: Romain Naour <romain.naour@gmail.com> Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> commit 7ef76ed32fcd447391e26d33a555ff5dab6dc48e Author: Romain Naour <romain.naour@gmail.com> Date: Mon Apr 27 00:33:23 2020 +0200 package/python-pycrypto: remove package This package doesn't work with Python 3.8 since the code contains time.clock() that was deprecated in Python 3.3 and removed in Python 3.8. Instead of applying non upstream patches from Fedora [1], python-pycrypto was replaced by python-pycryptodomex for crda and optee-os package. Now we can remove safely this package. [1] http://lists.busybox.net/pipermail/buildroot/2020-April/280683.html Fixes: https://gitlab.com/buildroot.org/buildroot/-/jobs/498144209 Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: James Hilliard <james.hilliard1@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> commit 82b74001752beaee4f87b1c58b8accea6bd53a9d Author: Romain Naour <romain.naour@gmail.com> Date: Mon Apr 27 00:33:22 2020 +0200 boot/optee-os: replace pycrypto by pycryptodomex >From [1] included in optee-os release 3.7.0: "PyCryptodome is a fork of PyCrypto, which is not maintained any more (the last release dates back to 2013 [2]). It exposes almost the same API, but there are a few incompatibilities [3]." pem_to_pub_c.py/sign.py scripts still use pycrypto that is replaced by pycryptodomex. Add a patch to use pycryptodomex but don't use upstream commit since it also switches from the algorithm TEE_ALG_RSASSA_PKCS1_V1_5_SHA256 to TEE_ALG_RSASSA_PKCS1_PSS_MGF1_SHA256 when replacing pycrypto to pycryptodomex [4]. [1] https://github.com/OP-TEE/optee_os/commit/90ad2450436fdd9fc0d28a3f92f3fbcfd89a38f0 [2] https://pypi.org/project/pycrypto/#history [3] https://pycryptodome.readthedocs.io/en/latest/src/vs_pycrypto.html [4] https://github.com/OP-TEE/optee_os/commit/ababd72d2fd76cb2ded8e202b49db28d6545f6eb Fixes: https://gitlab.com/buildroot.org/buildroot/-/jobs/526035730 Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: James Hilliard <james.hilliard1@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> commit 8d05237b6018d5389e4381b38d874f447137f987 Author: Romain Naour <romain.naour@gmail.com> Date: Mon Apr 27 00:33:21 2020 +0200 package/crda: replace pycrypto by pycryptodomex >From [1]: "PyCryptodome is a fork of PyCrypto, which is not maintained any more (the last release dates back to 2013 [2]). It exposes almost the same API, but there are a few incompatibilities [3]." [1] https://github.com/OP-TEE/optee_os/commit/90ad2450436fdd9fc0d28a3f92f3fbcfd89a38f0 [2] https://pypi.org/project/pycrypto/#history [3] https://pycryptodome.readthedocs.io/en/latest/src/vs_pycrypto.html Update the patch 0001-crda-support-python-3-in-utils-key2pub.py.patch since it add pycrypto. >From [4] "CRDA is no longer needed as of kernel v4.15 since commit 007f6c5e6eb45 ("cfg80211: support loading regulatory database as firmware file") added support to use the kernel's firmware request API which looks for the firmware on /lib/firmware. Because of this CRDA is legacy software for older kernels. It will continue to be maintained." [4] https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/crda.git/tree/README?id=9856751feaf7b102547cea678a5da6c94252d83d#n8 Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: James Hilliard <james.hilliard1@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> commit 3db1e5fbcbde9f78f9cac99614fefc243545094e Author: Romain Naour <romain.naour@gmail.com> Date: Mon Apr 27 00:33:20 2020 +0200 package/python-pycryptodomex: add host variant Adding a host variant will allow to replace host-python-pycrypto by host-python-pycryptodomex for the crda and optee-os packages. From [1]: "PyCryptodome is a fork of PyCrypto, which is not maintained any more (the last release dates back to 2013 [2]). It exposes almost the same API, but there are a few incompatibilities [3]." [1] https://github.com/OP-TEE/optee_os/commit/90ad2450436fdd9fc0d28a3f92f3fbcfd89a38f0 [2] https://pypi.org/project/pycrypto/#history [3] https://pycryptodome.readthedocs.io/en/latest/src/vs_pycrypto.html Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: James Hilliard <james.hilliard1@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> commit 6cff75415781deda1414fe22827400a7c334de6c Author: Stephan Hoffmann <sho@relinux.de> Date: Mon May 18 11:36:02 2020 +0200 DEVELOPERS: add Stephan Hoffmann for libhttpserver I added this package while working for Grandcentrix but am willing to maintain it further. Signed-off-by: Stephan Hoffmann <sho@relinux.de> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> commit 64a2bfcf8f07d9d40e730ff9f483eb23a95233c1 Author: Stephan Hoffmann <sho@relinux.de> Date: Mon May 18 11:47:55 2020 +0200 package/mtdev2tuio: remove package mtdev2tuio breaks the builds every now and then and is not maintained upstream. It does not seem to be useful any more. Signed-off-by: Stephan Hoffmann <sho@relinux.de> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> commit 285986ae5970d13090a27aba6b88743efd696158 Author: Ryan Coe <bluemrp9@gmail.com> Date: Mon May 18 07:00:49 2020 -0700 package/mariadb: security bump to 10.3.23 Add two spaces in hash file. Remove patch 0002 as it has been applied upstream. Release notes: https://mariadb.com/kb/en/library/mariadb-10323-release-notes/ Changelog: https://mariadb.com/kb/en/library/mariadb-10323-changelog/ Fixes the following security vulnerabilities: CVE-2020-2752 - Vulnerability in the MySQL Client product of Oracle MySQL (component: C API). Supported versions that are affected are 5.6.47 and prior, 5.7.27 and prior and 8.0.17 and prior. Difficult to exploit vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Client. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Client. CVE-2020-2812 - Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Stored Procedure). Supported versions that are affected are 5.6.47 and prior, 5.7.29 and prior and 8.0.19 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVE-2020-2814 - Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB). Supported versions that are affected are 5.6.47 and prior, 5.7.28 and prior and 8.0.18 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVE-2020-2760 - Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB). Supported versions that are affected are 5.7.29 and prior and 8.0.19 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as unauthorized update, insert or delete access to some of MySQL Server accessible data. Signed-off-by: Ryan Coe <bluemrp9@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> commit ca0547ffeaea77b1b59ddcf77a2f3713167f8a7e Author: Fabrice Fontaine <fontaine.fabrice@gmail.com> Date: Tue May 19 20:02:16 2020 +0200 package/libexif: security bump to version 0.6.22 - Switch site to github - Drop patches (already in version) - Fix the following CVEs: - CVE-2020-13114: Time consumption DoS when parsing canon array markers - CVE-2020-13113: Potential use of uninitialized memory - CVE-2020-13112: Various buffer overread fixes due to integer overflows in maker notes - CVE-2020-0093: read overflow - CVE-2020-12767: fixed division by zero https://github.com/libexif/libexif/releases/tag/libexif-0_6_22-release Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> commit 78e78071128ccf2dba8cf76b00b1beb0c5f3e538 Author: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Date: Mon May 18 08:26:47 2020 +0200 package/bison: make installation relocatable Our current host-bison installation is not relocatable, so if you generate the SDK, and install it in a different location, bison will no longer work with failures such as: bison: /home/user/buildroot/output/host/share/bison/m4sugar/m4sugar.m4: cannot open: No such file or directory This particular issue is already resolved upstream by the addition of "relocatable" support, which we enable using --enable-relocatable. Once this issue is fixed, a second one pops up: the path to the m4 program itself is also hardcoded. So we add a patch to fix that as well. The patch has been submitted upstream, which have requested for further refinements not applicable to the Buildroot context; in the meantime, we carry that patch. Fixes: https://bugs.busybox.net/show_bug.cgi?id=12656 Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> [yann.morin.1998@free.fr: add reference to the upstream submission] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> commit 39ae8290aadf8c3b29388a9ebe0b32a7f6dd8e7e Author: Yann E. MORIN <yann.morin.1998@free.fr> Date: Tue May 19 21:08:11 2020 +0200 Revert "package/cracklib: add python3 support" This reverts commit f584595424137399dd06f73c6f04c759e04b879e. It in fact depends on a previous patch to python that was not applied [0], as upstream believes it is dangerous [1], and is still debating the proper solution [2]. [0] https://patchwork.ozlabs.org/project/buildroot/patch/20200202205306.1785085-1-fontaine.fabrice@gmail.com/ [1] https://bugs.python.org/issue39026#msg369309 [2] https://bugs.python.org/issue39026 Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> commit f584595424137399dd06f73c6f04c759e04b879e Author: Fabrice Fontaine <fontaine.fabrice@gmail.com> Date: Sun Feb 2 21:53:06 2020 +0100 package/cracklib: add python3 support python bindings supports python3 since version 2.8.19 and https://github.com/cracklib/cracklib/commit/219de98766b9f1e4c8c5b174de770158ffda3a93 Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> commit 42617caa720b96b66f00787b3d24b9bb18754e1e Author: Stefan Sørensen <stefan@astylos.dk> Date: Tue May 19 15:35:23 2020 +0200 package/p7zip: fix build with gcc 10 Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> commit 9e9c242fb73fe19248c48ac28c083851d14f6813 Author: Stefan Sørensen <stefan.sorensen@spectralink.com> Date: Tue May 19 15:27:21 2020 +0200 package/openldap: security bump to version 2.4.50 Security fixes: CVE-2020-12243: Fixed slapd to limit depth of nested filters Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com> [yann.morin.1998@free.fr: two spaces in hash file] Signed…
As reported by several Buildroot users [1][2][3], the gcc build may fail while running selftests makefile target. The problem only occurs when ccache is used with gcc 9 and 10, probably due to a race condition. While debuging with "make -p" we can notice that s-selftest-c target contain only "cc1" as dependency instead of cc1 and SELFTEST_DEPS [4]. s-selftest-c: cc1 While the build is failing, the s-selftest-c dependencies recipe is still running and reported as a bug by make. "Dependencies recipe running (THIS IS A BUG)." A change [5] in gcc 9 seems to introduce the problem since we can't reproduce this problem with gcc 8. As suggested by Yann E. MORIN [6], move SELFTEST_DEPS before including language makefile fragments. With the fix applied, the s-seltest-c dependency contains SELFTEST_DEPS value. s-selftest-c: cc1 xgcc specs stmp-int-hdrs ../../gcc/testsuite/selftests [1] http://lists.busybox.net/pipermail/buildroot/2020-May/282171.html [2] http://lists.busybox.net/pipermail/buildroot/2020-May/282766.html [3] cirosantilli/linux-kernel-module-cheat#108 [4] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/c/Make-lang.in;h=bfae6fd2549c4f728816cd355fa9739dcc08fcde;hb=033eb5671769a4c681a44aad08a454e667e08502#l120 [5] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=033eb5671769a4c681a44aad08a454e667e08502 [6] http://lists.busybox.net/pipermail/buildroot/2020-May/283213.html Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: Ben Dakin-Norris <ben.dakin-norris@navtechradar.com> Cc: Maxim Kochetkov <fido_max@inbox.ru> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
As reported by several Buildroot users [1][2][3], the gcc build may fail while running selftests makefile target. The problem only occurs when ccache is used with gcc 9 and 10, probably due to a race condition. While debuging with "make -p" we can notice that s-selftest-c target contain only "cc1" as dependency instead of cc1 and SELFTEST_DEPS [4]. s-selftest-c: cc1 While the build is failing, the s-selftest-c dependencies recipe is still running and reported as a bug by make. "Dependencies recipe running (THIS IS A BUG)." A change [5] in gcc 9 seems to introduce the problem since we can't reproduce this problem with gcc 8. As suggested by Yann E. MORIN [6], move SELFTEST_DEPS before including language makefile fragments. With the fix applied, the s-seltest-c dependency contains SELFTEST_DEPS value. s-selftest-c: cc1 xgcc specs stmp-int-hdrs ../../gcc/testsuite/selftests [1] http://lists.busybox.net/pipermail/buildroot/2020-May/282171.html [2] http://lists.busybox.net/pipermail/buildroot/2020-May/282766.html [3] cirosantilli/linux-kernel-module-cheat#108 [4] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/c/Make-lang.in;h=bfae6fd2549c4f728816cd355fa9739dcc08fcde;hb=033eb5671769a4c681a44aad08a454e667e08502#l120 [5] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=033eb5671769a4c681a44aad08a454e667e08502 [6] http://lists.busybox.net/pipermail/buildroot/2020-May/283213.html Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: Ben Dakin-Norris <ben.dakin-norris@navtechradar.com> Cc: Maxim Kochetkov <fido_max@inbox.ru> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> (cherry picked from commit 58ecbbc) Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
At https://github.com/cirosantilli/linux-kernel-module-cheat/tree/buildroot-2019.11-1 which has buildroot 2019.11 and GCC 9.2:
Problem does not happen on clean Buildroot 2019.11 with
make qemu_x86_64_defconfig
thenmenuconfig
to use GCC 9.2.Problem also does not happen with above + modify binutils to 2.32... give up?
The text was updated successfully, but these errors were encountered: