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. -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(-) > > -- > ============================================================================= > -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
