Date: Sun, 24 Apr 2022 23:44:03 +0000 From: bugzilla-noreply@freebsd.org To: uboot@FreeBSD.org Subject: [Bug 263543] sysutils/ed2k: Fails to build with GCC 11 (all flavors) Message-ID: <bug-263543-39090-79ZrCsV4Yg@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-263543-39090@https.bugs.freebsd.org/bugzilla/> References: <bug-263543-39090@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D263543 Mark Millard <marklmi26-fbsd@yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marklmi26-fbsd@yahoo.com --- Comment #1 from Mark Millard <marklmi26-fbsd@yahoo.com> --- 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 =3D 1650175003 SHA256 (tianocore-edk2-v1.33-edk2-stable201903-4059-g79f2734e5a_GH0.tar.gz)= =3D d27d53d02772beddfbe7dd3e7d094a6786302b076f95668645024f07b9b6431b SIZE (tianocore-edk2-v1.33-edk2-stable201903-4059-g79f2734e5a_GH0.tar.gz) = =3D 14223044 SHA256 (tianocore-edk2-platforms-958fc02b15_GH0.tar.gz) =3D f94257ab457a0344247fa79e433a14b9bb22abf5007e5507d5fc50cc76e79aac SIZE (tianocore-edk2-platforms-958fc02b15_GH0.tar.gz) =3D 10340955 SHA256 (tianocore-edk2-non-osi-0320db9_GH0.tar.gz) =3D c9b2af563d8a919b38895c649858515c71226cb24c171f3de891d72e35c2875c SIZE (tianocore-edk2-non-osi-0320db9_GH0.tar.gz) =3D 18901823 SHA256 (openssl-openssl-OpenSSL_1_1_1j_GH0.tar.gz) =3D 22d6588e4a7c5ad48fcac2fbf1d035bd43258c22a49457dad0539ded0651b4d2 SIZE (openssl-openssl-OpenSSL_1_1_1j_GH0.tar.gz) =3D 9994760 SHA256 (ucb-bar-berkeley-softfloat-3-b64af41_GH0.tar.gz) =3D f22bf52cc980b122c663f2e22f8098fa60d8e468e0095f1da58231235a6b324e SIZE (ucb-bar-berkeley-softfloat-3-b64af41_GH0.tar.gz) =3D 148768 SHA256 (kkos-oniguruma-v6.9.4_mark1_GH0.tar.gz) =3D 7f7576c926f7d4a071d594a01691c477bbb9391df250378bd5e1c003d42b4318 SIZE (kkos-oniguruma-v6.9.4_mark1_GH0.tar.gz) =3D 592141 SHA256 (google-brotli-v1.0.9-36-gf4153a0_GH0.tar.gz) =3D bd103cee96d67e4fde08989316a86309e0e5498c346d3f98efbd94bce3b7f6ba SIZE (google-brotli-v1.0.9-36-gf4153a0_GH0.tar.gz) =3D 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-263543-39090-79ZrCsV4Yg>