Of all the gin joints in all the towns in all the world, Jordan Justen had to walk into mine at 15:47:05 on Thursday 16 June 2016 and say:
> 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. So I either bootstrap a new host GCC or bootstrap a cross-build GCC. I have to build GCC either way. > 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. _Or_ I can just use the build script that already exists. > (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 think you meant "to build something newer than MinGW GCC 4.3."] I *did* update the mingw-gcc-build.py script. I also updated the tools_def.template to match it. It made it GCC 4.9.3 and binutils 2.25. That's why it says "make it work again" in the subject line. (Now you will tell me it's my fault you didn't notice the other patch because I used Kmail.) > 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? In this context: everyone == all the EDK2 maintainers I did not mean: everione != everybody outside Intel using EDK _I'm_ clearly not ignoring it. > If we want to add support for MinGW GCC 4.9, then I'd rather see it > called MINGWGCC49. And when you that, you're still going to have to apply the patch that I just gave you to fix the .dsc files in OVMF because _any_ MinGW build will be missing the support for the -z flag. > The UNIXGCC name is too generic. But, I still think > it is better (today) to just recommend/use GCC49. It is not _better_. It is only _different_. You personally prefer it that way. But today I don't care about that. Today I just want to FIX THE BITROT. If someone wants to rename UNIXGCC to MINGWGCC they can submit another patch to do that after the bitrot is fixed. -Bill > -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 > > > [email protected] > > > https://lists.01.org/mailman/listinfo/edk2-devel -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Member of Technical Staff, [email protected] | Master of Unix-Fu - Wind River Systems ============================================================================= "I put a dollar in a change machine. Nothing changed." - George Carlin ============================================================================= _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
