On 17 August 2015 at 20:22, Jordan Justen <jordan.l.jus...@intel.com> wrote:
> On 2015-08-17 11:10:57, Bill Paul wrote:
>> Of all the gin joints in all the towns in all the world, David Woodhouse had
>> to walk into mine at 11:00:23 on Monday 17 August 2015 and say:
>> > On Mon, 2015-08-17 at 10:53 -0700, Jordan Justen wrote:
>> > > UNIXGCC and CYGGCC are GCC 4.3 & mingw based. Did this get tested?
>> > >
>> > > I think ELFGCC is unused at this point. (And has been since UnixPkg
>> > > was deprecated.)
>> > >
>> > > I think we should deprecate all three of these toolchains. I would
>> > > like to see us move them to BaseTools/Conf/tools_def.deprecated. I'll
>> > > add Larry to this email, because I think he disagrees with
>> > > deprecating
>> > > toolchains...
>> > >
>> > > If you make these changes and it breaks those toolchains, I don't
>> > > think we would be able to notice, because I don't think we test them
>> > > in our build pool anymore. To me this is all the more reason to move
>> > > them out of tools_def.template.
>> >
>> > I was building with UNIXGCC last week, to test LLP64 builds without the
>> > pain of actually having to deal with Windows.
>> >
>> > I'd rather see it updated to work with modern MinGW rather than
>> > deprecated.
>> I use UNIXGCC with the cross-compiler toolchain generated by mingw-gcc-
>> build.py. Yes, I know the existing version of the script uses GCC 4.3.0.
>> That's why I made an updated version that uses 4.9.3:
>> http://people.freebsd.org/~wpaul/edk2/mingw-gcc-build.py
>> I know you don't want to support this script, that's why I did the work for
>> you. :) Yes I've tested both IA32 and X64 builds. Yes they work fine.
>> There is value in being able to bootstrap your own cross-build toolchain on
>> whatever platform. I don't think you should be so quick to remove it.
> 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

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
edk2-devel mailing list

Reply via email to