[Xen-devel] Two linkers - EFI one (mingw64) and normal GNU one [Fedora]

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

Hey,

Fedora for the longest time seems to have two linkers - one normal for GNU
applications and then another - mingw64 - for building EFI applications.

Which means that to compile ELF binaries on Fedora requires this patch
(taken from Fedora build):

From 078f2d6155e940a91c1f668b86dcb9534d76b8b7 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Wed, 6 Jan 2016 16:39:23 -0500
Subject: [PATCH] EFI build using mingw

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>

Conflicts:
        xen/arch/x86/Makefile
---
 xen/Makefile              | 2 ++
 xen/arch/x86/Makefile     | 6 +++---
 xen/arch/x86/efi/Makefile | 2 +-
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/xen/Makefile b/xen/Makefile
index f702525..09c708c 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -20,6 +20,8 @@ export XEN_ROOT := $(BASEDIR)/..
 MAKEFLAGS += -rR
 
 EFI_MOUNTPOINT ?= $(BOOT_DIR)/efi
+EFI_VENDOR=fedora
+LD_EFI ?= $(LD)
 
 ARCH=$(XEN_TARGET_ARCH)
 SRCARCH=$(shell echo $(ARCH) | sed -e 's/x86.*/x86/' -e 
s'/arm\(32\|64\)/arm/g')
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 5f7c57e..e010fa0 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -160,20 +160,20 @@ endif
 
 $(TARGET).efi: prelink-efi.o efi.lds efi/relocs-dummy.o 
$(BASEDIR)/common/symbols-dummy.o efi/mkreloc
        $(foreach base, $(VIRT_BASE) $(ALT_BASE), \
-                 $(guard) $(LD) $(call EFI_LDFLAGS,$(base)) -T efi.lds -N $< 
efi/relocs-dummy.o \
+                 $(guard) $(LD_EFI) $(call EFI_LDFLAGS,$(base)) -T efi.lds -N 
$< efi/relocs-dummy.o \
                        $(BASEDIR)/common/symbols-dummy.o -o 
$(@D)/.$(@F).$(base).0 &&) :
        $(guard) efi/mkreloc $(foreach base,$(VIRT_BASE) 
$(ALT_BASE),$(@D)/.$(@F).$(base).0) >$(@D)/.$(@F).0r.S
        $(guard) $(NM) -pa --format=sysv $(@D)/.$(@F).$(VIRT_BASE).0 \
                | $(guard) $(BASEDIR)/tools/symbols --sysv --sort 
>$(@D)/.$(@F).0s.S
        $(guard) $(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0r.o 
$(@D)/.$(@F).0s.o
        $(foreach base, $(VIRT_BASE) $(ALT_BASE), \
-                 $(guard) $(LD) $(call EFI_LDFLAGS,$(base)) -T efi.lds -N $< \
+                 $(guard) $(LD_EFI) $(call EFI_LDFLAGS,$(base)) -T efi.lds -N 
$< \
                        $(@D)/.$(@F).0r.o $(@D)/.$(@F).0s.o -o 
$(@D)/.$(@F).$(base).1 &&) :
        $(guard) efi/mkreloc $(foreach base,$(VIRT_BASE) 
$(ALT_BASE),$(@D)/.$(@F).$(base).1) >$(@D)/.$(@F).1r.S
        $(guard) $(NM) -pa --format=sysv $(@D)/.$(@F).$(VIRT_BASE).1 \
                | $(guard) $(BASEDIR)/tools/symbols --sysv --sort 
>$(@D)/.$(@F).1s.S
        $(guard) $(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1r.o 
$(@D)/.$(@F).1s.o
-       $(guard) $(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T efi.lds -N $< \
+       $(guard) $(LD_EFI) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T efi.lds -N $< \
                        $(@D)/.$(@F).1r.o $(@D)/.$(@F).1s.o $(build_id_file) -o 
$@
        if $(guard) false; then rm -f $@; echo 'EFI support disabled'; fi
        rm -f $(@D)/.$(@F).[0-9]*
diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
index 5099430..a6dae4c 100644
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -6,7 +6,7 @@ create = test -e $(1) || touch -t 199901010000 $(1)
 
 efi := y$(shell rm -f disabled)
 efi := $(if $(efi),$(shell $(CC) $(filter-out $(CFLAGS-y) .%.d,$(CFLAGS)) -c 
check.c 2>disabled && echo y))
-efi := $(if $(efi),$(shell $(LD) -mi386pep --subsystem=10 -o check.efi check.o 
2>disabled && echo y))
+efi := $(if $(efi),$(shell $(LD_EFI) -mi386pep --subsystem=10 -o check.efi 
check.o 2>disabled && echo y))
 efi := $(if $(efi),$(shell rm disabled)y,$(shell $(call create,boot.init.o); 
$(call create,runtime.o)))
 
 extra-$(efi) += boot.init.o relocs-dummy.o runtime.o compat.o
-- 
2.1.0


Which is not very nice.

I was thinking that we could augment configure.ac to detect for this and if so, 
well here I am
not sure. The final step is that this:

LD_EFI=/usr/x86_64-w64-mingw32/bin/ld

exists. Usually the configure.ac ends up jamming those in tools/config.h as 
this:

#define QEMU_XEN_PATH "/usr/lib/xen/bin/qemu-system-i386"


But that is 'tools', and not 'xen'.

Would it be OK if the configure.ac jammed an config.h in 'xen' directory? But 
then somehow
the Config.mk has to read this and figure this out? Which is kind of hackish.


Or should I just attempt at making the Config.mk have these exact same checks 
that can be evaluated?


Preferences?

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel