Updating GCC_DEFAULT from GCC 10 to GCC 11 is blocked by the fact that building this port with GCC 11 fails. Please see the logs at the following urls: http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-09-18_18h41m21s/logs/errors/edk2-fvp-g202102.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-09-18_18h41m21s/logs/errors/edk2-rpi3-g202102.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-09-18_18h41m21s/logs/errors/edk2-rpi4-g202102.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-09-18_18h41m21s/logs/errors/edk2-xen-x64-g202102.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-09-18_18h41m21s/logs/errors/edk2-macchiatobin-g202102.log Also, it should be checked if USE_GCC is still needed and that the default clang compiler can't be used instead.
Some notes on EDK2 being odd, making sysutil/edk2 also odd for handling EDK2. (One point is that the invalid C code involved is actually upstream from EDK2. But that is not where this note is focused.) EDK2 is unusual in that it does not define any release that is good for all the platforms it supports at once. EDK2 also is structured using submodules for upstream, expecting a live use of git to get the upstream materials. This actually plays into how releases are generally handled by downstream EDK2 projects that put their code into EDK2. For example, https://github.com/pftf/RPi4 has edk2 via submodules (and so recursively on up stream). The submodules pick out a known/somewhat-tested combination of commits for the upstreams, including edk2 itself. There is very little else to https://github.com/pftf/RPi4 . Most of its representation is in edk2 itself. There is also a https://github.com/pftf/RPi3 that works similarly but that is based on a different set of EDK2 submodule commit points (and so recursively upstream). Turns out that https://github.com/pftf/RPi4 is referencing EDK2 modern enough to build under gcc11 but https://github.com/pftf/RPi3 has not progressed that far yet. But far more than that is involved in what commits the two use out of EDK2 (and upstream). Another issue is that different platforms can require a different subset of all the edk2 (and upstream) submodules. For example, https://github.com/pftf/RPi4 omits at least one submodule required for riscv, if I understand right. Picking out a release for a platform generally requires tracking a downstream project for the platform, even if is is primarily for identifying commits of EDK2 to use. I made the below for matching v1.33 of https://github.com/pftf/RPi4 I only include it for illustration. It is probably not appropriate to all the flavors the sysutils/edk2 port claims to target. # more /usr/ports/sysutils/edk2-pftf-rpi4/distinfo TIMESTAMP = 1650175003 SHA256 (tianocore-edk2-v1.33-edk2-stable201903-4059-g79f2734e5a_GH0.tar.gz) = d27d53d02772beddfbe7dd3e7d094a6786302b076f95668645024f07b9b6431b SIZE (tianocore-edk2-v1.33-edk2-stable201903-4059-g79f2734e5a_GH0.tar.gz) = 14223044 SHA256 (tianocore-edk2-platforms-958fc02b15_GH0.tar.gz) = f94257ab457a0344247fa79e433a14b9bb22abf5007e5507d5fc50cc76e79aac SIZE (tianocore-edk2-platforms-958fc02b15_GH0.tar.gz) = 10340955 SHA256 (tianocore-edk2-non-osi-0320db9_GH0.tar.gz) = c9b2af563d8a919b38895c649858515c71226cb24c171f3de891d72e35c2875c SIZE (tianocore-edk2-non-osi-0320db9_GH0.tar.gz) = 18901823 SHA256 (openssl-openssl-OpenSSL_1_1_1j_GH0.tar.gz) = 22d6588e4a7c5ad48fcac2fbf1d035bd43258c22a49457dad0539ded0651b4d2 SIZE (openssl-openssl-OpenSSL_1_1_1j_GH0.tar.gz) = 9994760 SHA256 (ucb-bar-berkeley-softfloat-3-b64af41_GH0.tar.gz) = f22bf52cc980b122c663f2e22f8098fa60d8e468e0095f1da58231235a6b324e SIZE (ucb-bar-berkeley-softfloat-3-b64af41_GH0.tar.gz) = 148768 SHA256 (kkos-oniguruma-v6.9.4_mark1_GH0.tar.gz) = 7f7576c926f7d4a071d594a01691c477bbb9391df250378bd5e1c003d42b4318 SIZE (kkos-oniguruma-v6.9.4_mark1_GH0.tar.gz) = 592141 SHA256 (google-brotli-v1.0.9-36-gf4153a0_GH0.tar.gz) = bd103cee96d67e4fde08989316a86309e0e5498c346d3f98efbd94bce3b7f6ba SIZE (google-brotli-v1.0.9-36-gf4153a0_GH0.tar.gz) = 512034 The bad C code that gcc11 correctly rejects was in a prior vintage of google-brotli . (gcc10 accepts the bad code without complaint.) Given all this, it is not obvious to me that sysutils/edk2 in its current state should block progressing the gcc default to gcc11. Nor is it obvious what sysutils/edk2 is in an appropriate state for building reasonable platform-specific edk2 instances. In my view tracking the commit usage of some downstream project that is platform specific should be done in order for edk2 builds to do platform specific version tracking.
A separate, additional note tied to being able to build on aarch64 . . . The Makefile that I used to test building to match the EDK2 material used in https://github.com/pftf/RPi4 ended up with the following: USE_GCC= 11:build # Note: # I needed to use a -Wl,-rpath=/usr/local/lib/gcc* to work around # FreeBSD's /lib/libgcc_s.so.1 having incomplete/inaccurate # coverage for aarch64 g++ code generation's use of libgcc_s.so.1 . # Otherwise tools built, such as VfrCompile, get the following # when run: "ld-elf.so.1: /lib/libgcc_s.so.1: version GCC_4.5.0 # required by /usr/local/lib/gcc11/libstdc++.so.6 not found". # I did not see a supported way to have an automatically # adjusting -Wl,-rpath=/usr/local/lib/gcc* . . . . # Avoid: "ld-elf.so.1: /lib/libgcc_s.so.1: version GCC_4.5.0 # required by /usr/local/lib/gcc11/libstdc++.so.6 not found" # (that is from /lib/libgcc_s.so.1 having incomplete/inaccurate # coverage for aarch64 g++ code generation's use of libgcc_s.so.1 ): EXTRA_LDFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc11
(In reply to Mark Millard from comment #2) I should have mentioned using EXTRA_LDFLAGS=${EXTRA_LDFLAGS} in setting up MAKE_ENV .
A new bug has been opened to fix the build of sysutils/edk2 with GCC 12. Please see bug #264262.
*** Bug 264262 has been marked as a duplicate of this bug. ***
This bugzilla originally documented that compiling with gcc11 was broken. That was fixed and this bugzilla submittal should have been closed on that basis as far as I can tell. The issue for gcc12 / gcc13 is a distinct issue, with a different type of compiler rejection of distinct code: different code needs to be updated now. Now that this bugzilla has been put to a different use, just be warned to ignore the edk2-*.log files referenced in the original desciption in this bugzilla. They will show the error that no longer happens for gcc11 and later. Somebody should add material about the new compiler rejection by gcc12 and gcc13 and what code is involved. (I might get to such at some point.) Note: I've only tried gcc12 in the past. I've no evidence about gcc13 or later.
(In reply to Mark Millard from comment #6) I am sorry, but I know very little about this port so I could not understand much about comment #1, comment #2 and comment #3. So what you were telling us, as much as GCC is involved, is that the port builds fine with GCC 11? Have I understood correctly? Indeed, the poudriere logs we have from the exp-run are a bit old and things might have been fixed since then.
(In reply to Lorenzo Salvadore from comment #7) Last I tested building via via lang/gcc11 it built. Later when I tested building it via lang/gcc12 it did not. The commit that got it to build with lang/gcc11 was: author Emmanuel Vadot <manu@FreeBSD.org> 2022-05-02 16:49:56 +0000 committer Emmanuel Vadot <manu@FreeBSD.org> 2022-05-02 16:52:29 +0000 commit 7d47e1f2971cabf764770d0388b2c6ad671e9f94 (patch) tree 328be8ebb7641c614845559ee7661ef725b1c0b8 /sysutils/edk2 parent 4e73a1fd32da46003d7070527b56b69bd3e1e6d8 (diff) download ports-7d47e1f2971cabf764770d0388b2c6ad671e9f94.tar.gz ports-7d47e1f2971cabf764770d0388b2c6ad671e9f94.zip sysutils/edk2: Update to stable202202 Release notes: https://github.com/tianocore/edk2/releases/tag/edk2-stable202202 Release notes: https://github.com/tianocore/edk2/releases/tag/edk2-stable202111 Release notes: https://github.com/tianocore/edk2/releases/tag/edk2-stable202108 Release notes: https://github.com/tianocore/edk2/releases/tag/edk2-stable202105 The lang/gcc12 rejection of that update is a separate issue.
(In reply to Mark Millard from comment #8) Thank you very much Mark. Then I remove the block for the update of GCC default version to version 11 and the URL from the bug description.
Created attachment 234324 [details] patch to fix build of sysutils/edk2 with gcc12 Moving GCC12 fix from closed bug #264262 issue as suggested: Backport 2 upstreamed patches and fix ar path While here pet portlint
Patch looks good to me, thanks.
Updating GCC_DEFAULT from GCC 11 to GCC 12 is blocked by the fact that building this port with GCC 12 on amd64 fails. Please see the logs at the following urls: http://package18.nyi.freebsd.org/data/123amd64-default-foo/2022-08-30_18h10m18s/logs/errors/edk2-bhyve-g202202_1.log http://package18.nyi.freebsd.org/data/123amd64-default-foo/2022-08-30_18h10m18s/logs/errors/edk2-fvp-g202202_1.log http://package18.nyi.freebsd.org/data/123amd64-default-foo/2022-08-30_18h10m18s/logs/errors/edk2-qemu-i386-g202202_1.log http://package18.nyi.freebsd.org/data/123amd64-default-foo/2022-08-30_18h10m18s/logs/errors/edk2-qemu-x64-g202202_1.log http://package18.nyi.freebsd.org/data/123amd64-default-foo/2022-08-30_18h10m18s/logs/errors/edk2-rpi3-g202202_1.log http://package18.nyi.freebsd.org/data/123amd64-default-foo/2022-08-30_18h10m18s/logs/errors/edk2-rpi4-g202202_1.log http://package18.nyi.freebsd.org/data/123amd64-default-foo/2022-08-30_18h10m18s/logs/errors/edk2-xen-x64-g202202_1.log http://package18.nyi.freebsd.org/data/123amd64-default-foo/2022-08-30_18h10m18s/logs/errors/edk2-macchiatobin-g202202_1.log I see there is already an approved patch, probably tested with GCC 12.1. Please note that we have now GCC 12.2. Could someone please check that the patch still compiles and that it still solves the issue? Thanks.
(In reply to Lorenzo Salvadore from comment #12) It still works for me
(In reply to Oleg Sidorkin from comment #13) Thanks Oleg. Emmanuel: Could you please confirm that the patch is still maintainer approved (I see you set the mainter-feedback flag and wrote that the patch is fine for you; I guess I can consider it equivalent to setting the maintainer-approval flag). In case you confirm, could you please commit it or do you prefer I do it?
(In reply to Lorenzo Salvadore from comment #14) Still ok for me if that compiles. I already have some issue to fix based on the latest gcc update (I think) on aarch64 and I don't want to have other to fix.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=675ef8421cde2569121e3b623c481f25d2de6c34 commit 675ef8421cde2569121e3b623c481f25d2de6c34 Author: Oleg Sidorkin <osidorkin@gmail.com> AuthorDate: 2022-09-09 22:02:50 +0000 Commit: Lorenzo Salvadore <salvadore@FreeBSD.org> CommitDate: 2022-09-09 22:19:51 +0000 sysutils/edk2: Fix build with GCC 12 - Backport two upstreamed patches. - Fix ar path. While here, pet portlint. PR: 263543 Reported by: exp-run (antoine) Approved by: manu sysutils/edk2/Makefile | 11 ++++++++--- sysutils/edk2/distinfo | 6 +++++- 2 files changed, 13 insertions(+), 4 deletions(-)
Commited, thanks Oleg. Emmanuel: I have tested the patch with poudriere on amd64 (all flavors) and I confirm it compiles successfully.
(In reply to Lorenzo Salvadore from comment #17) FYI: compile problems are not the only ones around. The new: https://lists.freebsd.org/archives/freebsd-uboot/2022-September/000295.html for [package - 131arm64-default][sysutils/edk2] Failed for edk2-fvp-g202202_1 in build shows a failure reason: ld-elf.so.1: /lib/libgcc_s.so.1: version GCC_4.5.0 required by /usr/local/lib/gcc11/libstdc++.so.6 not found Even main does not have GCC_4.5.0 in /lib/libgcc_s.so.1: # strings /lib/libgcc_s.so.1 | grep GCC_ | more GCC_3.0 GCC_3.3 GCC_3.3.1 GCC_3.4 GCC_3.4.2 GCC_3.4.4 GCC_3.5 GCC_4.0.0 GCC_4.2.0 GCC_4.3.0 GCC_4.6.0 Until/unless FreeBSD makes /lib/libgcc_s.so.1 have the symbols that aarch64 gcc/g++/libstdc++ actually requires under various conditions, it takes linking against the g++*'s specific /usr/local/lib/gcc*/libgcc_s.so.1 instead of using /lib/libgcc_s.so.1 when the activity happens to hit those conditions. EDK2 and other things around do not always do this.
(In reply to Mark Millard from comment #18) Thanks Mark. Unfortunately, I could not test the patch on aarch64 too, however it seems to me that the problem you are referencing is not related to the last commit as - you already referenced it in comment #2 (it is the same, am I wrong?) and it is maybe also the same that Emmanuel has referenced in comment #15; - the same error seems to have already been reported by pkg-fallout at https://lists.freebsd.org/archives/freebsd-uboot/2022-September/000273.html , which is before last commit. So I think that as far as the last commit is involved, things are still fine. If they are not, we can always revert the commit and put USE_GCC=11 so that this port does not block the GCC_DEFAULT upgrade. If I understood correctly comment #2, adding EXTRA_LDFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${GCC_DEFAULT} fixes the issue. May I encourage you to open a new bug report and submit a patch with your fix?
(In reply to Lorenzo Salvadore from comment #19) My comment #17 is related to what I'd referenced in #2, for sure. I should have referenced #2 explicitly. Agreed that there is no need to revert to gcc11: it has the same issue since the problem with /lib/libgcc_s.so.1 use is on the FreeBSD side of things for aarch64, FreeBSD not matching what gcc has long defined as needed for the likes of libstdc++ use for aarch64. The mismatch for a tier 1 context is unfortunate in my view. Agreed that the addition of the likes of: EXTRA_LDFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${GCC_DEFAULT} is an additional change. (The specifics would not automatically track potential future USE_GCC= use from what I can tell. I'm not aware of a technique to get general automatic rpath tracking. I had hoped someone would know a way to do so. Otherwise the Makefile content is easy to end up mismatched. This applies to more than EDK2.) I'll need to synchronize my ports environment to have a context to deal with setting up a tested patch based on GCC_DEFAULT. So it may be a while.
(In reply to Lorenzo Salvadore from comment #19) For avoiding the aarch64 /lib/libgcc_s.so.1 issue for sysutils/edk2, see: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266404