From: Laszlo Ersek <lersek@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>,
"Olaf Hering" <olaf@aepfle.de>
Cc: qemu-devel@nongnu.org, Igor Mammedov <imammedo@redhat.com>,
Gerd Hoffmann <kraxel@redhat.com>,
"Michael S . Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH for-4.0 v2 0/2] roms: Rename the EFIROM variable and let it be overridable
Date: Mon, 8 Apr 2019 11:02:09 +0200 [thread overview]
Message-ID: <7fde154a-4384-0233-fae5-7dc9e288ccec@redhat.com> (raw)
In-Reply-To: <20190405153314.2068-1-philmd@redhat.com>
On 04/05/19 17:33, Philippe Mathieu-Daudé wrote:
> Hi,
>
> Two trivial fixes to avoid the latest EDK2 testing series to
> cause trouble to downstream distributions (in particular if
> they have PIE enforced).
I disgree with this.
(1) In the first commit message, you say,
"The iPXE project already uses the EFIROM for a tool named 'efirom'
which is not the Intel EfiRom used by the EDK2 project".
That's wrong. For building the combined (UEFI+BIOS) iPXE oprom binaries,
the efirom tool that is invoked is *most definitely* the tool from edk2.
What changes is that we now build efirom directly from the edk2
submodule, rather than using a binary that could possibly be found on a
GNU/Linux system from another package.
This is entirely aligned with the addition of the edk2 submodule. The
source for the efirom tool is now directly available, so in a
*maintainer* build -- i.e., when you decide to rebuild iPXE binaries --
we should certainly prefer to build everything from source.
Again, this is a *maintainer* build (which also covers downstream
package builds), not end-user build. If you decide to rebuild artifacts
that are otherwise offered in binary form to end-users, you commit to
building everything from source that goes into (or is necessary for)
producing those artifacts.
In the thread "edk2 fails to compile in v4.0.0-rc2", Olaf wrote,
"It is in ovmf-tools.rpm, which comes from ovmf."
That only proves my point.
(2) For a while now, it has been possible for downstream build scripts
to inject their preferred build flags into the BaseTools build recipes
(makefiles) themselves. Please see
<https://bugzilla.redhat.com/show_bug.cgi?id=1540244>. This is the
relevant upstream commit list:
1 67983484a443 BaseTools/footer.makefile: expand BUILD_CFLAGS last
for C files too
2 03252ae287c4 BaseTools/header.makefile: remove "-c" from
BUILD_CFLAGS
3 b8a661702643 BaseTools/Source/C: split "-O2" to BUILD_OPTFLAGS
4 b0ca5dae78ff BaseTools/Source/C: take EXTRA_OPTFLAGS from the
caller
5 81502cee20ac BaseTools/Source/C: take EXTRA_LDFLAGS from the caller
6 aa4e0df1f0c7 BaseTools/VfrCompile: honor EXTRA_LDFLAGS
Build BaseTools as follows:
make -C "$EDK_TOOLS_PATH" EXTRA_OPTFLAGS="..." EXTRA_LDFLAGS="..."
If you need to inject PIC/PIE-related flags into the BaseTools
compilation/linking, please use the above facility.
I think it's pretty usual that new upstream releases (of any open source
project) bring some changes for downstream packaging scripts.
Thanks
Laszlo
WARNING: multiple messages have this Message-ID (diff)
From: Laszlo Ersek <lersek@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>,
"Olaf Hering" <olaf@aepfle.de>
Cc: Igor Mammedov <imammedo@redhat.com>,
"Michael S . Tsirkin" <mst@redhat.com>,
qemu-devel@nongnu.org, Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Qemu-devel] [PATCH for-4.0 v2 0/2] roms: Rename the EFIROM variable and let it be overridable
Date: Mon, 8 Apr 2019 11:02:09 +0200 [thread overview]
Message-ID: <7fde154a-4384-0233-fae5-7dc9e288ccec@redhat.com> (raw)
Message-ID: <20190408090209.Z1gz5cC7PmjoYWl_kIVgc0NFyi1C_HxgwVb0EgyNIsM@z> (raw)
In-Reply-To: <20190405153314.2068-1-philmd@redhat.com>
On 04/05/19 17:33, Philippe Mathieu-Daudé wrote:
> Hi,
>
> Two trivial fixes to avoid the latest EDK2 testing series to
> cause trouble to downstream distributions (in particular if
> they have PIE enforced).
I disgree with this.
(1) In the first commit message, you say,
"The iPXE project already uses the EFIROM for a tool named 'efirom'
which is not the Intel EfiRom used by the EDK2 project".
That's wrong. For building the combined (UEFI+BIOS) iPXE oprom binaries,
the efirom tool that is invoked is *most definitely* the tool from edk2.
What changes is that we now build efirom directly from the edk2
submodule, rather than using a binary that could possibly be found on a
GNU/Linux system from another package.
This is entirely aligned with the addition of the edk2 submodule. The
source for the efirom tool is now directly available, so in a
*maintainer* build -- i.e., when you decide to rebuild iPXE binaries --
we should certainly prefer to build everything from source.
Again, this is a *maintainer* build (which also covers downstream
package builds), not end-user build. If you decide to rebuild artifacts
that are otherwise offered in binary form to end-users, you commit to
building everything from source that goes into (or is necessary for)
producing those artifacts.
In the thread "edk2 fails to compile in v4.0.0-rc2", Olaf wrote,
"It is in ovmf-tools.rpm, which comes from ovmf."
That only proves my point.
(2) For a while now, it has been possible for downstream build scripts
to inject their preferred build flags into the BaseTools build recipes
(makefiles) themselves. Please see
<https://bugzilla.redhat.com/show_bug.cgi?id=1540244>. This is the
relevant upstream commit list:
1 67983484a443 BaseTools/footer.makefile: expand BUILD_CFLAGS last
for C files too
2 03252ae287c4 BaseTools/header.makefile: remove "-c" from
BUILD_CFLAGS
3 b8a661702643 BaseTools/Source/C: split "-O2" to BUILD_OPTFLAGS
4 b0ca5dae78ff BaseTools/Source/C: take EXTRA_OPTFLAGS from the
caller
5 81502cee20ac BaseTools/Source/C: take EXTRA_LDFLAGS from the caller
6 aa4e0df1f0c7 BaseTools/VfrCompile: honor EXTRA_LDFLAGS
Build BaseTools as follows:
make -C "$EDK_TOOLS_PATH" EXTRA_OPTFLAGS="..." EXTRA_LDFLAGS="..."
If you need to inject PIC/PIE-related flags into the BaseTools
compilation/linking, please use the above facility.
I think it's pretty usual that new upstream releases (of any open source
project) bring some changes for downstream packaging scripts.
Thanks
Laszlo
next prev parent reply other threads:[~2019-04-08 9:10 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-05 15:33 [Qemu-devel] [PATCH for-4.0 v2 0/2] roms: Rename the EFIROM variable and let it be overridable Philippe Mathieu-Daudé
2019-04-05 15:33 ` Philippe Mathieu-Daudé
2019-04-05 15:33 ` [Qemu-devel] [PATCH for-4.0 v2 1/2] roms: Rename the EFIROM variable to avoid clashing with iPXE Philippe Mathieu-Daudé
2019-04-05 15:33 ` Philippe Mathieu-Daudé
2019-04-08 10:54 ` Laszlo Ersek
2019-04-08 10:54 ` Laszlo Ersek
2019-04-05 15:33 ` [Qemu-devel] [PATCH for-4.0 v2 2/2] roms: Allow the EDK2_EFIROM variable to be overridden Philippe Mathieu-Daudé
2019-04-05 15:33 ` Philippe Mathieu-Daudé
2019-04-08 11:05 ` Laszlo Ersek
2019-04-08 11:05 ` Laszlo Ersek
2019-04-10 6:25 ` Olaf Hering
2019-04-10 6:25 ` Olaf Hering
2019-04-10 14:54 ` Laszlo Ersek
2019-04-10 14:54 ` Laszlo Ersek
2019-04-08 9:02 ` Laszlo Ersek [this message]
2019-04-08 9:02 ` [Qemu-devel] [PATCH for-4.0 v2 0/2] roms: Rename the EFIROM variable and let it be overridable Laszlo Ersek
2019-04-08 9:20 ` Laszlo Ersek
2019-04-08 9:20 ` Laszlo Ersek
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=7fde154a-4384-0233-fae5-7dc9e288ccec@redhat.com \
--to=lersek@redhat.com \
--cc=imammedo@redhat.com \
--cc=kraxel@redhat.com \
--cc=mst@redhat.com \
--cc=olaf@aepfle.de \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.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).