xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, Doug Goldstein <cardoe@cardoe.com>
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, m.a.young@durham.ac.uk,
	xen-devel <xen-devel@lists.xenproject.org>,
	ian.jackson@citrix.com
Subject: Re: Two linkers - EFI one (mingw64) and normal GNU one [Fedora]
Date: Mon, 15 Feb 2016 09:26:16 -0500	[thread overview]
Message-ID: <20160215142616.GE3698@char.us.oracle.com> (raw)
In-Reply-To: <56C1A94D02000078000D1F96@prv-mh.provo.novell.com>

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
> 

  reply	other threads:[~2016-02-15 14:26 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-12 17:19 Two linkers - EFI one (mingw64) and normal GNU one [Fedora] Konrad Rzeszutek Wilk
2016-02-12 17:52 ` Ian Jackson
2016-02-12 22:17 ` Doug Goldstein
2016-02-13  0:23   ` Konrad Rzeszutek Wilk
2016-02-15  9:32 ` Jan Beulich
2016-02-15 14:26   ` Konrad Rzeszutek Wilk [this message]
2016-02-15 15:01     ` Doug Goldstein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160215142616.GE3698@char.us.oracle.com \
    --to=konrad.wilk@oracle.com \
    --cc=JBeulich@suse.com \
    --cc=cardoe@cardoe.com \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@citrix.com \
    --cc=m.a.young@durham.ac.uk \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).