Ard: > -----邮件原件----- > 发件人: bounce+27952+64834+4905953+8761...@groups.io > <bounce+27952+64834+4905953+8761...@groups.io> 代表 Ard > Biesheuvel > 发送时间: 2020年8月31日 21:22 > 收件人: Leif Lindholm <l...@nuviainc.com>; Laszlo Ersek > <ler...@redhat.com> > 抄送: Pierre Gondois <pierre.gond...@arm.com>; devel@edk2.groups.io; > bob.c.f...@intel.com; liming....@intel.com; Tomas Pilar > <tomas.pi...@arm.com>; nd <n...@arm.com> > 主题: Re: [edk2-devel] [PATCH V2 2/2] BaseTools: Factorize GCC flags > > On 8/28/20 9:15 PM, Leif Lindholm wrote: > > On Fri, Aug 28, 2020 at 18:56:45 +0200, Laszlo Ersek wrote: > >>>> Leif, please comment! > >>> > >>> I did propose reverting it. But I asked for Ard's feedback on the > >>> reason for why we had the break in the flags-chain, in case he > >>> remembered (and he was on holiday at the time). > >>> > >>> Basically, I'm wondering whether we're better off changing this > >>> behaviour or simply nuking GCC48. > >> > >> I use GCC48 daily -- it's the system compiler on RHEL7. My laptop runs > >> RHEL7 -- I value stability above all. > > > > That explains why it's still in then :) > > > > OK, so then cleaning it up would be nice. > > > > Apologies, I had missed this discussion. > > The reason the GCC flags are defined the way the are is because the > GCC4x toolchains for x86 were completely disjoint from the UNIXGCC and > other ones that were defined for ARM and IA64. > > I agree that some cleanup would be nice, but if we are only going to > reshuffle tools_def variable assignments, I'm not sure it is worth it. > What I would like to see is a bit more structure, and some justification > why we are using all those different options, as i am not convinced they > are still needed even for GCC as far back as v4.8. > > Also, even though I understand Laszlo's point about being able to use > the RHEL 7 system compiler, using other toolchains is trivially easy > with EDK2 (this is the whole point), and mainline EDK2 is arguably a > development tree, not a stable production tree for ~5 year old firmware > builds, and so I do think we should get rid of GCC48 even before RHEL7 > goes EOL. > I have the same feeling on VS tool chain. Now, very old VS2008 tool chain is still in tools_def.txt.
> I'd even go so far as suggesting that [at some point in the not too > distant future], we rename GCC5 to GCCELFLTO (or something less > obnoxious) and phase out all the version based GCC toolchains entirely. > We might do the same for CLANG38 (the ELF based one), and depending on > whether PE/COFF linker support ever materializes for ARM, have a single > Clang+PE based toolchain as well. > This is a good idea to unify tool chain. But, the impact is big. To keep combability, GCC5 and GCCELFLTO can be defined together and share the same setting. Thanks Liming > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#64835): https://edk2.groups.io/g/devel/message/64835 Mute This Topic: https://groups.io/mt/76533871/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
