paolo or laszlo, do you know what's required to cross compile here? I tried

cd edk2-r14365
source ./edksetup.sh
make CC=x86_64-linux-gnu-gcc -C $WORKSPACE/BaseTools

x86_64-linux-gnu-gcc  -c -MD -fshort-wchar -fno-strict-aliasing -fno-merge-constants -nostdlib -Wall -Werror -c -g  -I .. -I ../Include/Common -I ../Include/ -I ../Include/IndustryStandard -I ../Common/ -I .. -I . -I ../Include/X64/  BasePeCoff.c -o BasePeCoff.o
In file included from ../Include/X64/ProcessorBind.h:130:0,
                 from ../Include/Common/BaseTypes.h:25,
                 from ../Include/Common/UefiBaseTypes.h:21,
                 from BasePeCoff.c:16:
/usr/lib/gcc/x86_64-linux-gnu/4.7.2/include/stdint.h:3:26: fatal error: stdint.h: No such file or directory

CC=gcc (the default) works fine and continues on:

gcc  -c -MD -fshort-wchar -fno-strict-aliasing -fno-merge-constants -nostdlib -Wall -Werror -c -g  -I .. -I ../Include/Common -I ../Include/ -I ../Include/IndustryStandard -I ../Common/ -I .. -I . -I ../Include/X64/  BasePeCoff.c -o BasePeCoff.o
gcc  -c -MD -fshort-wchar -fno-strict-aliasing -fno-merge-constants -nostdlib -Wall -Werror -c -g  -I .. -I ../Include/Common -I ../Include/ -I ../Include/IndustryStandard -I ../Common/ -I .. -I . -I ../Include/X64/  BinderFuncs.c -o BinderFuncs.o

Apologies, the logs in comment 0 are gone, and I don't understand the problem. Can you tell me more about it? What is the reason for cross-compiling?

In any case the gcc command line is identical between the failing and the succeeding case. "BaseTools/Source/C/Include/X64/ProcessorBind.h" seems to include <stdint.h> simply. What does "/usr/lib/gcc/x86_64-linux-gnu/4.7.2/include/stdint.h" contain? Are we sure this isn't a toolchain installation error?

Thanks

I submitted a scratch build for the f20-rebuild target, arch-override armv7hl:

http://koji.fedoraproject.org/koji/taskinfo?taskID=5836570

It failed with:

  make: Entering directory `/builddir/build/BUILD/edk2-r14365/BaseTools'
  make -C Source/C
  Attempting to detect ARCH from 'uname -m': armv7l
  Could not detected ARCH from uname results
  [...]
  GNUmakefile:30: *** ARCH is not defined!.  Stop.

The basetools makefile (BaseTools/Source/C/GNUmakefile) wants to know about the target ARCH it is building for. It has simple detection with uname -m for X64 and IA32, other arches are not recognized.

The TianoCore wiki explains "How to build UEFI for the BeagleBoard":

http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=BeagleBoardPkg#How_to_build_UEFI_for_the_BeagleBoard

In particular, the following toolchains are supported by BaseTools:

http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=ArmPkg/Toolchain

$ cat /usr/lib/gcc/x86_64-linux-gnu/4.7.2/include/stdint.h#ifndef _GCC_WRAP_STDINT_H
#if __STDC_HOSTED__
# include_next <stdint.h>
#else
# include "stdint-gcc.h"
#endif
#define _GCC_WRAP_STDINT_H
#endif

We cross compile seabios, sgabios, and openbios without issue, so the infrastructure isn't completely broken in all cases.

Logs from the last failure, an issue actually came from i686:

http://koji.fedoraproject.org/koji/taskinfo?taskID=5834440

I'm actually a little confused about paolo's suggestion to cross compile now. If we were building OVMF it makes sense, but right now we are just shipping tools. Are all of these run in the guest context, x86 only? Or are some/all run on the host?

(In reply to Cole Robinson from comment #4)

> We cross compile seabios, sgabios, and openbios without issue, so the
> infrastructure isn't completely broken in all cases.
> 
> Logs from the last failure, an issue actually came from i686:
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=5834440

That's actually an understandable error, see <http://koji.fedoraproject.org/koji/getfile?taskID=5834440&name=build.log&offset=-4000>:

    Architecture(s)  = X64
    Build target     = RELEASE
    Toolchain        = GCC46

The koji task says "Arch: i686", but the edk2 build tools were configured for Architecture = X64.

I think this bug is due to Kay's patch for bug 998638 -- it starts

  build -a X64 -b RELEASE -p ShellPkg/ShellPkg.dsc -t GCC46

which is wrong on i686. (See also bug 998638 comment 2.)


> I'm actually a little confused about paolo's suggestion to cross compile
> now. If we were building OVMF it makes sense,

(Not really, as OVMF itself supports nothing but IA32 and X64.)


> but right now we are just
> shipping tools. Are all of these run in the guest context, x86 only? Or are
> some/all run on the host?

This is a mess, of course.

- The build failure in task 5711658 (comment 0) and my repro (task 5836570, comment 3) are genuine. They are not gcc errors or anything like that; the BuildTools bail out on purpose (missing environment variable, and autodetection fails).

- The make command with the CC macro override in comment 1 is not useful. We should actually ignore the errors it reports.


(1) BaseTools is a set of python and C and C++ utilities that must be first built on the host.

(2) These utilities then parse the edk2 DSC/FDF/INF files, and build UEFI code for the target platform, using the (cross) compiler installed on the host.

We don't care about step (2) for now, we just want to build (1). However the "configure" phase of (1) apparently (1a) requires the cross compiler to be present, or at least (1b) needs to be *told* what cross compiler to use in step (2).

(1a) the cross compilers in question are listed in <http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=ArmPkg/Toolchain>.

(1b) Open the other link in comment 3: <http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=BeagleBoardPkg#How_to_build_UEFI_for_the_BeagleBoard>.

It explains:
- install uuid-dev
- get the edk2 tree
- get the toolchain
  (for us, this is either ARMGCC or ARMLINUXGCC, or whatever x86_64-to-arm
  cross compiler Fedora uses),
- [snip]
- run "BeagleBoardPkg/build.sh"

Now "BeagleBoardPkg/build.sh" is important:
(i) it sources "edksetup.sh",
(ii) it configures the TARGET_TOOLS environment variable (which is where ARMGCC or ARMLINUXGCC must be available on the host),
(iii) and *then* runs 'make -C $EDK_TOOLS_PATH', which builds the BaseTools.

This way the BuildTools "configure" phase (1) will know what "inferior" compiler to use.


So, I think we don't want to cross-compile the tools themselves -- instead, we must configure/build them on the host so that they cross-compile UEFI code later on.

I'll ask on edk2-buildtools and CC you (and Jon Masters).

Plus, I'm not sure if BuildTools themselves can actually be built on ARM, as a host platform. If not, then the "armv7hl" koji target arch doesn't make any sense, and must be disabled.

Thread starts here:
http://thread.gmane.org/gmane.comp.bios.tianocore.buildtools.devel/173

Created attachment 789140 [details]
make build and file names arch dependent

Here is a patch that might make the IA32 build working, I tested it
only locally on x86_64.

It also disabled the ARM build for now, ARM would need more work, if
it should be supported.

Thanks!

I think the patch is good.

(Except perhaps the change to %description isn't complete -- we should probably mention that the package only contains build tools and the UEFI shell.)

Oh, it's only the description for the sources, no normal user will ever
see that, as only the sub-packages contain files and will be installed,
right?

Fine by me, if Cole doesn't mind it :)

It would be nice for us to build arm and x86 versions of edk2

Hi Dennis,

I'm trying to figure out how to build just the Build Tools for ARM, not even UEFI code. See comment 7 -- no answers yet.

What we want is:

- build tools for ARM

- UEFI code for x86_64

I don't recall why building the build tools for ARM requires a cross-compiler, and the logs are gone.  Perhaps I got confused by the ARCH autodetection that Laszlo mentioned and the bug has to be split.

This is firmware meant to run with qemu-system-x86_64, and we do not need to support it on 32-bit machines.  We need to build the same firmware on all machines including ARM (hence the cross-compilation reference in the subject).  Building UEFI code for 32-bit on 32-bit machines, and on 64-bit for 64-bit machines, makes no sense for the OVMF image, even though it may make some sense for the UEFI shell.

(In reply to Paolo Bonzini from comment #14)
> What we want is:
> 
> - build tools for ARM
> 
> - UEFI code for x86_64
> 
> I don't recall why building the build tools for ARM requires a
> cross-compiler, and the logs are gone.

See comment 3 for my repro. I quoted the relevant parts of the error.

I don't even know for sure *if* building the build tools for ARM requires a cross compiler. This requirement is *implied* (but not spelled out anywhere) in the TianoCore wiki, and relied on by the "BeagleBoardPkg/build.sh" build script.

See (1b)/(ii) and (1b)/(iii) in comment 5. In a nutshell, the build tools themselves are only built after TARGET_TOOLS is configured (by finding the cross compiler).

Now the cross compiler might not be a hard dependency -- something incidental through or around the TARGET_TOOLS configuration might enable the BuildTools to build. But I don't know for sure what, and I figured people on edk2-buildtools-devel would know.

> Perhaps I got confused by the ARCH
> autodetection that Laszlo mentioned and the bug has to be split.
> 
> This is firmware meant to run with qemu-system-x86_64, and we do not need to
> support it on 32-bit machines.  We need to build the same firmware on all
> machines including ARM (hence the cross-compilation reference in the
> subject).

So, basically you want to build x86_64 UEFI code on an ARM host, right?

IOW my thinking has been reverse -- we need ARM-to-x86_64 cross compilation, correct?

I pushed Kay's second patch to rawhide/f20, building packages now. We can keep this open to track dropping the ExclusiveArch bit, and adding cross compilation.

No, Kay's patch is wrong.  Please revert it except for the ExclusiveArch bit.

The EFI shell should be in a noarch subpackage.  If Kay wants both 32-bit and 64-bit shell binaries, he should build the ShellPkg twice.  So in fact I suggest reverting both of Kay's patches.

(In reply to Paolo Bonzini from comment #14)
> What we want is:
> 
> - build tools for ARM
> 
> - UEFI code for x86_64
> 
> I don't recall why building the build tools for ARM requires a
> cross-compiler, and the logs are gone.  Perhaps I got confused by the ARCH
> autodetection that Laszlo mentioned and the bug has to be split.

It doesn't but as with many upstream projects they write their documentation assuming you cross compile arm code from a x86 machine
 
> This is firmware meant to run with qemu-system-x86_64, and we do not need to
> support it on 32-bit machines.  We need to build the same firmware on all
> machines including ARM (hence the cross-compilation reference in the
> subject).  Building UEFI code for 32-bit on 32-bit machines, and on 64-bit
> for 64-bit machines, makes no sense for the OVMF image, even though it may
> make some sense for the UEFI shell.

in this case it should be "ExclusiveArch: x86_64" with a bug filed blocking each of the arch trackers explaining the situation. id like us to offer an option of a arm build for use with qemu-system-arm but im not stuck on it.  Note Fedora only supports UEFI on x86_64 if you wanted a 32 bit version to support other OS's it wouldn't hurt. but would not be useful in testing Fedora

This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle.
Changing version to '20'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20

> in this case it should be "ExclusiveArch: x86_64" with a bug filed blocking 
> each of the arch trackers explaining the situation

No, this wouldn't work.

The package is 64-bit x86 code that runs on ARM, PowerPC, s390, even 32-bit x86 through emulation.

If we make it "ExclusiveArch: x86_64", the Koji instances for PPC and s390 will not be able to build it, and this will break the PPC and s390 qemu packages.

edk2-20130515svn14365-7.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/edk2-20130515svn14365-7.fc20

Package edk2-20130515svn14365-7.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing edk2-20130515svn14365-7.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-20957/edk2-20130515svn14365-7.fc20
then log in and leave karma (feedback).

edk2-20130515svn14365-7.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.