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
>
next prev parent 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).