[Bug 263543] sysutils/ed2k: Fails to build with GCC 11 (all flavors)

From: <bugzilla-noreply_at_freebsd.org>
Date: Sun, 24 Apr 2022 23:44:03 UTC

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

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) =
SIZE (tianocore-edk2-v1.33-edk2-stable201903-4059-g79f2734e5a_GH0.tar.gz) =
SHA256 (tianocore-edk2-platforms-958fc02b15_GH0.tar.gz) =
SIZE (tianocore-edk2-platforms-958fc02b15_GH0.tar.gz) = 10340955
SHA256 (tianocore-edk2-non-osi-0320db9_GH0.tar.gz) =
SIZE (tianocore-edk2-non-osi-0320db9_GH0.tar.gz) = 18901823
SHA256 (openssl-openssl-OpenSSL_1_1_1j_GH0.tar.gz) =
SIZE (openssl-openssl-OpenSSL_1_1_1j_GH0.tar.gz) = 9994760
SHA256 (ucb-bar-berkeley-softfloat-3-b64af41_GH0.tar.gz) =
SIZE (ucb-bar-berkeley-softfloat-3-b64af41_GH0.tar.gz) = 148768
SHA256 (kkos-oniguruma-v6.9.4_mark1_GH0.tar.gz) =
SIZE (kkos-oniguruma-v6.9.4_mark1_GH0.tar.gz) = 592141
SHA256 (google-brotli-v1.0.9-36-gf4153a0_GH0.tar.gz) =
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

You are receiving this mail because:
You are the assignee for the bug.