On 2016-06-16 14:11:01, Bill Paul wrote: > Of all the gin joints in all the towns in all the world, Jordan Justen had to > walk into mine at 12:54:33 on Thursday 16 June 2016 and say: > > Rather than promoting > > usage of mingw based toolchains, I think we should deprecate them > > altogether. They are not recommended toolchains for EDK II, and I > > think they only cause confusion. > > Because building EDK2/OVMF is already so simple otherwise? >
Actually, it is, assuming your system GCC is new enough. This is why it is commonly used, and is the most tested (on Linux). > > > > I'm still not sure what is preventing you from using GCC49. Last time > > this came up, I don't think you answered why. David had a half-way > > decent reason for using a mingw based toolchain, but I personally > > don't think it was good enough to keep a separate toolchain in > > tools_def.template. > > I did explain why, though fairness it was a while ago so permit me to > reiterate: the expectation is to use the host GCC toolchain to do builds, and > the particular system I chose to use (FreeBSD 9.1), had a host GCC and > binutils that wasn't quite up to the task. However it was perfectly capable > of > bootstrapping a cross compiler. > > So I did that and it worked great. It was certainly less hassle that > upgrading > the system compiler. <snip> > Really there are two paths here: > > 1) Support the OS host compiler > 2) Use a cross-build compiler > You can also just build and install GCC 4.9 under your home dir, or another location that doesn't take over the system GCC. If you make a dir, and then symlink ar, gcc and ld to your ELF GCC 4.9 build, then you can set the GCC49_BIN environment variable to point at that directory which will then allow EDK II to build with the GCC49 toolchain. (At least this worked well for me in the past on some of our build pool machines.) > > Today all I want to do is FIX THE BITROT, especially given that the fix is > pretty trivial. > UNIXGCC is MinGW GCC 4.3, so fixing the bitrot would mean updating the script to allow it to build MinGW GCC 4.3. I'd rather see us finally admit that UNIXGCC is dead, and remove it than see someone update the script to build it. I've tried to get both ELFGCC and UNIXGCC deprecated. I think the only thing that has happened is that we have stopped testing those toolchains, and instead GCC4* is tested. > You don't have to "support" it. But since it's there and since I've explained > that in spite of your perspective it has merit, why don't we just clean it up > a little until someone comes up with a better idea. Apparently everyone was > content to ignore the UNIXGCC toolchain before; you're certainly free to go > back to doing that again after applying the patches. > So 'everyone' is ignoring it, but we need it updated in our tools_def.template? If we want to add support for MinGW GCC 4.9, then I'd rather see it called MINGWGCC49. The UNIXGCC name is too generic. But, I still think it is better (today) to just recommend/use GCC49. -Jordan > > > Maybe tools_def.template gets split into tools_def.supported, > > tools_def.deprecated, and tools_def.community. Or, maybe we could have > > tools_def.MINGWGCC49, and make it very clear in the comments what > > level of support the toolchain has. > > > > -Jordan > > > > > > > > On 2016-06-15 16:36:12, Bill Paul wrote: > > > > > > > A while ago there was some talk of updating the UNIXGCC toolchain > > > > > > > to support a newer version of GCC and binutils. Unfortunately > > > > > > > after almost a year, nothing has happened. (I think Ard > > > > > > > Biesheuvel said he had plans to fix this, but apparently nothing > > > > > > > came of this.) In fact things have gotten slightly worse. > > > > > > > > > > > > > > I've listened to all the various opinions about keeping the > > > > > > > UNIXGCC toolchain option around, but I still think it's useful, > > > > > > > and the fixes to update it and make it work again are small, so > > > > > > > I'm hoping there won't be tremendous resistance them. > > > > > > > > > > > > I don't think we should 'upgrade' UNIXGCC. Instead, I think we > > > > > > should deprecate it. I think a better idea would be a MINGWGCC49 > > > > > > toolchain, but even then, I don't think it is worth-while to > > > > > > maintain a separate mingw gcc based toolchain. > > > > > > > > > > > > Any reason that you can't use an elf based GCC 4.9 with the GCC49 > > > > > > toolchain? This is the best supported toolchain for (non OS X) > > > > > > unix-like environments. > > > > > > > > > > > > -Jordan > > > > > > > > > > > > > This patch set updates the mingw-gcc-build.py script to use GCC > > > > > > > 4.9.3 and binutils 2.25, and updates the rules for UNIXGCC in > > > > > > > tools_def accordingly. The only real issue that the newer > > > > > > > compiler version must not use underscore decorations for X64 > > > > > > > builds. > > > > > > > > > > > > > > Aside from fixing the build script and rules, the only problem I > > > > > > > ran into is that the -z linker option used for force 4K section > > > > > > > alignment only works ELF versions of GCC. With the MinGW linker > > > > > > > (which is targeted for PE/COFF), you need to use different > > > > > > > flags. I tried to adjust the rules to add an exception for the > > > > > > > UNIXGCC case without breaking the other cases. This should be > > > > > > > thoroughly reviewed to make sure I did it right. > > > > > > > > > > > > > > With these fixes I was able to build working IA32 and X64 release > > > > > > > images of the OVMF firmware on my FreeBSD/amd64 host. > > > > > > > > > > > > > > Bill Paul (2): > > > > > > > This commit updates the support for MinGW/UNIXGCC cross-build > > > > > > > > > > > > > > toolchain. > > > > > > > > > > > > > > This commit makes OvmfPkg builds work with UNIXGCC again. > > > > > > > > > > > > > > BaseTools/Conf/tools_def.template | 19 ++++++++++++------- > > > > > > > BaseTools/gcc/mingw-gcc-build.py | 11 +++++------ > > > > > > > OvmfPkg/OvmfPkgIa32.dsc | 3 ++- > > > > > > > OvmfPkg/OvmfPkgIa32X64.dsc | 3 ++- > > > > > > > OvmfPkg/OvmfPkgX64.dsc | 3 ++- > > > > > > > 5 files changed, 23 insertions(+), 16 deletions(-) > > > > _______________________________________________ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel > > -- > ============================================================================= > -Bill Paul (510) 749-2329 | Senior Member of Technical Staff, > wp...@windriver.com | Master of Unix-Fu - Wind River Systems > ============================================================================= > "I put a dollar in a change machine. Nothing changed." - George Carlin > ============================================================================= _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
