On 8/31/20 4:03 PM, Laszlo Ersek wrote:
On 08/31/20 15:22, Ard Biesheuvel wrote:
mainline EDK2 is arguably a development tree
I agree.
not a stable production tree for ~5 year old firmware builds
I agree with that too.
But I don't think GCC48 is "holding back" edk2. I don't know of a
firmware feature that suffers because I'd like to be able to build the
tree with GCC48.
True.
(LTO is not a firmware feature; and NOOPT builds, which are important,
don't / shouldn't enable LTO anyway.)
I do agree that maintaining the BaseTools stuff that's related to GCC48
is a burden, technically speaking. Is it a big burden? Should I attempt
to handle related issues?
Not necessarily. For obvious reasons, my mental picture of the
historical situation is more clear when it comes to ARM, and GCC48 is
the last version that uses the large code model, and which shipped with
a version of binutils that was buggy, requiring extra restrictions wrt
binary layout in GenFw) [which brings me to another GCC toolchain
versioning issue, which is that binutils is released on a separate
schedule, and the '48' in GCC48 does not clearly specify the binutils
version]
Not sure how Leif feels about this, but i wouldn't mind retaining GCC48
support only for IA32/X64. Or alternatively, make it a per-platform
decision (which it ultimately is anyway, given that every platform ships
with platform specific code that could have issues with older toolchains)
Official Software Collections / Developer Toolset add-ons exist for
RHEL7:
https://developers.redhat.com/products/developertoolset/overview
https://access.redhat.com/documentation/en-us/red_hat_developer_toolset/9/html/user_guide/chap-red_hat_developer_toolset#sect-Red_Hat_Developer_Toolset-Compatibility
I've played with them in the past. They weren't a good fit for me, as I
recall. Anyway, I can check them out again, if I must.
and so I do think we should get rid of GCC48 even before RHEL7 goes
EOL.
We might want to explore the Debian / Ubuntu status too (LTS).
Agreed. But one final remark on the distro/system toolchain situation:
distros have good reasons for sticking with a single GCC version to
build the world, but I wonder if any of them hold for UEFI builds such
as OVMF, which runs entirely in its own context, and is mangled by GenFw
so the ELF objects are never even consumed directly. So as I see it, the
*only* benefit of retaining GCC48 support is for the convenience of
developers that use 'mature' distros like RHEL 7 and prefer to use the
compiler that happens to be installed. I am not saying this is not a
good enough reason, just something we have to realize.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#64837): https://edk2.groups.io/g/devel/message/64837
Mute This Topic: https://groups.io/mt/75351533/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
