On 17 August 2015 at 20:53, Jordan Justen <jordan.l.jus...@intel.com> wrote:
> On 2015-08-17 11:25:56, Ard Biesheuvel wrote:
>> On 17 August 2015 at 20:22, Jordan Justen <jordan.l.jus...@intel.com> wrote:
>> > Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead?
>> >
>> > I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to be
>> > based on GCC 4.9 rather than 4.3. I think GCC 4.3 was implicitly part
>> > of the definition of the UNIXGCC toolchain. (Well, maybe explicitly if
>> > you count the comment in tools_def :) This is why I'd rather deprecate
>> > it as a toolchain, and use the GCC4X toolchains instead.
>> >
>> No, you can't really.
>> MinGW generates PE/COFF not ELF, so much of the linker command line is
>> different, and it really deserves a toolchain of its own
> Why does it deserve a toolchain of its own if the other toolchain
> produces better code? Why should EDK II care about using the different
> linker path if it isn't the best recommended way to build images?

By the same logic, why on earth do we insist on retaining support for
GCC44 and GCC45?

Note that it is not about the linker path, but about the options that
we pass, for instance to get 4 KB section alignment. MinGW does not
need a linker script for this, you can simply set --section-alignment
and --file-alignment on the command line.

As for the PE/COFF support: if you are incorporating PE/COFF binary
static libraries into your build, you need a native PE/COFF toolchain.
But in general, I think the ELF to PE/COFF conversion is not the most
elegant step in the build, and I would prefer to avoid it if possible
(only, there is no PE/COFF support in the GNU tools for ARM or

>> Making version 4.3.0 part of the definition of UNIXGCC sounds awkward
>> to me. In fact, the idea of supporting all toolchains into eternity
>> sounds awkward, and it is obviously not working, since many are
>> deprecated and don't work at all or only partially. It would be much
>> better imo to allow a definition like UNIXGCC to evolve with the state
>> of the art
> I mostly agree, but I would rather see us add new toolchains and
> deprecate the old ones rather than evolving the requirements for a
> particular toolchain.
> I think the name UNIXGCC is too generic and too short sighted. It made
> sense at the time, but I don't think we should keep moving it forward
> and turn it into a moving target.
> The MYTOOLS toolchain was what you are describing, but for MSVC. It
> looks like it is stuck at VS2008 though. Anyway, I guess we should
> also deprecate MYTOOLS. :)

Probably, yes.
edk2-devel mailing list

Reply via email to