[OE-core] [PATCH] bitbake.conf: Add HOSTTOOLS_NONFATAL bits needed for OpenMandriva hosts
From: Bernhard Rosenkränzer
Some Linux distributions (e.g. OpenMandriva, ROSA) try to support
gcc style LTO objects and clang style LTO objects at the same time
by replacing ar and friends with a wrapper script that calls the
binutils or llvm version of the tool depending on input.
For those, the binutils and llvm versions need to be available in
HOSTTOOLS as well (or the wrapper script will fail).
Signed-off-by: Bernhard Rosenkränzer
---
meta/conf/bitbake.conf | 8
1 file changed, 8 insertions(+)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 62cdd9aa9c..e03bfd1b6b 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -534,6 +534,14 @@ HOSTTOOLS += "${@'ip ping ps scp ssh stty' if
(bb.utils.contains_any('IMAGE_CLAS
# Link to these if present
HOSTTOOLS_NONFATAL += "aws gcc-ar gpg gpg-agent ld.bfd ld.gold nc pigz sftp
socat ssh sudo"
+# Some Linux distributions (e.g. OpenMandriva, ROSA) try to support
+# gcc style LTO objects and clang style LTO objects at the same time
+# by replacing ar and friends with a wrapper script that calls the
+# binutils or llvm version of the tool depending on input. For those,
+# the binutils and llvm versions need to be available in HOSTTOOLS
+# as well (or the wrapper script will fail)
+HOSTTOOLS_NONFATAL += "binutils-ar binutils-ranlib binutils-nm gcc-ranlib
gcc-nm"
+
# Temporary add few more detected in bitbake world
HOSTTOOLS_NONFATAL += "join nl size yes zcat"
--
2.38.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172230):
https://lists.openembedded.org/g/openembedded-core/message/172230
Mute This Topic: https://lists.openembedded.org/mt/94616121/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] base.bbclass: Try harder to find a compatible tar implementation
From: Bernhard Rosenkränzer base.bbclass currently symlinks the first copy of tar on the PATH to hosttools. If that copy of tar isn't GNU tar (some Linux distributions use libarchive tar for the fact that it can handle zip files etc. as well; some others probably use busybox or toybox tar for space issues), the build fails early on because path.py uses --xattrs and --xattrs-include With this patch, base.bbclass checks if tar supports --xattrs-include, and checks for gtar if the first tar found doesn't support it. Signed-off-by: Bernhard Rosenkränzer --- meta/classes-global/base.bbclass | 10 ++ 1 file changed, 10 insertions(+) diff --git a/meta/classes-global/base.bbclass b/meta/classes-global/base.bbclass index 8203f54519..b6391501ca 100644 --- a/meta/classes-global/base.bbclass +++ b/meta/classes-global/base.bbclass @@ -135,6 +135,16 @@ def setup_hosttools_dir(dest, toolsvar, d, fatal=True): if os.path.islink(desttool): os.unlink(desttool) srctool = bb.utils.which(path, tool, executable=True) +# copytree() uses tar options such as --xattrs and +# --xattrs-include that are currently specific to GNU tar. +# If the first tar in PATH is libarchive tar or busybox/toybox +# tar, GNU tar may well be available as gtar. +if (tool == "tar"): +import subprocess +if not b'--xattrs-include' in subprocess.check_output([srctool, '--help']): +gtar = bb.utils.which(path, "gtar", executable=True) +if gtar: +srctool = gtar # gcc/g++ may link to ccache on some hosts, e.g., # /usr/local/bin/ccache/gcc -> /usr/bin/ccache, then which(gcc) # would return /usr/local/bin/ccache/gcc, but what we need is -- 2.38.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#172229): https://lists.openembedded.org/g/openembedded-core/message/172229 Mute This Topic: https://lists.openembedded.org/mt/94616037/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH v2 1/1] cmake-native: Fix host tool contamination (Bug: 14951)
From: Bernhard Rosenkränzer
[v2 should fix the From: header, no functional changes]
Trying to build cmake-native on a host system where curl was built with cmake
(resulting in CURLConfig.cmake and friends, which do not use the same naming
schemes expected by cmake-native's build process, being installed to a system
wide cmake directory like /usr/lib64/cmake/CURL) results in undefined
references to all libcurl symbols.
The problem is that cmake-native sees and uses the system wide
/usr/lib64/cmake/CURL/CURLConfig.cmake, which defines CURL::libcurl and
CURL::curl as opposed to setting ${CURL_LIBRARIES} as expected by
cmake-native.
find_package(CURL) (cmake-native's CMakeLists.txt, line 478) succeeds, but
incorrectly uses the system wide CURLConfig.cmake, resulting
CMAKE_CURL_LIBRARIES to be set to an empty string (cmake-native's
CMakeLists.txt, line 484), causing the cmake-native build to miss -lcurl.
The simplest fix is to let cmake know the right value for
CURL_LIBRARIES. Making it -lcurl should always work with libcurl-native
in recipe-sysroot-native.
Signed-off-by: Bernhard Rosenkränzer
---
meta/recipes-devtools/cmake/cmake-native_3.22.3.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-devtools/cmake/cmake-native_3.22.3.bb
b/meta/recipes-devtools/cmake/cmake-native_3.22.3.bb
index ee1f7761c4..45ea78ae00 100644
--- a/meta/recipes-devtools/cmake/cmake-native_3.22.3.bb
+++ b/meta/recipes-devtools/cmake/cmake-native_3.22.3.bb
@@ -32,6 +32,7 @@ CMAKE_EXTRACONF = "\
-DCMAKE_USE_SYSTEM_LIBRARY_EXPAT=0 \
-DENABLE_ACL=0 -DHAVE_ACL_LIBACL_H=0 \
-DHAVE_SYS_ACL_H=0 \
+-DCURL_LIBRARIES=-lcurl \
"
do_configure () {
--
2.38.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172204):
https://lists.openembedded.org/g/openembedded-core/message/172204
Mute This Topic: https://lists.openembedded.org/mt/94612388/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH v2 1/1] cmake-native: Fix host tool contamination (Bug: 14951)
From: Bernhard Rosenkränzer
[v2 hopefully fixes the From: mangling by the ML, no functional changes]
Trying to build cmake-native on a host system where curl was built with cmake
(resulting in CURLConfig.cmake and friends, which do not use the same naming
schemes expected by cmake-native's build process, being installed to a system
wide cmake directory like /usr/lib64/cmake/CURL) results in undefined
references to all libcurl symbols.
The problem is that cmake-native sees and uses the system wide
/usr/lib64/cmake/CURL/CURLConfig.cmake, which defines CURL::libcurl and
CURL::curl as opposed to setting ${CURL_LIBRARIES} as expected by
cmake-native.
find_package(CURL) (cmake-native's CMakeLists.txt, line 478) succeeds, but
incorrectly uses the system wide CURLConfig.cmake, resulting
CMAKE_CURL_LIBRARIES to be set to an empty string (cmake-native's
CMakeLists.txt, line 484), causing the cmake-native build to miss -lcurl.
The simplest fix is to let cmake know the right value for
CURL_LIBRARIES. Making it -lcurl should always work with libcurl-native
in recipe-sysroot-native.
Signed-off-by: Bernhard Rosenkränzer
---
meta/recipes-devtools/cmake/cmake-native_3.24.0.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-devtools/cmake/cmake-native_3.24.0.bb
b/meta/recipes-devtools/cmake/cmake-native_3.24.0.bb
index 722a486f20..bcc87eb8f2 100644
--- a/meta/recipes-devtools/cmake/cmake-native_3.24.0.bb
+++ b/meta/recipes-devtools/cmake/cmake-native_3.24.0.bb
@@ -32,6 +32,7 @@ CMAKE_EXTRACONF = "\
-DCMAKE_USE_SYSTEM_LIBRARY_EXPAT=0 \
-DENABLE_ACL=0 -DHAVE_ACL_LIBACL_H=0 \
-DHAVE_SYS_ACL_H=0 \
+-DCURL_LIBRARIES=-lcurl \
"
do_configure () {
--
2.38.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172203):
https://lists.openembedded.org/g/openembedded-core/message/172203
Mute This Topic: https://lists.openembedded.org/mt/94612335/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 1/1] cmake-native: Fix host tool contamination (Bug: 14951)
Trying to build cmake-native on a host system where curl was built with cmake
(resulting in CURLConfig.cmake and friends, which do not use the same naming
schemes expected by cmake-native's build process, being installed to a system
wide cmake directory like /usr/lib64/cmake/CURL) results in undefined
references to all libcurl symbols.
The problem is that cmake-native sees and uses the system wide
/usr/lib64/cmake/CURL/CURLConfig.cmake, which defines CURL::libcurl and
CURL::curl as opposed to setting ${CURL_LIBRARIES} as expected by
cmake-native.
find_package(CURL) (cmake-native's CMakeLists.txt, line 478) succeeds, but
incorrectly uses the system wide CURLConfig.cmake, resulting
CMAKE_CURL_LIBRARIES to be set to an empty string (cmake-native's
CMakeLists.txt, line 484), causing the cmake-native build to miss -lcurl.
The simplest fix is to let cmake know the right value for
CURL_LIBRARIES. Making it -lcurl should always work with libcurl-native
in recipe-sysroot-native.
Signed-off-by: Bernhard Rosenkränzer
---
meta/recipes-devtools/cmake/cmake-native_3.24.0.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-devtools/cmake/cmake-native_3.24.0.bb
b/meta/recipes-devtools/cmake/cmake-native_3.24.0.bb
index 722a486f20..bcc87eb8f2 100644
--- a/meta/recipes-devtools/cmake/cmake-native_3.24.0.bb
+++ b/meta/recipes-devtools/cmake/cmake-native_3.24.0.bb
@@ -32,6 +32,7 @@ CMAKE_EXTRACONF = "\
-DCMAKE_USE_SYSTEM_LIBRARY_EXPAT=0 \
-DENABLE_ACL=0 -DHAVE_ACL_LIBACL_H=0 \
-DHAVE_SYS_ACL_H=0 \
+-DCURL_LIBRARIES=-lcurl \
"
do_configure () {
--
2.38.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172200):
https://lists.openembedded.org/g/openembedded-core/message/172200
Mute This Topic: https://lists.openembedded.org/mt/94611422/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [kirkstone][PATCH 1/1] cmake-native: Fix host tool contamination (Bug: 14951)
Trying to build cmake-native on a host system where curl was built with cmake
(resulting in CURLConfig.cmake and friends, which do not use the same naming
schemes expected by cmake-native's build process, being installed to a system
wide cmake directory like /usr/lib64/cmake/CURL) results in undefined
references to all libcurl symbols.
The problem is that cmake-native sees and uses the system wide
/usr/lib64/cmake/CURL/CURLConfig.cmake, which defines CURL::libcurl and
CURL::curl as opposed to setting ${CURL_LIBRARIES} as expected by
cmake-native.
find_package(CURL) (cmake-native's CMakeLists.txt, line 478) succeeds, but
incorrectly uses the system wide CURLConfig.cmake, resulting
CMAKE_CURL_LIBRARIES to be set to an empty string (cmake-native's
CMakeLists.txt, line 484), causing the cmake-native build to miss -lcurl.
The simplest fix is to let cmake know the right value for
CURL_LIBRARIES. Making it -lcurl should always work with libcurl-native
in recipe-sysroot-native.
Signed-off-by: Bernhard Rosenkränzer
---
meta/recipes-devtools/cmake/cmake-native_3.22.3.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-devtools/cmake/cmake-native_3.22.3.bb
b/meta/recipes-devtools/cmake/cmake-native_3.22.3.bb
index ee1f7761c4..45ea78ae00 100644
--- a/meta/recipes-devtools/cmake/cmake-native_3.22.3.bb
+++ b/meta/recipes-devtools/cmake/cmake-native_3.22.3.bb
@@ -32,6 +32,7 @@ CMAKE_EXTRACONF = "\
-DCMAKE_USE_SYSTEM_LIBRARY_EXPAT=0 \
-DENABLE_ACL=0 -DHAVE_ACL_LIBACL_H=0 \
-DHAVE_SYS_ACL_H=0 \
+-DCURL_LIBRARIES=-lcurl \
"
do_configure () {
--
2.38.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172199):
https://lists.openembedded.org/g/openembedded-core/message/172199
Mute This Topic: https://lists.openembedded.org/mt/94611412/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] gcc: Update to 12.2
Update gcc to 12.2, drop
0001-libsanitizer-cherry-pick-9cf13067cb5088626ba7-from-u.patch
(which is already in 12.2)
Signed-off-by: Bernhard Rosenkränzer
---
.../gcc/{gcc-12.1.inc => gcc-12.2.inc}| 7 ++-
...ian_12.1.bb => gcc-cross-canadian_12.2.bb} | 0
.../{gcc-cross_12.1.bb => gcc-cross_12.2.bb} | 0
...-crosssdk_12.1.bb => gcc-crosssdk_12.2.bb} | 0
...cc-runtime_12.1.bb => gcc-runtime_12.2.bb} | 0
...itizers_12.1.bb => gcc-sanitizers_12.2.bb} | 0
...{gcc-source_12.1.bb => gcc-source_12.2.bb} | 0
...rry-pick-9cf13067cb5088626ba7-from-u.patch | 45 ---
.../gcc/{gcc_12.1.bb => gcc_12.2.bb} | 0
...initial_12.1.bb => libgcc-initial_12.2.bb} | 0
.../gcc/{libgcc_12.1.bb => libgcc_12.2.bb}| 0
...ibgfortran_12.1.bb => libgfortran_12.2.bb} | 0
12 files changed, 3 insertions(+), 49 deletions(-)
rename meta/recipes-devtools/gcc/{gcc-12.1.inc => gcc-12.2.inc} (95%)
rename meta/recipes-devtools/gcc/{gcc-cross-canadian_12.1.bb =>
gcc-cross-canadian_12.2.bb} (100%)
rename meta/recipes-devtools/gcc/{gcc-cross_12.1.bb => gcc-cross_12.2.bb}
(100%)
rename meta/recipes-devtools/gcc/{gcc-crosssdk_12.1.bb =>
gcc-crosssdk_12.2.bb} (100%)
rename meta/recipes-devtools/gcc/{gcc-runtime_12.1.bb => gcc-runtime_12.2.bb}
(100%)
rename meta/recipes-devtools/gcc/{gcc-sanitizers_12.1.bb =>
gcc-sanitizers_12.2.bb} (100%)
rename meta/recipes-devtools/gcc/{gcc-source_12.1.bb => gcc-source_12.2.bb}
(100%)
delete mode 100644
meta/recipes-devtools/gcc/gcc/0001-libsanitizer-cherry-pick-9cf13067cb5088626ba7-from-u.patch
rename meta/recipes-devtools/gcc/{gcc_12.1.bb => gcc_12.2.bb} (100%)
rename meta/recipes-devtools/gcc/{libgcc-initial_12.1.bb =>
libgcc-initial_12.2.bb} (100%)
rename meta/recipes-devtools/gcc/{libgcc_12.1.bb => libgcc_12.2.bb} (100%)
rename meta/recipes-devtools/gcc/{libgfortran_12.1.bb => libgfortran_12.2.bb}
(100%)
diff --git a/meta/recipes-devtools/gcc/gcc-12.1.inc
b/meta/recipes-devtools/gcc/gcc-12.2.inc
similarity index 95%
rename from meta/recipes-devtools/gcc/gcc-12.1.inc
rename to meta/recipes-devtools/gcc/gcc-12.2.inc
index 488e0c95b1..572fd8b669 100644
--- a/meta/recipes-devtools/gcc/gcc-12.1.inc
+++ b/meta/recipes-devtools/gcc/gcc-12.2.inc
@@ -2,11 +2,11 @@ require gcc-common.inc
# Third digit in PV should be incremented after a minor release
-PV = "12.1.0"
+PV = "12.2.0"
# BINV should be incremented to a revision after a minor gcc release
-BINV = "12.1.0"
+BINV = "12.2.0"
FILESEXTRAPATHS =. "${FILE_DIRNAME}/gcc:${FILE_DIRNAME}/gcc/backport:"
@@ -64,11 +64,10 @@ SRC_URI = "${BASEURI} \
file://0024-Fix-install-path-of-linux64.h.patch \
file://0025-Move-sched.h-include-ahead-of-user-headers.patch \
file://0026-rust-recursion-limit.patch \
-
file://0001-libsanitizer-cherry-pick-9cf13067cb5088626ba7-from-u.patch \
file://prefix-map-realpath.patch \
file://hardcoded-paths.patch \
"
-SRC_URI[sha256sum] =
"62fd634889f31c02b64af2c468f064b47ad1ca78411c45abe6ac4b5f8dd19c7b"
+SRC_URI[sha256sum] =
"e549cf9cf3594a00e27b6589d4322d70e0720cdd213f39beb4181e06926230ff"
S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/${SOURCEDIR}"
B = "${WORKDIR}/gcc-${PV}/build.${HOST_SYS}.${TARGET_SYS}"
diff --git a/meta/recipes-devtools/gcc/gcc-cross-canadian_12.1.bb
b/meta/recipes-devtools/gcc/gcc-cross-canadian_12.2.bb
similarity index 100%
rename from meta/recipes-devtools/gcc/gcc-cross-canadian_12.1.bb
rename to meta/recipes-devtools/gcc/gcc-cross-canadian_12.2.bb
diff --git a/meta/recipes-devtools/gcc/gcc-cross_12.1.bb
b/meta/recipes-devtools/gcc/gcc-cross_12.2.bb
similarity index 100%
rename from meta/recipes-devtools/gcc/gcc-cross_12.1.bb
rename to meta/recipes-devtools/gcc/gcc-cross_12.2.bb
diff --git a/meta/recipes-devtools/gcc/gcc-crosssdk_12.1.bb
b/meta/recipes-devtools/gcc/gcc-crosssdk_12.2.bb
similarity index 100%
rename from meta/recipes-devtools/gcc/gcc-crosssdk_12.1.bb
rename to meta/recipes-devtools/gcc/gcc-crosssdk_12.2.bb
diff --git a/meta/recipes-devtools/gcc/gcc-runtime_12.1.bb
b/meta/recipes-devtools/gcc/gcc-runtime_12.2.bb
similarity index 100%
rename from meta/recipes-devtools/gcc/gcc-runtime_12.1.bb
rename to meta/recipes-devtools/gcc/gcc-runtime_12.2.bb
diff --git a/meta/recipes-devtools/gcc/gcc-sanitizers_12.1.bb
b/meta/recipes-devtools/gcc/gcc-sanitizers_12.2.bb
similarity index 100%
rename from meta/recipes-devtools/gcc/gcc-sanitizers_12.1.bb
rename to meta/recipes-devtools/gcc/gcc-sanitizers_12.2.bb
diff --git a/meta/recipes-devtools/gcc/gcc-source_12.1.bb
b/meta/recipes-devtools/gcc/gcc-source_12.2.bb
similarity index 100%
rename from meta/recipes-devtools/gcc/gcc-source_12.1.bb
rename to meta/recipes-devtools/gcc/gcc-source_12.2.bb
diff --git
a/meta/recipes-devtools/gcc/gcc/0001-libsanitizer-cherry-pick-9cf13067cb5088626ba7-from-u.patch
b/meta/recipes-devtools/gcc/gcc/0001-libsanitizer-cherry-pick-9cf13067cb5088626ba7-from-u.patch
deleted
Re: [OE-core] [PATCH] gcc: upgrade 11.2 -> current 12 snapshot
On Thu, Apr 7, 2022 at 02:32 PM, Richard Purdie wrote:
>
> On Thu, 2022-04-07 at 14:26 +0200, Bernhard Rosenkränzer via
> lists.openembedded.org wrote:
>
>> rename from meta/recipes-devtools/gcc/gcc-cross-canadian_11.2.bb
>> rename to meta/recipes-devtools/gcc/gcc-cross-canadian_12.0.bb
>> diff --git a/meta/recipes-devtools/gcc/gcc-cross.inc
>> b/meta/recipes-devtools/gcc/gcc-cross.inc
>> index 3ffa1f0c46..0e8119384b 100644
>> --- a/meta/recipes-devtools/gcc/gcc-cross.inc
>> +++ b/meta/recipes-devtools/gcc/gcc-cross.inc
>> @@ -47,6 +47,15 @@ ARCH_FLAGS_FOR_TARGET +=
>> "-isystem${STAGING_DIR_TARGET}${target_includedir}"
>> do_configure:prepend () {
>> install -d ${RECIPE_SYSROOT}${target_includedir}
>> touch ${RECIPE_SYSROOT}${target_includedir}/limits.h
>> +
>> + if ! echo ${@d.getVar("TARGET_OS")} | grep -qi linux; then
>> + # Building Zephyr with DWARF-5 is problematic because
>> + # its kernel tests use pyelftools, which has incomplete
>> + # DWARF-5 support (even after applying preliminary
>> + # support patches). Use DWARF-4 on Zephyr and FreeRTOS
>> + # for the time being.
>> + sed -i -e 's,Var(dwarf_version) Init(5),Var(dwarf_version) Init(4),'
>> ${S}/gcc/common.opt
>> + fi
>> }
>>
>> do_compile () {
>
> Unfortunately you can't do that. The gcc-cross is shared amongst all
> targets on
> a given architecture. This will "kind of work" in that other sstate code
> will
> clean it up and rebuild gcc but it isn't as designed and can't merge like
> that
> I'm afraid.
True, didn't think of that. I've backed out this part and sent a new patch.
Will address the zephyr problem with an added -gdwarf-4 flag in zephyr configs.
ttyl
bero
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#164108):
https://lists.openembedded.org/g/openembedded-core/message/164108
Mute This Topic: https://lists.openembedded.org/mt/90311375/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] recipes-core/ovmf: Fix build with gcc 12
From: Bernhard Rosenkränzer
edk2 doesn't compile with gcc 12 - due to 2 legitimate bugs (trying to
use a file handle as if it were a string) and 2 new warnings in code
using -Werror (they need further investigation to determine if they're
legitimate bugs or false positives; in the mean time we can keep things
building by disabling the warnings for the particular lines triggering
them).
The proper fixes have already been submitted upstream at
https://github.com/tianocore/edk2/pull/2602
Will not submit the workarounds for the warnings upstream for now.
Signed-off-by: Bernhard Rosenkränzer
---
...nfusion-between-file-handle-and-name.patch | 44 +++
...orkaround-for-gcc-12-build-failure-2.patch | 33 ++
...-workaround-for-gcc-12-build-failure.patch | 28
meta/recipes-core/ovmf/ovmf_git.bb| 3 ++
4 files changed, 108 insertions(+)
create mode 100644
meta/recipes-core/ovmf/ovmf/edk2-fix-confusion-between-file-handle-and-name.patch
create mode 100644
meta/recipes-core/ovmf/ovmf/edk2-workaround-for-gcc-12-build-failure-2.patch
create mode 100644
meta/recipes-core/ovmf/ovmf/edk2-workaround-for-gcc-12-build-failure.patch
diff --git
a/meta/recipes-core/ovmf/ovmf/edk2-fix-confusion-between-file-handle-and-name.patch
b/meta/recipes-core/ovmf/ovmf/edk2-fix-confusion-between-file-handle-and-name.patch
new file mode 100644
index 00..98023f93c2
--- /dev/null
+++
b/meta/recipes-core/ovmf/ovmf/edk2-fix-confusion-between-file-handle-and-name.patch
@@ -0,0 +1,44 @@
+From 74e7ad4e400ea3f942805e70df4d3ed6990759f3 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Bernhard=20Rosenkr=C3=A4nzer?=
+Date: Tue, 8 Mar 2022 18:56:23 +0100
+Subject: [PATCH] GenFfs: Don't treat a file handle as a string
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The current code tries to print the file handle as a string on error.
+Do what it is meant to do instead: Print the file name.
+
+Upstream-Status: Submitted [https://github.com/tianocore/edk2/pull/2602]
+Signed-off-by: Bernhard Rosenkränzer
+---
+ BaseTools/Source/C/GenFfs/GenFfs.c | 2 +-
+ BaseTools/Source/C/GenSec/GenSec.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/BaseTools/Source/C/GenFfs/GenFfs.c
b/BaseTools/Source/C/GenFfs/GenFfs.c
+index 949025c33325..06e009e279ce 100644
+--- a/BaseTools/Source/C/GenFfs/GenFfs.c
b/BaseTools/Source/C/GenFfs/GenFfs.c
+@@ -542,7 +542,7 @@ GetAlignmentFromFile(char *InFile, UINT32 *Alignment)
+ PeFileBuffer = (UINT8 *) malloc (PeFileSize);
+ if (PeFileBuffer == NULL) {
+ fclose (InFileHandle);
+-Error(NULL, 0, 4001, "Resource", "memory cannot be allocated of %s",
InFileHandle);
++Error(NULL, 0, 4001, "Resource", "memory cannot be allocated of %s",
InFile);
+ return EFI_OUT_OF_RESOURCES;
+ }
+ fread (PeFileBuffer, sizeof (UINT8), PeFileSize, InFileHandle);
+diff --git a/BaseTools/Source/C/GenSec/GenSec.c
b/BaseTools/Source/C/GenSec/GenSec.c
+index d54a4f9e0a7d..1ad92de1d50e 100644
+--- a/BaseTools/Source/C/GenSec/GenSec.c
b/BaseTools/Source/C/GenSec/GenSec.c
+@@ -1062,7 +1062,7 @@ GetAlignmentFromFile(char *InFile, UINT32 *Alignment)
+ PeFileBuffer = (UINT8 *) malloc (PeFileSize);
+ if (PeFileBuffer == NULL) {
+ fclose (InFileHandle);
+-Error(NULL, 0, 4001, "Resource", "memory cannot be allocated of %s",
InFileHandle);
++Error(NULL, 0, 4001, "Resource", "memory cannot be allocated of %s",
InFile);
+ return EFI_OUT_OF_RESOURCES;
+ }
+ fread (PeFileBuffer, sizeof (UINT8), PeFileSize, InFileHandle);
diff --git
a/meta/recipes-core/ovmf/ovmf/edk2-workaround-for-gcc-12-build-failure-2.patch
b/meta/recipes-core/ovmf/ovmf/edk2-workaround-for-gcc-12-build-failure-2.patch
new file mode 100644
index 00..e7b7269d82
--- /dev/null
+++
b/meta/recipes-core/ovmf/ovmf/edk2-workaround-for-gcc-12-build-failure-2.patch
@@ -0,0 +1,33 @@
+From: Bernhard Rosenkränzer
+Date: Fri, 18 Mar 2022 17:28:47 +0100
+Subject: [PATCH] Disable gcc >= 12 stringop-overflow warning
+
+gcc 12 warns about a stringop-overflow with SetDevicePathEndNode
+potentially copying 4 bytes to an area of 1 byte.
+Since edk2 is built with -Werror, this breaks the build.
+
+It is not immedaitely clear whether this is a false warning or if
+SetDevicePathEndNode is being used incorrectly somewhere, but since
+the code seems to work, ignore the warning for the time being to
+keep things buildable.
+
+This should be investigated properly at some point.
+
+Upstream-Status: Inappropriate [Workaround to keep things going, should be
fixed properly]
+Signed-off-by: Bernhard Rosenkränzer
+
+diff --git a/BaseTools/Source/C/DevicePath/DevicePathUtilities.c
b/BaseTools/Source/C/DevicePath/DevicePathUtilities.c
+index 2ffefa8cee..32c02bdf82 100644
+--- a/BaseTools/Source/C/DevicePath/DevicePathUtilities.c
b/BaseTools/Source/C/DevicePath/DevicePathUtilities.c
+@@ -318,7 +318,10 @@
[OE-core] gcc 12 support
Hi, with gcc 12 likely being released next month, I thought it's a good idea to get started on supporting it -- I've submitted a patch that fixes building ovmf, will submit a few more as I run into more failures. If anyone is interested in gcc 12 itself, I've uploaded a recipe for the current 12 snapshot to https://lindev.ch/gcc12.tar.xz (Probably not worth submitting until gcc 12 is released upstream...) ttyl bero -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#163469): https://lists.openembedded.org/g/openembedded-core/message/163469 Mute This Topic: https://lists.openembedded.org/mt/89887595/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] gcc: Fix tm.h plugin header
On Thu, Dec 9, 2021 at 07:40 PM, Andrei Gherzan wrote:
>
> On Thu, 9 Dec 2021, at 16:40, Khem Raj wrote:
>
>> On Thu, Dec 9, 2021 at 7:40 AM Andrei Gherzan wrote:
>>
>>> From: Andrei Gherzan
>>>
>>> On x86-64, tm.h (needed to build gcc plugins) tries to include
>>> config/i386/linux64.h, which isn't installed. Fortunately it also isn't
>>> used, so simply removing the include statement is an ok fix.
>>
>> is it due to multilib support ? if so we might be ok since we may not
>> be using it
>> but really it will be good to check it with multilib builds of x86_64/x86
>
> I don't think it is related to multilib but I'll give multilib a try. In
> my case, the issue was revealed when compiling a kernel plugin config. I
> can't remember right now which one but I can replicate it for logs.
Hi,
I've had a closer look at the problem, and can confirm the patch doesn't break
even in multilib setups.
The problem is that in a non-multilib setup, the config/i386/linux64.h header
is not generated, but tm.h tries to include it nevertheless, causing any gcc
plugin that #includes tm.h (such as all the gcc plugins in the kernel -- tm.h
is included by scripts/gcc-plugins/gcc-common.h) to fail to build.
An alternative fix would be adding
mkdir -p ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/plugin/include/config/i386
touch
${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/plugin/include/config/i386/linux64.h
(creating the file if it isn't there) instead. This would make sure that in
cases where config/i386/linux64.h does exist, it doesn't get removed from tm.h
(potentially fixing plugins that reference any of the #defines in
i386/linux64.h without including the file manually -- but I have yet to see any
such plugin).
I will try to get a better fix (not adding the include statement to tm.h in the
first place rather than having to remove it later in install scripts) upstream,
but in the mean time, the patch fixes our builds before the better fix is
ready/applied.
ttyl
bero
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159853):
https://lists.openembedded.org/g/openembedded-core/message/159853
Mute This Topic: https://lists.openembedded.org/mt/87614108/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] gcc: update 11.1 -> 11.2
Update gcc, drop patches that have been merged upstream
Signed-off-by: Bernhard Rosenkränzer
---
.../gcc/{gcc-11.1.inc => gcc-11.2.inc}| 12 +-
...ian_11.1.bb => gcc-cross-canadian_11.2.bb} | 0
.../{gcc-cross_11.1.bb => gcc-cross_11.2.bb} | 0
...-crosssdk_11.1.bb => gcc-crosssdk_11.2.bb} | 0
...cc-runtime_11.1.bb => gcc-runtime_11.2.bb} | 0
...itizers_11.1.bb => gcc-sanitizers_11.2.bb} | 0
...{gcc-source_11.1.bb => gcc-source_11.2.bb} | 0
...nstallation-of-python-hooks-PR-99453.patch | 57
...arc-Update-64bit-move-split-patterns.patch | 290 --
.../0039-arc-Fix-u-maddhisi-patterns.patch| 127
.../0040-arc-Update-doloop_end-patterns.patch | 105 ---
.../gcc/{gcc_11.1.bb => gcc_11.2.bb} | 0
...initial_11.1.bb => libgcc-initial_11.2.bb} | 0
.../gcc/{libgcc_11.1.bb => libgcc_11.2.bb}| 0
...ibgfortran_11.1.bb => libgfortran_11.2.bb} | 0
15 files changed, 3 insertions(+), 588 deletions(-)
rename meta/recipes-devtools/gcc/{gcc-11.1.inc => gcc-11.2.inc} (88%)
rename meta/recipes-devtools/gcc/{gcc-cross-canadian_11.1.bb =>
gcc-cross-canadian_11.2.bb} (100%)
rename meta/recipes-devtools/gcc/{gcc-cross_11.1.bb => gcc-cross_11.2.bb}
(100%)
rename meta/recipes-devtools/gcc/{gcc-crosssdk_11.1.bb =>
gcc-crosssdk_11.2.bb} (100%)
rename meta/recipes-devtools/gcc/{gcc-runtime_11.1.bb => gcc-runtime_11.2.bb}
(100%)
rename meta/recipes-devtools/gcc/{gcc-sanitizers_11.1.bb =>
gcc-sanitizers_11.2.bb} (100%)
rename meta/recipes-devtools/gcc/{gcc-source_11.1.bb => gcc-source_11.2.bb}
(100%)
delete mode 100644
meta/recipes-devtools/gcc/gcc/0001-libstdc-Fix-installation-of-python-hooks-PR-99453.patch
delete mode 100644
meta/recipes-devtools/gcc/gcc/0038-arc-Update-64bit-move-split-patterns.patch
delete mode 100644
meta/recipes-devtools/gcc/gcc/0039-arc-Fix-u-maddhisi-patterns.patch
delete mode 100644
meta/recipes-devtools/gcc/gcc/0040-arc-Update-doloop_end-patterns.patch
rename meta/recipes-devtools/gcc/{gcc_11.1.bb => gcc_11.2.bb} (100%)
rename meta/recipes-devtools/gcc/{libgcc-initial_11.1.bb =>
libgcc-initial_11.2.bb} (100%)
rename meta/recipes-devtools/gcc/{libgcc_11.1.bb => libgcc_11.2.bb} (100%)
rename meta/recipes-devtools/gcc/{libgfortran_11.1.bb => libgfortran_11.2.bb}
(100%)
diff --git a/meta/recipes-devtools/gcc/gcc-11.1.inc
b/meta/recipes-devtools/gcc/gcc-11.2.inc
similarity index 88%
rename from meta/recipes-devtools/gcc/gcc-11.1.inc
rename to meta/recipes-devtools/gcc/gcc-11.2.inc
index c21242af58..31dbc072b8 100644
--- a/meta/recipes-devtools/gcc/gcc-11.1.inc
+++ b/meta/recipes-devtools/gcc/gcc-11.2.inc
@@ -2,11 +2,11 @@ require gcc-common.inc
# Third digit in PV should be incremented after a minor release
-PV = "11.1.0"
+PV = "11.2.0"
# BINV should be incremented to a revision after a minor gcc release
-BINV = "11.1.1"
+BINV = "11.2.0"
FILESEXTRAPATHS =. "${FILE_DIRNAME}/gcc:${FILE_DIRNAME}/gcc/backport:"
@@ -27,7 +27,6 @@ LIC_FILES_CHKSUM = "\
#BASEURI ?=
"https://github.com/gcc-mirror/gcc/archive/${RELEASE}.zip;downloadfilename=gcc-${PV}-${RELEASE}.zip;
BASEURI ?= "${GNU_MIRROR}/gcc/gcc-${PV}/gcc-${PV}.tar.xz \
-
http://downloads.yoctoproject.org/mirror/sources/gcc-11.1.0-9ee61d2b51df012c659359873637cc2162ecccf3.patch;apply=yes;name=backports
\
"
SRC_URI = "\
${BASEURI} \
@@ -68,13 +67,8 @@ SRC_URI = "\
file://0035-gentypes-genmodes-Do-not-use-__LINE__-for-maintainin.patch \
file://0036-mingw32-Enable-operation_not_supported.patch \
file://0037-libatomic-Do-not-enforce-march-on-aarch64.patch \
- file://0001-libstdc-Fix-installation-of-python-hooks-PR-99453.patch
\
- file://0038-arc-Update-64bit-move-split-patterns.patch \
- file://0039-arc-Fix-u-maddhisi-patterns.patch \
- file://0040-arc-Update-doloop_end-patterns.patch \
"
-SRC_URI[sha256sum] =
"4c4a6fb8a8396059241c2e674b85b351c26a5d678274007f076957afa1cc9ddf"
-SRC_URI[backports.sha256sum] =
"69274bebd6c069a13443d4af61070e854740a639ec4d66eedf3e80070363587b"
+SRC_URI[sha256sum] =
"d08edc536b54c372a1010ff6619dd274c0f1603aa49212ba20f7aa2cda36fa8b"
S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/gcc-${PV}"
diff --git a/meta/recipes-devtools/gcc/gcc-cross-canadian_11.1.bb
b/meta/recipes-devtools/gcc/gcc-cross-canadian_11.2.bb
similarity index 100%
rename from meta/recipes-devtools/gcc/gcc-cross-canadian_11.1.bb
rename to meta/recipes-devtools/gcc/gcc-cross-canadian_11.2.bb
diff --git a/meta/recipes-devtools/gcc/gcc-cross_11.1.bb
b/meta/recipes-devtools/gcc/gcc-cross_11.2.bb
similarity index 100%
rename from meta/recipes-devtools/gcc/gcc-cross_11.1.bb
rename to meta/recipes-devtools/gcc/gcc-cross_11.2.bb
diff --git a/meta/recipes-devtools/gcc/gcc-crosssdk_11.1.bb
b/meta/recipes-devtools/gcc/gcc-crosssdk_11.2.bb
similarity index 100%
rename from meta/recipes-devtools/gcc/gcc-crosssdk_11.1.bb
rename to
