Of all the gin joints in all the towns in all the world, Jordan Justen had to walk into mine at 16:46:07 on Thursday 16 June 2016 and say:
> On 2016-06-16 16:11:34, Bill Paul wrote: > > 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: > > > > 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. > > Yeah, so build the one that is better supported and tested for EDK II. I've already made it clear that I'm willing to shoulder the burden of using the cross-build toolchain even if it's not considered officially supported. I know that if it breaks I get to keep both pieces. > Relatedly ... If Steven gets clang working for EDK II, will you > consider using that toolchain instead? That seems like a toolchain for > EDK II that actually might have a future. a) Getting _which_ clang working? If you still mean host-based versions of clang instead of a cross-build target that I can bootstrap anywhere, then I've already explained why I'm against that. b) Why not have both since the only thing needed to make UNIXGCC work again is to FIX THE BITROT. c) I've already got a patch to fix UNIXGCC now. Why should have to wait until later? (I always waited almost a year for someone to fix UNIXGCC.) If you can add a clang cross-compiler option instead of the GNU option that's great, but until then, why not have a temporary stop-gap? > > > > 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."] > > No, I did not. UNIXGCC is an ancient GCC (4.3) MinGW toolchain. Which > nobody uses. But they can use a newer version. (Like I do.) > And nobody tests. And probably doesn't build. But for > some readon we can't deprecate it. I think that's a misinterpretation. It occurred to on the way home from work yesterday that what you were trying to say was that the UNIXGCC toolchain option is tied to GCC 4.3. It's more accurate to say that UNIXGCC is to the MinGW compiler generated by the mingw-build.py script. I don't think there's anything written down anywhere that says that script can't be updated to use a newer version of GCC. You may be inferring that it's stuck at that version forever because nobody has taken the time to fix it, but I don't think anyone else is saying that's the case, and there's no documentation that I can find to support that position. The instructions for using the cross-build option are here: https://github.com/tianocore/tianocore.github.io/wiki/Unix-like-systems (And on a few descendant pages.) It says it uses the MinGW compiler. It doesn't specify exactly which version nor say that it will always be pegged at the same version forever. So please, I implore you: stop trying to make it sound that way. > I assumed that the script no longer managed to build MinGW GCC 4.3, > but maybe it still works... Yes, it still does build a working GCC 4.3. But you can't use GCC 4.3 anymore. Also, it could be arguably considered a bug to have it use that version. The 4.3 MinGW target assumes you have to use underscore decoration for both IA32 and X64 targets. That's actually wrong (and the wrongness was perpetuated in the tools_def file too -- that's something else that I fixed). Newer versions fix that (it only applies to IA32). And as I said, there is nothing written in stone that says the script can't be updated to use a newer version of GCC. And doing that took barely more than just changing the download paths and MD5 sums. It was not rocket science. No animals were harmed. > > > 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. > > Or, you can try to build ELF GCC 4.9 and then try GCC49 to see if it > can also work for you. You're going in circles. I explained already: 1) I don't want to use a host compiler for what is fundamentally a cross-build target. 2) It makes no sense for me to replace my host compiler (which may be tightly integrated with my host environment and work perfectly well for its intended use) 3) I could build a "x86-none-elf" cross-build compiler instead, but I'm basically trying to do that anyway. And if I have to choose between a toolchain that generates ELF binaries which I then have to convert to PE/COFF versus a toolchain that produces PE/COFF binaries in the first place, I'd rather have the latter. And none of that matters anyway because it has nothing to do with my actual goal here which is just to FIX THE BITROT. I still maintain there is no technical reason not to just fix the UNIXGCC build option and let people use it if they happen to find it convenient, especially since the fix is pretty simple _and_ I've already done the work. In spite of your protestations, it will not make your life harder, there will not be any human sacrifices, dogs and cats living together or mass hysteria. There will just be a few more people getting stuff done with this wonderful project. -Bill -- ============================================================================= -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
