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:
> On 2016-06-16 10:14:50, Bill Paul wrote: > > Of all the gin joints in all the towns in all the world, Jordan Justen > > had to > > > > walk into mine at 09:37:31 on Thursday 16 June 2016 and say: > > > On 2016-06-16 09:19:41, Bill Paul wrote: > > > > Of all the gin joints in all the towns in all the world, Jordan > > > > Justen had to > > > > > > > > walk into mine at 18:11:27 on Wednesday 15 June 2016 and say: > > > > > Can you use git send-email rather than KMail to send your patches, > > > > > so they will be threaded? > > > > > > > > You know, I spent about 10 minutes looking over my patches trying to > > > > think of there was *anything* I'd forgotten to do that someone might > > > > nitpick me over and for once I thought I'd gotten everything right. I > > > > guess should have known better. > > > > > > > > No, actually, I can't use git send-email. I only have one machine > > > > that's setup to send e-mail and it's not the one I used for > > > > development. > > > > > > Yeah. I've had a similar situation with some temp dev machines. Two > > > things that I've used in the past are: > > > > > > 1. Push the branch to a personal git repo. Fetch it on the machine > > > > > > that can send email. Generate and send the patches. > > > > > > 2. Generate the patches, and copy them to a machine that can send the > > > > > > patches. Use git send-email to send the patches. > > > > That's fine, but are you saying I have to do one of these thing right now > > in order to get these patches accepted? > > No. I wouldn't say that. > > I don't think we should make these changes. I knew you were going to say that. > 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? I must disagree. The pieces are there, and aside from some minor bitrot, they still work. If someone wants to come along and do a full re-evaluation of this matter later, that's fine. All I want to do now is just fix the bitrot. > There's really nothing preventing you from having your own personal > tools_def config for a toolchain. The real question is whether the > toolchain is useful for a lot of people, or something we want to > officially support. > > 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. Actually the system compiler in FreeBSD is now clang, but that's precisely the point: no matter what happens to the host compiler, as long as it can bootstrap a cross-build toolchain, I'll always be able to create a working built environment for EDK2. Also, from my point of view as an embedded software developer, it's not strictly correct to use a host toolchain for building the EDK2 firmware since it's fundamentally a cross-build project. The host compiler is mainly for native applications, which EDK firmware images, drivers and applications are not. Can you sometimes use the host compiler for standalone images? Sure! FreeBSD does it to build its bootloader apps. However that's expected because FreeBSD is also self-hosting. For VxWorks on the Intel platform, we (Wind River/Intel) use ELF images, but we don't expect people to build VxWorks with the ELF GCC that comes with Linux. You might actually be able to do that (because ELF is ELF and x86 is x86) but really you're supposed to use the cross-build tool chain that comes with the SDK. This is mainly so that we know that regardless of whether they compile on Linux or on Windows, everything behaves the same way. The same source is always compiled to the same object code. Windows is the one murky case. The EFI firmware was originally developed with Microsoft compiler tools and it uses the same executable format as Windows. With the possible exception of the "NT" build case, it's still technically a cross-build. Really there are two paths here: 1) Support the OS host compiler 2) Use a cross-build compiler Each has their own benefits and detriments. Using the host compiler means that you don't need to install a separate compiler, but it creates additional support burden from the development end because there are _many_ of them and new ones keep appearing. Using a cross-build compiler forces you to install/bootstrap another compiler toolchain, but if you get it to work it provides a consistent build environment on every platform. You seem to think it's preferable to go chasing after different host compiler versions. I think it's preferable to support a cross build-toolchain. I think both of us are tilting at our own particular windmill, but I think we can do that without getting in each others way. > If we could figure out a way to deprecate toolchains, then maybe we > could also have a 'community' or 'upsupported' class of toolchains. If you want to do something "enterprisey" like that later, it can be discussed separately. Today all I want to do is FIX THE BITROT, especially given that the fix is pretty trivial. 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. -Bill > 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
