| Message ID | 20160212171908.GA10110@char.us.oracle.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Konrad Rzeszutek Wilk writes ("Two linkers - EFI one (mingw64) and normal GNU one [Fedora]"):
> 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.
Until now, hypervisor developers have maintained that it should be
possible to build the hypervisor without running configure.
Your proposal is to have configure detect this problematic situation
and automatically make it work. But that means that at least on
Fedora it will be necessary to run configure first.
So this proposal introduces new build system plumbing anomaly: there
would have to be an output from configure that is consumed by the xen
build - a thing which has been hitherto forbidden.
Personally I would be happy to relax the no-configure-for-hypervisor
rule entirely, or in this specific case.
But hypervisor developers may prefer something else.
If we do go down the route of having autoconf figure this out, it
should not be plumbed via config.h. autoconf can already generate
makefile outputs.
Probably the answer would be a xen/config.autoconf.mk.in (or some such
filename) which is turned into xen/config.autoconf.mk by configure and
"-include"d from the Xen Makefile.
Ian.
On 2/12/16 11:19 AM, Konrad Rzeszutek Wilk wrote: > 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@oracle.com> > Date: Wed, 6 Jan 2016 16:39:23 -0500 > Subject: [PATCH] EFI build using mingw > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > > 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 > +LD_EFI ?= $(LD) So I think doing this is reasonable to allow Fedora to override it. You can even do a check that LD_EFI supports i386pep as a target and skip doing the EFI build/install if it does not. Similar to the case when EFI_VENDOR is not set. I don't see what adding a configure.ac would buy you since you would have to hardcode a number of different paths to check for a linker that works because the path that Fedora uses is different from every other distro I currently have access to. The real question is why can't we change the EFI stub generation to be closer to how Linux does it which doesn't have this same constraint.
On February 12, 2016 5:17:42 PM EST, Doug Goldstein <cardoe@cardoe.com> wrote: >On 2/12/16 11:19 AM, Konrad Rzeszutek Wilk wrote: >> 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@oracle.com> >> Date: Wed, 6 Jan 2016 16:39:23 -0500 >> Subject: [PATCH] EFI build using mingw >> >> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> >> >> 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 >> +LD_EFI ?= $(LD) > >So I think doing this is reasonable to allow Fedora to override it. You >can even do a check that LD_EFI supports i386pep as a target and skip >doing the EFI build/install if it does not. Similar to the case when >EFI_VENDOR is not set. > >I don't see what adding a configure.ac would buy you since you would >have to hardcode a number of different paths to check for a linker that >works because the path that Fedora uses is different from every other >distro I currently have access to. OK, which is why I was thinking of configure.ac trying different paths. > >The real question is why can't we change the EFI stub generation to be >closer to how Linux does it which doesn't have this same constraint. That is what Daniel suggested going forward. But that is a bit of further material.
>>> On 12.02.16 at 18:19, <konrad.wilk@oracle.com> wrote: > 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): This seems completely backwards: Just like we (SUSE) did, they should really configure their binutils package with --enable-targets=<arch>-pep. I absolutely cannot see why a MingW64 linker should be used to generate EFI binaries. Yes, both use the same binary container format, but beyond that there's nothing common here: EFI binaries are of no use in a MingW64 environment (afaict at least), but are nowadays an integral part of an OS installation (i.e. a Linux distro in this case). If it can be proven that Fedora folks are absolutely unwilling to do so, I could see something like what you propose as a workaround (albeit it's more like a hack), so a few comments on the patch itself: > --- a/xen/Makefile > +++ b/xen/Makefile > @@ -20,6 +20,8 @@ export XEN_ROOT := $(BASEDIR)/.. > MAKEFLAGS += -rR > > EFI_MOUNTPOINT ?= $(BOOT_DIR)/efi > +EFI_VENDOR=fedora This is a no-go. The variable specifically should only be set from outside our build environment. > +LD_EFI ?= $(LD) Why couldn't you just probe the binary location(s) you know about here? But in any case this would perhaps need better integration with the checking done in xen/arch/x86/efi/Makefile. Jan
On Mon, Feb 15, 2016 at 02:32:45AM -0700, Jan Beulich wrote: > >>> On 12.02.16 at 18:19, <konrad.wilk@oracle.com> wrote: > > 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): > > This seems completely backwards: Just like we (SUSE) did, they > should really configure their binutils package with > --enable-targets=<arch>-pep. I absolutely cannot see why a > MingW64 linker should be used to generate EFI binaries. Yes, > both use the same binary container format, but beyond that > there's nothing common here: EFI binaries are of no use in a > MingW64 environment (afaict at least), but are nowadays an > integral part of an OS installation (i.e. a Linux distro in this case). It has been like this for the last couple of releases. MA Young has been CC-ed on this thread so hopefully he has some idea of why it was choosen this way. > > If it can be proven that Fedora folks are absolutely unwilling to > do so, I could see something like what you propose as a > workaround (albeit it's more like a hack), so a few comments on > the patch itself: > > > --- a/xen/Makefile > > +++ b/xen/Makefile > > @@ -20,6 +20,8 @@ export XEN_ROOT := $(BASEDIR)/.. > > MAKEFLAGS += -rR > > > > EFI_MOUNTPOINT ?= $(BOOT_DIR)/efi > > +EFI_VENDOR=fedora > > This is a no-go. The variable specifically should only be set from > outside our build environment. Right. > > > +LD_EFI ?= $(LD) > > Why couldn't you just probe the binary location(s) you know about > here? But in any case this would perhaps need better integration > with the checking done in xen/arch/x86/efi/Makefile. <nods> I can certainly do that. Doug, does Gentoo have it in some other locations? > > Jan >
On 2/15/16 8:26 AM, Konrad Rzeszutek Wilk wrote: > On Mon, Feb 15, 2016 at 02:32:45AM -0700, Jan Beulich wrote: >>>>> On 12.02.16 at 18:19, <konrad.wilk@oracle.com> wrote: >>> 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): >> >> This seems completely backwards: Just like we (SUSE) did, they >> should really configure their binutils package with >> --enable-targets=<arch>-pep. I absolutely cannot see why a >> MingW64 linker should be used to generate EFI binaries. Yes, >> both use the same binary container format, but beyond that >> there's nothing common here: EFI binaries are of no use in a >> MingW64 environment (afaict at least), but are nowadays an >> integral part of an OS installation (i.e. a Linux distro in this case). >> >>> +LD_EFI ?= $(LD) >> >> Why couldn't you just probe the binary location(s) you know about >> here? But in any case this would perhaps need better integration >> with the checking done in xen/arch/x86/efi/Makefile. > > <nods> > I can certainly do that. > > Doug, does Gentoo have it in some other locations? >> >> Jan >> Gentoo does --enable-targets=<arch>-pep so our default ld can generate EFI binaries.
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