Files
operating-system/buildroot/package/python3/0033-configure.ac-fixup-CC-print-multiarch-output-for-mus.patch
Stefan Agner a0871be6c0 Bump buildroot to 2020.11-rc1 (#985)
* Update buildroot-patches for 2020.11-rc1 buildroot

* Update buildroot to 2020.11-rc1

Signed-off-by: Stefan Agner <stefan@agner.ch>

* Don't rely on sfdisk --list-free output

The --list-free (-F) argument does not allow machine readable mode. And
it seems that the output format changes over time (different spacing,
using size postfixes instead of raw blocks).

Use sfdisk json output and calculate free partition space ourselfs. This
works for 2.35 and 2.36 and is more robust since we rely on output which
is meant for scripts to parse.

* Migrate defconfigs for Buildroot 2020.11-rc1

In particular, rename BR2_TARGET_UBOOT_BOOT_SCRIPT(_SOURCE) to
BR2_PACKAGE_HOST_UBOOT_TOOLS_BOOT_SCRIPT(_SOURCE).

* Rebase/remove systemd patches for systemd 246

* Drop apparmor/libapparmor from buildroot-external

* hassos-persists: use /run as directory for lockfiles

The U-Boot tools use /var/lock by default which is not created any more
by systemd by default (it is under tmpfiles legacy.conf, which we no
longer install).

* Disable systemd-update-done.service

The service is not suited for pure read-only systems. In particular the
service needs to be able to write a file in /etc and /var. Remove the
service. Note: This is a static service and cannot be removed using
systemd-preset.

* Disable apparmor.service for now

The service loads all default profiles. Some might actually cause
problems. E.g. the profile for ping seems not to match our setup for
/etc/resolv.conf:
[85503.634653] audit: type=1400 audit(1605286002.684:236): apparmor="DENIED" operation="open" profile="ping" name="/run/resolv.conf" pid=27585 comm="ping" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
2020-11-13 18:25:44 +01:00

49 lines
1.8 KiB
Diff

From edc0757c56090364e0a95aabfa9f645a16a27569 Mon Sep 17 00:00:00 2001
From: Peter Korsgaard <peter@korsgaard.com>
Date: Fri, 2 Aug 2019 15:53:16 +0200
Subject: [PATCH] configure.ac: fixup $CC --print-multiarch output for
musl/uclibc GCC 8+ toolchains
GCC commit 6834b83784dcf0364eb820e8 (multiarch support for non-glibc linux
systems), which is part of GCC 8+, changed the multiarch logic to use
$arch-linux-musl / $arch-linux-uclibc rather than $arch-linux-gnu.
This then causes the python3 configure script to error out:
checking for the platform triplet based on compiler characteristics... powerpc-linux-gnu
configure: error: internal configure error for the platform triplet, please file a bug report
http://autobuild.buildroot.net/results/cb4/cb49c539501342e45cbe5ade82e588fcdf51f05b
As it requires that the --print-multiarch output (if not empty) matches the
deduced triplet (which always uses -linux-gnu).
It isn't quite clear why --print-multiarch returns something for a
non-multiarch toolchain on some architectures (E.G. PowerPC), but as a
workaround, rewrite the --print-multiarch output to match older GCC versions
to keep the configure script happy.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
---
configure.ac | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 615c16aced..241298e6cf 100644
--- a/configure.ac
+++ b/configure.ac
@@ -718,7 +718,9 @@ then
fi
-MULTIARCH=$($CC --print-multiarch 2>/dev/null)
+# GCC 8+ returns $arch-linux-{musl,uclibc} for musl/uClibc based
+# toolchains confusing python. Fix that up
+MULTIARCH=$($CC --print-multiarch 2>/dev/null | sed -E 's/-linux-(musl|uclibc)*$/-linux-gnu/')
AC_SUBST(MULTIARCH)
AC_MSG_CHECKING([for the platform triplet based on compiler characteristics])
--
2.25.1