Of all the gin joints in all the towns in all the world, Bruce Cran had to walk into mine at 14:43:23 on Wednesday 08 July 2015 and say:
> On Wed, Jul 08, 2015 at 11:15:44AM -0700, Bill Paul wrote: > > Lastly, yesterday I actually spent some time updating the > > mingw-gcc-build.py to support binutils 2.25 and GCC 4.9.3, and I ran > > into this exact issue. > > I also spent a few minutes updating it today (to binutils 2.25 and gcc 5.1, > though 5.1.0 is way too new to be put into a changeset to be committed). When I tried GCC 5.1.0 on my FreeBSD 9.1 machine in my office, it bombed with an internal compiler error on some files. I'm not sure why this happened; the cross compiler build succeeded without error. I tried 4.8.5 and 4.9.3 and both of those worked fine, so I stuck with the latter. > Did you come across the missing objcopy symlink in > BaseTools/gcc/symlinks/{ia32,x64}? Er... no? I put my modified copies of mingw-gcc-build.py and tools_def.template at: http://people.freebsd.org/~wpaul/edk2 The problems I ran into were: 1) When building gcc, the fixincludes stage insists that there be a mingw/include directory present in the --prefix= path. This was not the case with 4.3.0, but 4.8.x and 4.9.x seem to want it. When I tried 5.1.0 it didn't seem to care about it. I modified the mingw-gcc-build.py to create this directory and that shut it up. (The directory can be empty, but it must be present.) 2) The UNIXGCC rules now need -Wno-unused-but-set-variable, for reasons already discussed. 3) The DLINK and ASLDLINK rules for X64 builds need to be changed. Currently the UNIXGCC rules use these generic GCC rules: DEFINE GCC_IA32_X64_ASLDLINK_FLAGS = DEF(GCC_IA32_X64_DLINK_COMMON) --entry _ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT) DEFINE GCC_IA32_X64_DLINK_FLAGS = DEF(GCC_IA32_X64_DLINK_COMMON) --entry _$(IMAGE_ENTRY_POINT) --file-alignment 0x20 --section-alignment 0x20 -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map Note the leading underscore before ReferenceAcpiTable and $(IMAGE_ENTRY_POINT). This rule is used for both IA32 and X64 builds (hence the name), under the assumption that both the 32-bit and 64-bit exhibit the same behavior. But the newer versions of GCC built for MinGW do _NOT_ need the leading undercore for symbol names on for the x86-64 architecture, so using these rules results in non-functional X64 images. Frustratingly, this does not cause the build to halt and catch fire to make the problem obvious. Instead the linker emits a warning and then merrily proceeds to create invalid objects, and you end up with an OVMF.fd that doesn't boot. (It took me half an hour before I figured it out.) I added X64-specific instances of these rules that do not include the underscore and switched the UNIXGCC X64 rules to use them. 4) I added -m32 and -m64 to the UNIXGCC assembler flags in a few places to match existing cases for GCC 4.9. (This change may be superfluous.) Once I did the above, I was able to build functional cross compilers and generate working OVMF images for IA32 and X64 architectures which I tested with QEMU 2.3.0. I was also able to compile working versions of the VxWorks UEFI boot loader. > I also had to add a UNIXGCC_IPF_PETOOLS_PREFIX line to tools_def.txt, and > also change ENV(WORKSPACE)/BaseTools/Bin/gcc/Ia32/ to > ENV(WORKSPACE)/BaseTools/gcc/symlinks/ia32/ (and the corresponding x64 > define). Should these changes be committed to the template, or do people > commonly have gcc in BaseTools/Bin/gcc/{Ia32,X64}? I did not do anything with the IPF platform rules. You can't build OVMF for the Itanium architecture anyway. I tend to modify the "Option 5" rules in tools_def.txt to specify my custom path to the cross-compiler toolchain. The changes I made to fix the rules for the newer version of GCC should go in the template. Changes to specify your local toolchain path should be done in your own tools_def.txt file. -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 ============================================================================= ------------------------------------------------------------------------------ Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel