Re: build failure trying to build gcc cross-compiler

[Bill Paul <wpaul@windriver.com>]

Of all the gin joints in all the towns in all the world, Shragai, Yaron had to 
walk into mine at 12:54:53 on Monday 12 December 2016 and say:

> Hello,
> I am trying to build the Tianocore source from
> https://github.com/tianocore/edk2, as per the instructions here:
> https://github.com/tianocore/tianocore.github.io/wiki/Common-instructions-
> for-Unix
> 
> I am runnin on a Virtualbox VM running Ubuntu Desktop LTS.
> 
> I get as far as the "Build gcc x64 UEFI cross compiler" section.
> The script mingw-gcc-build.py contains hardcoded references to download
> binutils and gcc. In the case of binutils, it references a version that no
> longer exists in the archive (version 2.20.51.0.5). In the case of gcc, it
> references version 4.3.0, on ftpmirror.gnu.org/gcc/, which redirects to
> other mirror sites, many of which are blocked by my firewall. I tried
> getting around this by downloaded the files myself, and commented out the
> part of the script that downloads the sources (the call to
> sources.GetAll() - lines 553-558). I downloaded binutils version
> 2.24.51.0.2, and gcc vesion 2.24.51.0.2. It appears that binutils built,
> but gcc is not building.
> Any advice?
> Is there an updated version of mingw-gcc-build.py?

I submitted a patch some time ago to fix the bitrot in cross-compiler 
toolchain case which updates the script to use GCC 4.9.3, but for reasons that 
completely baffle me, there is continued resistance to applying it. The 
preference seems to be to use a native compiler instead. This works if you 
intend to do an IA32 or X64 build and you have an IA32/X64 host system and 
saves you the time/trouble of setting up a cross-build toolchain. However I 
continue to maintain that using a cross-compiler is technically the better 
solution, especially for OSes other than Windows where the native executable 
format is not PE/COFF.

The patches I created at least make using the cross-compiler build an option 
again. I uploaded my patches along with the original and modified files here:

http://people.freebsd.org/~wpaul/edk2/patch

The tools_def.template file needed some updates because the newer version of 
GCC behaves a little differently than GCC 4.3.0 did with respect to underscore 
decoration of function names. (GCC 4.3.0 didn't actually implement the 
convention correctly.) Also, the OVMF build uses a flag to enforce alignment 
which the newer version of GNU ld doesn't support. (The flags for PE/COFF 
binaries are different from those for ELF binaries.)

Note that while this fixes the script to build a newer version of GCC, that 
alone may not correct your problem: it's hard to say because you didn't show 
us the log file containing the actual build error. Building GCC requires 
libmpfr and libgmp to be present, along with their associated header files. 
With many Linux distributions, simply installing the library packages is not 
enough: that just gives you the shared library, but omits the header files 
that go with it. For those you usually need to install a "devel" package.

I have used these patches to successfully build a cross-compile toolchain and 
OVMF images on my FreeBSD host system. I also have some (now-stale) 
instructions for how I did the build at:

http://people.freebsd.org/~wpaul/edk2/README.txt

It's possible the tools_def.template and OVMF build files have changed since I 
created this patch, so you may have to apply some of the changes manually. 
They are pretty straightforward though. Standard disclaimers apply. If it 
breaks, you get to keep both pieces.

-Bill

> Extracting ./src/gcc-4.3.0.tar.bz2:
> Extracting ./src/binutils-2.24.51.0.2.tar.bz2:
> binutils [config] ... [done]
> binutils [build] ... [done]
> binutils [install] ... [done]
> binutils module is now built and installed
> gcc [config] ... [done]
> gcc [build] ... [failed!]
> Traceback (most recent call last):
>   File "./mingw-gcc-build.py", line 564, in <module>
>     App()
>   File "./mingw-gcc-build.py", line 562, in __init__
>     Builder(sources, config).Build()
>   File "./mingw-gcc-build.py", line 426, in Build
>     self.BuildModule('gcc')
>   File "./mingw-gcc-build.py", line 473, in BuildModule
>     self.RunCommand(cmd, module, 'build')
>   File "./mingw-gcc-build.py", line 511, in RunCommand
>     'See output log at %s' % self.config.Relative(logFile)
> Exception: Failed to build gcc
> See output log at ./build/log.txt
> 
> Thanks,
> Yaron Shragai
> yshragai@draper.com
> 
>   ________________________________
> Notice: This email and any attachments may contain proprietary (Draper
> non-public) and/or export-controlled information of Draper. If you are not
> the intended recipient of this email, please immediately notify the sender
> by replying to this email and immediately destroy all copies of this
> email. ________________________________
> _______________________________________________
> 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,
                 wpaul@windriver.com | Master of Unix-Fu - Wind River Systems
=============================================================================
   "I put a dollar in a change machine. Nothing changed." - George Carlin
=============================================================================