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
