[Qemu-devel] edk2 fails to compile in v4.0.0-rc2

[Qemu-devel] edk2 fails to compile in v4.0.0-rc2

[Olaf Hering]

[-- Attachment #1: Type: text/plain, Size: 1712 bytes --]

It seems in qemu.git#master the edk2.git submodule is now mandatory.
For me it fails to compile. This is not a new error. It needs to be compiled with -fPIC since essentially forever.

But I wonder, why does it fail to compile only for me?!
Example of failure:

 $ grep -h CommonLib.o /dev/shm/*/.build.log 
[   85s] gcc  -c  -I .. -I ../Include/Common -I ../Include/ -I ../Include/IndustryStandard -I ../Common/ -I .. -I . -I ../Include/X64/  -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-deprecated-declarations -Wno-stringop-truncation -Wno-restrict -Wno-unused-result -nostdlib -g -O2  CommonLib.c -o CommonLib.o
[   89s] ar crs ../libs/libCommon.a BasePeCoff.o BinderFuncs.o CommonLib.o Crc32.o Decompress.o EfiCompress.o EfiUtilityMsgs.o FirmwareVolumeBuffer.o FvLib.o MemoryFile.o MyAlloc.o OsPath.o ParseGuidedSectionTools.o ParseInf.o PeCoffLoaderEx.o SimpleFileParsing.o StringFuncs.o TianoCompress.o PcdValueCommon.o
[  106s] /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: ../libs/libCommon.a(CommonLib.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
[  106s] /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: ../libs/libCommon.a(CommonLib.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
[  120s] /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: ../libs/libCommon.a(CommonLib.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC

What do I need to change in my setup so that -fPIC is not required?

Olaf

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[Qemu-devel] edk2 fails to compile in v4.0.0-rc2

[Olaf Hering]

[-- Attachment #1: Type: text/plain, Size: 1712 bytes --]

It seems in qemu.git#master the edk2.git submodule is now mandatory.
For me it fails to compile. This is not a new error. It needs to be compiled with -fPIC since essentially forever.

But I wonder, why does it fail to compile only for me?!
Example of failure:

 $ grep -h CommonLib.o /dev/shm/*/.build.log 
[   85s] gcc  -c  -I .. -I ../Include/Common -I ../Include/ -I ../Include/IndustryStandard -I ../Common/ -I .. -I . -I ../Include/X64/  -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-deprecated-declarations -Wno-stringop-truncation -Wno-restrict -Wno-unused-result -nostdlib -g -O2  CommonLib.c -o CommonLib.o
[   89s] ar crs ../libs/libCommon.a BasePeCoff.o BinderFuncs.o CommonLib.o Crc32.o Decompress.o EfiCompress.o EfiUtilityMsgs.o FirmwareVolumeBuffer.o FvLib.o MemoryFile.o MyAlloc.o OsPath.o ParseGuidedSectionTools.o ParseInf.o PeCoffLoaderEx.o SimpleFileParsing.o StringFuncs.o TianoCompress.o PcdValueCommon.o
[  106s] /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: ../libs/libCommon.a(CommonLib.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
[  106s] /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: ../libs/libCommon.a(CommonLib.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
[  120s] /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: ../libs/libCommon.a(CommonLib.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC

What do I need to change in my setup so that -fPIC is not required?

Olaf

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [Qemu-devel] edk2 fails to compile in v4.0.0-rc2

[Philippe Mathieu-Daudé]

[-- Attachment #1: Type: text/plain, Size: 2184 bytes --]

Hi Olaf,

On 4/5/19 12:39 PM, Olaf Hering wrote:
> It seems in qemu.git#master the edk2.git submodule is now mandatory.

The EDK2 submodule was added for UEFI testing, you don't need to compile
it to build/use QEMU.

How did you end up compiling it?

> For me it fails to compile. This is not a new error. It needs to be compiled with -fPIC since essentially forever.
> 
> But I wonder, why does it fail to compile only for me?!
> Example of failure:
> 
>  $ grep -h CommonLib.o /dev/shm/*/.build.log 
> [   85s] gcc  -c  -I .. -I ../Include/Common -I ../Include/ -I ../Include/IndustryStandard -I ../Common/ -I .. -I . -I ../Include/X64/  -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-deprecated-declarations -Wno-stringop-truncation -Wno-restrict -Wno-unused-result -nostdlib -g -O2  CommonLib.c -o CommonLib.o
> [   89s] ar crs ../libs/libCommon.a BasePeCoff.o BinderFuncs.o CommonLib.o Crc32.o Decompress.o EfiCompress.o EfiUtilityMsgs.o FirmwareVolumeBuffer.o FvLib.o MemoryFile.o MyAlloc.o OsPath.o ParseGuidedSectionTools.o ParseInf.o PeCoffLoaderEx.o SimpleFileParsing.o StringFuncs.o TianoCompress.o PcdValueCommon.o
> [  106s] /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: ../libs/libCommon.a(CommonLib.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
> [  106s] /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: ../libs/libCommon.a(CommonLib.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
> [  120s] /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: ../libs/libCommon.a(CommonLib.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
> 
> What do I need to change in my setup so that -fPIC is not required?

Apparently your Linux distribution has transitioned to enabling PIE by
default in GCC 7, see:
https://lists.opensuse.org/opensuse-factory/2017-06/msg00403.html

"This is achieved by a gcc defaults override in the "gcc-PIE" package."

Regards,

Phil.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Qemu-devel] edk2 fails to compile in v4.0.0-rc2

[Philippe Mathieu-Daudé]

[-- Attachment #1: Type: text/plain, Size: 2184 bytes --]

Hi Olaf,

On 4/5/19 12:39 PM, Olaf Hering wrote:
> It seems in qemu.git#master the edk2.git submodule is now mandatory.

The EDK2 submodule was added for UEFI testing, you don't need to compile
it to build/use QEMU.

How did you end up compiling it?

> For me it fails to compile. This is not a new error. It needs to be compiled with -fPIC since essentially forever.
> 
> But I wonder, why does it fail to compile only for me?!
> Example of failure:
> 
>  $ grep -h CommonLib.o /dev/shm/*/.build.log 
> [   85s] gcc  -c  -I .. -I ../Include/Common -I ../Include/ -I ../Include/IndustryStandard -I ../Common/ -I .. -I . -I ../Include/X64/  -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-deprecated-declarations -Wno-stringop-truncation -Wno-restrict -Wno-unused-result -nostdlib -g -O2  CommonLib.c -o CommonLib.o
> [   89s] ar crs ../libs/libCommon.a BasePeCoff.o BinderFuncs.o CommonLib.o Crc32.o Decompress.o EfiCompress.o EfiUtilityMsgs.o FirmwareVolumeBuffer.o FvLib.o MemoryFile.o MyAlloc.o OsPath.o ParseGuidedSectionTools.o ParseInf.o PeCoffLoaderEx.o SimpleFileParsing.o StringFuncs.o TianoCompress.o PcdValueCommon.o
> [  106s] /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: ../libs/libCommon.a(CommonLib.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
> [  106s] /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: ../libs/libCommon.a(CommonLib.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
> [  120s] /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: ../libs/libCommon.a(CommonLib.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
> 
> What do I need to change in my setup so that -fPIC is not required?

Apparently your Linux distribution has transitioned to enabling PIE by
default in GCC 7, see:
https://lists.opensuse.org/opensuse-factory/2017-06/msg00403.html

"This is achieved by a gcc defaults override in the "gcc-PIE" package."

Regards,

Phil.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Qemu-devel] edk2 fails to compile in v4.0.0-rc2

[Olaf Hering]

[-- Attachment #1: Type: text/plain, Size: 423 bytes --]

Am Fri, 5 Apr 2019 12:49:15 +0200
schrieb Philippe Mathieu-Daudé <philmd@redhat.com>:

> The EDK2 submodule was added for UEFI testing, you don't need to compile
> it to build/use QEMU.
> 
> How did you end up compiling it?

The qemu.spec file has this since a very long time:
make -C roms efirom ${unrelated_settings}

This used to work still in January with c9d18c1c150c84e7a976df989ad04ddf01083f46.

Olaf

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [Qemu-devel] edk2 fails to compile in v4.0.0-rc2

[Olaf Hering]

[-- Attachment #1: Type: text/plain, Size: 423 bytes --]

Am Fri, 5 Apr 2019 12:49:15 +0200
schrieb Philippe Mathieu-Daudé <philmd@redhat.com>:

> The EDK2 submodule was added for UEFI testing, you don't need to compile
> it to build/use QEMU.
> 
> How did you end up compiling it?

The qemu.spec file has this since a very long time:
make -C roms efirom ${unrelated_settings}

This used to work still in January with c9d18c1c150c84e7a976df989ad04ddf01083f46.

Olaf

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [Qemu-devel] edk2 fails to compile in v4.0.0-rc2

[Philippe Mathieu-Daudé]

[-- Attachment #1: Type: text/plain, Size: 865 bytes --]

On 4/5/19 12:59 PM, Olaf Hering wrote:
> Am Fri, 5 Apr 2019 12:49:15 +0200
> schrieb Philippe Mathieu-Daudé <philmd@redhat.com>:
> 
>> The EDK2 submodule was added for UEFI testing, you don't need to compile
>> it to build/use QEMU.
>>
>> How did you end up compiling it?
> 
> The qemu.spec file has this since a very long time:
> make -C roms efirom ${unrelated_settings}

I don't have any qemu.spec, is it a SUSE file?

> 
> This used to work still in January with c9d18c1c150c84e7a976df989ad04ddf01083f46.

Before f590a812c210 the EfiRom tool was not available, now we compile it
inconditionally.

So I assume your distribution already provides the EfiRom tool. Can you
point me at the package which provides it? I wonder if your distribution
use a non-upstreamed patch that change the EDK2 BaseTools PIE/PIC flags.

Thanks,

Phil.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Qemu-devel] edk2 fails to compile in v4.0.0-rc2

[Philippe Mathieu-Daudé]

[-- Attachment #1: Type: text/plain, Size: 865 bytes --]

On 4/5/19 12:59 PM, Olaf Hering wrote:
> Am Fri, 5 Apr 2019 12:49:15 +0200
> schrieb Philippe Mathieu-Daudé <philmd@redhat.com>:
> 
>> The EDK2 submodule was added for UEFI testing, you don't need to compile
>> it to build/use QEMU.
>>
>> How did you end up compiling it?
> 
> The qemu.spec file has this since a very long time:
> make -C roms efirom ${unrelated_settings}

I don't have any qemu.spec, is it a SUSE file?

> 
> This used to work still in January with c9d18c1c150c84e7a976df989ad04ddf01083f46.

Before f590a812c210 the EfiRom tool was not available, now we compile it
inconditionally.

So I assume your distribution already provides the EfiRom tool. Can you
point me at the package which provides it? I wonder if your distribution
use a non-upstreamed patch that change the EDK2 BaseTools PIE/PIC flags.

Thanks,

Phil.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Qemu-devel] edk2 fails to compile in v4.0.0-rc2

[Philippe Mathieu-Daudé]

[-- Attachment #1: Type: text/plain, Size: 2104 bytes --]

On 4/5/19 1:14 PM, Philippe Mathieu-Daudé wrote:
> On 4/5/19 12:59 PM, Olaf Hering wrote:
>> Am Fri, 5 Apr 2019 12:49:15 +0200
>> schrieb Philippe Mathieu-Daudé <philmd@redhat.com>:
>>
>>> The EDK2 submodule was added for UEFI testing, you don't need to compile
>>> it to build/use QEMU.
>>>
>>> How did you end up compiling it?
>>
>> The qemu.spec file has this since a very long time:
>> make -C roms efirom ${unrelated_settings}
> 
> I don't have any qemu.spec, is it a SUSE file?

I checked and apparently.

>>
>> This used to work still in January with c9d18c1c150c84e7a976df989ad04ddf01083f46.
> 
> Before f590a812c210 the EfiRom tool was not available, now we compile it
> inconditionally.
> 
> So I assume your distribution already provides the EfiRom tool. Can you
> point me at the package which provides it? I wonder if your distribution
> use a non-upstreamed patch that change the EDK2 BaseTools PIE/PIC flags.

I see EfiRom was previously provided by ovmf-tools-2017.src.rpm, and the
latest ovmf-2019.src.rpm has this file:

$ cat ovmf-pie.patch
Index:
ovmf-2018+git1534736099.43fe4c405292/BaseTools/Source/C/Makefiles/header.makefile
===================================================================
---
ovmf-2018+git1534736099.43fe4c405292.orig/BaseTools/Source/C/Makefiles/header.makefile
+++
ovmf-2018+git1534736099.43fe4c405292/BaseTools/Source/C/Makefiles/header.makefile
@@ -77,7 +77,7 @@ ifeq ($(DARWIN),Darwin)
 # assume clang or clang compatible flags on OS X
 BUILD_CFLAGS = -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror
-Wno-deprecated-declarations -Wno-self-assign -Wno-unused-result
-nostdlib -g
 else
-BUILD_CFLAGS = -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror
-Wno-deprecated-declarations -Wno-stringop-truncation -Wno-restrict
-Wno-unused-result -nostdlib -g
+BUILD_CFLAGS = -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror
-Wno-deprecated-declarations -Wno-stringop-truncation -Wno-restrict
-Wno-unused-result -nostdlib -g -fPIE
 endif
 BUILD_LFLAGS =
 BUILD_CXXFLAGS = -Wno-unused-result




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Qemu-devel] edk2 fails to compile in v4.0.0-rc2

[Philippe Mathieu-Daudé]

[-- Attachment #1: Type: text/plain, Size: 2104 bytes --]

On 4/5/19 1:14 PM, Philippe Mathieu-Daudé wrote:
> On 4/5/19 12:59 PM, Olaf Hering wrote:
>> Am Fri, 5 Apr 2019 12:49:15 +0200
>> schrieb Philippe Mathieu-Daudé <philmd@redhat.com>:
>>
>>> The EDK2 submodule was added for UEFI testing, you don't need to compile
>>> it to build/use QEMU.
>>>
>>> How did you end up compiling it?
>>
>> The qemu.spec file has this since a very long time:
>> make -C roms efirom ${unrelated_settings}
> 
> I don't have any qemu.spec, is it a SUSE file?

I checked and apparently.

>>
>> This used to work still in January with c9d18c1c150c84e7a976df989ad04ddf01083f46.
> 
> Before f590a812c210 the EfiRom tool was not available, now we compile it
> inconditionally.
> 
> So I assume your distribution already provides the EfiRom tool. Can you
> point me at the package which provides it? I wonder if your distribution
> use a non-upstreamed patch that change the EDK2 BaseTools PIE/PIC flags.

I see EfiRom was previously provided by ovmf-tools-2017.src.rpm, and the
latest ovmf-2019.src.rpm has this file:

$ cat ovmf-pie.patch
Index:
ovmf-2018+git1534736099.43fe4c405292/BaseTools/Source/C/Makefiles/header.makefile
===================================================================
---
ovmf-2018+git1534736099.43fe4c405292.orig/BaseTools/Source/C/Makefiles/header.makefile
+++
ovmf-2018+git1534736099.43fe4c405292/BaseTools/Source/C/Makefiles/header.makefile
@@ -77,7 +77,7 @@ ifeq ($(DARWIN),Darwin)
 # assume clang or clang compatible flags on OS X
 BUILD_CFLAGS = -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror
-Wno-deprecated-declarations -Wno-self-assign -Wno-unused-result
-nostdlib -g
 else
-BUILD_CFLAGS = -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror
-Wno-deprecated-declarations -Wno-stringop-truncation -Wno-restrict
-Wno-unused-result -nostdlib -g
+BUILD_CFLAGS = -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror
-Wno-deprecated-declarations -Wno-stringop-truncation -Wno-restrict
-Wno-unused-result -nostdlib -g -fPIE
 endif
 BUILD_LFLAGS =
 BUILD_CXXFLAGS = -Wno-unused-result




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Qemu-devel] edk2 fails to compile in v4.0.0-rc2

[Olaf Hering]

[-- Attachment #1: Type: text/plain, Size: 1525 bytes --]

Am Fri, 5 Apr 2019 13:14:35 +0200
schrieb Philippe Mathieu-Daudé <philmd@redhat.com>:

> On 4/5/19 12:59 PM, Olaf Hering wrote:
> > Am Fri, 5 Apr 2019 12:49:15 +0200
> > schrieb Philippe Mathieu-Daudé <philmd@redhat.com>:
> >   
> >> The EDK2 submodule was added for UEFI testing, you don't need to compile
> >> it to build/use QEMU.
> >>
> >> How did you end up compiling it?  
> > 
> > The qemu.spec file has this since a very long time:
> > make -C roms efirom ${unrelated_settings}  
> I don't have any qemu.spec, is it a SUSE file?

Yes, it is part of the qemu package.

https://build.opensuse.org/package/show/Virtualization/qemu

> > This used to work still in January with c9d18c1c150c84e7a976df989ad04ddf01083f46.  
> Before f590a812c210 the EfiRom tool was not available, now we compile it
> inconditionally.

I wonder why it must be compiled unconditionally.
This is my workaround:

sed -i 's@EFIROM@KAPUTT@g' roms/Makefile
efirom=
test -x "$(type -P EfiRom)" && KAPUTT="$_" efirom=efirom
make -C roms ${efirom} KAPUTT=${KAPUTT}

> So I assume your distribution already provides the EfiRom tool. Can you
> point me at the package which provides it? I wonder if your distribution
> use a non-upstreamed patch that change the EDK2 BaseTools PIE/PIC flags.

It is in ovmf-tools.rpm, which comes from ovmf. And looking at this package,
they also had to workaround the fact that edk2 does not cope with PIE.

https://build.opensuse.org/package/show/Virtualization/ovmf

Olaf

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [Qemu-devel] edk2 fails to compile in v4.0.0-rc2

[Olaf Hering]

[-- Attachment #1: Type: text/plain, Size: 1525 bytes --]

Am Fri, 5 Apr 2019 13:14:35 +0200
schrieb Philippe Mathieu-Daudé <philmd@redhat.com>:

> On 4/5/19 12:59 PM, Olaf Hering wrote:
> > Am Fri, 5 Apr 2019 12:49:15 +0200
> > schrieb Philippe Mathieu-Daudé <philmd@redhat.com>:
> >   
> >> The EDK2 submodule was added for UEFI testing, you don't need to compile
> >> it to build/use QEMU.
> >>
> >> How did you end up compiling it?  
> > 
> > The qemu.spec file has this since a very long time:
> > make -C roms efirom ${unrelated_settings}  
> I don't have any qemu.spec, is it a SUSE file?

Yes, it is part of the qemu package.

https://build.opensuse.org/package/show/Virtualization/qemu

> > This used to work still in January with c9d18c1c150c84e7a976df989ad04ddf01083f46.  
> Before f590a812c210 the EfiRom tool was not available, now we compile it
> inconditionally.

I wonder why it must be compiled unconditionally.
This is my workaround:

sed -i 's@EFIROM@KAPUTT@g' roms/Makefile
efirom=
test -x "$(type -P EfiRom)" && KAPUTT="$_" efirom=efirom
make -C roms ${efirom} KAPUTT=${KAPUTT}

> So I assume your distribution already provides the EfiRom tool. Can you
> point me at the package which provides it? I wonder if your distribution
> use a non-upstreamed patch that change the EDK2 BaseTools PIE/PIC flags.

It is in ovmf-tools.rpm, which comes from ovmf. And looking at this package,
they also had to workaround the fact that edk2 does not cope with PIE.

https://build.opensuse.org/package/show/Virtualization/ovmf

Olaf

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [Qemu-devel] edk2 fails to compile in v4.0.0-rc2

[Olaf Hering]

[-- Attachment #1: Type: text/plain, Size: 281 bytes --]

Am Fri, 5 Apr 2019 12:59:18 +0200
schrieb Olaf Hering <olaf@aepfle.de>:

> This used to work still in January with c9d18c1c150c84e7a976df989ad04ddf01083f46.

It is not possible to just override EFIROM=$(type -P EfiRom) because this variable is also used by ipxe.git.

Olaf

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [Qemu-devel] edk2 fails to compile in v4.0.0-rc2

[Olaf Hering]

[-- Attachment #1: Type: text/plain, Size: 281 bytes --]

Am Fri, 5 Apr 2019 12:59:18 +0200
schrieb Olaf Hering <olaf@aepfle.de>:

> This used to work still in January with c9d18c1c150c84e7a976df989ad04ddf01083f46.

It is not possible to just override EFIROM=$(type -P EfiRom) because this variable is also used by ipxe.git.

Olaf

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [Qemu-devel] edk2 fails to compile in v4.0.0-rc2

[Philippe Mathieu-Daudé]

[-- Attachment #1: Type: text/plain, Size: 748 bytes --]

On 4/5/19 1:16 PM, Olaf Hering wrote:
> Am Fri, 5 Apr 2019 12:59:18 +0200
> schrieb Olaf Hering <olaf@aepfle.de>:
> 
>> This used to work still in January with c9d18c1c150c84e7a976df989ad04ddf01083f46.
> 
> It is not possible to just override EFIROM=$(type -P EfiRom) because this variable is also used by ipxe.git.

Yes, lets got back with the overridable form previous to f590a812c210:

-- >8 --
diff --git a/roms/Makefile b/roms/Makefile
index 78d5dd18c30..fc501a6c30c 100644
--- a/roms/Makefile
+++ b/roms/Makefile
@@ -49,3 +49,3 @@ SEABIOS_EXTRAVERSION="-prebuilt.qemu.org"
 #
-EFIROM = edk2/BaseTools/Source/C/bin/EfiRom
+EFIROM ?= edk2/BaseTools/Source/C/bin/EfiRom

---

I'll submit that patch.

Thanks,

Phil.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Qemu-devel] edk2 fails to compile in v4.0.0-rc2

[Philippe Mathieu-Daudé]

[-- Attachment #1: Type: text/plain, Size: 748 bytes --]

On 4/5/19 1:16 PM, Olaf Hering wrote:
> Am Fri, 5 Apr 2019 12:59:18 +0200
> schrieb Olaf Hering <olaf@aepfle.de>:
> 
>> This used to work still in January with c9d18c1c150c84e7a976df989ad04ddf01083f46.
> 
> It is not possible to just override EFIROM=$(type -P EfiRom) because this variable is also used by ipxe.git.

Yes, lets got back with the overridable form previous to f590a812c210:

-- >8 --
diff --git a/roms/Makefile b/roms/Makefile
index 78d5dd18c30..fc501a6c30c 100644
--- a/roms/Makefile
+++ b/roms/Makefile
@@ -49,3 +49,3 @@ SEABIOS_EXTRAVERSION="-prebuilt.qemu.org"
 #
-EFIROM = edk2/BaseTools/Source/C/bin/EfiRom
+EFIROM ?= edk2/BaseTools/Source/C/bin/EfiRom

---

I'll submit that patch.

Thanks,

Phil.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Qemu-devel] edk2 fails to compile in v4.0.0-rc2

[Olaf Hering]

[-- Attachment #1: Type: text/plain, Size: 193 bytes --]

Am Fri, 5 Apr 2019 13:29:44 +0200
schrieb Philippe Mathieu-Daudé <philmd@redhat.com>:

> I'll submit that patch.

Can this actually work? It does not remove the naming conflict.

Olaf

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [Qemu-devel] edk2 fails to compile in v4.0.0-rc2

[Olaf Hering]

[-- Attachment #1: Type: text/plain, Size: 193 bytes --]

Am Fri, 5 Apr 2019 13:29:44 +0200
schrieb Philippe Mathieu-Daudé <philmd@redhat.com>:

> I'll submit that patch.

Can this actually work? It does not remove the naming conflict.

Olaf

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [Qemu-devel] edk2 fails to compile in v4.0.0-rc2

[Laszlo Ersek]

On 04/05/19 12:59, Olaf Hering wrote:
> Am Fri, 5 Apr 2019 12:49:15 +0200
> schrieb Philippe Mathieu-Daudé <philmd@redhat.com>:
> 
>> The EDK2 submodule was added for UEFI testing, you don't need to compile
>> it to build/use QEMU.
>>
>> How did you end up compiling it?
> 
> The qemu.spec file has this since a very long time:
> make -C roms efirom ${unrelated_settings}
> 
> This used to work still in January with c9d18c1c150c84e7a976df989ad04ddf01083f46.

This is not a QEMU build failure, but an issue in the downstream
packaging that not only tries to build QEMU, but performs a maintainer
build on binary artifacts.

I responded in more detail under Phil's thread

[PATCH for-4.0 v2 0/2] roms: Rename the EFIROM variable and let it be
overridable

Thanks
Laszlo

Re: [Qemu-devel] edk2 fails to compile in v4.0.0-rc2

[Laszlo Ersek]

On 04/05/19 12:59, Olaf Hering wrote:
> Am Fri, 5 Apr 2019 12:49:15 +0200
> schrieb Philippe Mathieu-Daudé <philmd@redhat.com>:
> 
>> The EDK2 submodule was added for UEFI testing, you don't need to compile
>> it to build/use QEMU.
>>
>> How did you end up compiling it?
> 
> The qemu.spec file has this since a very long time:
> make -C roms efirom ${unrelated_settings}
> 
> This used to work still in January with c9d18c1c150c84e7a976df989ad04ddf01083f46.

This is not a QEMU build failure, but an issue in the downstream
packaging that not only tries to build QEMU, but performs a maintainer
build on binary artifacts.

I responded in more detail under Phil's thread

[PATCH for-4.0 v2 0/2] roms: Rename the EFIROM variable and let it be
overridable

Thanks
Laszlo

Re: [Qemu-devel] edk2 fails to compile in v4.0.0-rc2

[Olaf Hering]

[-- Attachment #1: Type: text/plain, Size: 395 bytes --]

Am Mon, 8 Apr 2019 11:04:09 +0200
schrieb Laszlo Ersek <lersek@redhat.com>:

> This is not a QEMU build failure, but an issue in the downstream
> packaging that not only tries to build QEMU, but performs a maintainer
> build on binary artifacts.

I'm sure everyone will rebuild the things from source that can be rebuilt.
Who would ship random binary blobs from unknown origin?

Olaf

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [Qemu-devel] edk2 fails to compile in v4.0.0-rc2

[Olaf Hering]

[-- Attachment #1: Type: text/plain, Size: 395 bytes --]

Am Mon, 8 Apr 2019 11:04:09 +0200
schrieb Laszlo Ersek <lersek@redhat.com>:

> This is not a QEMU build failure, but an issue in the downstream
> packaging that not only tries to build QEMU, but performs a maintainer
> build on binary artifacts.

I'm sure everyone will rebuild the things from source that can be rebuilt.
Who would ship random binary blobs from unknown origin?

Olaf

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [Qemu-devel] edk2 fails to compile in v4.0.0-rc2

[Laszlo Ersek]

On 04/08/19 11:09, Olaf Hering wrote:
> Am Mon, 8 Apr 2019 11:04:09 +0200
> schrieb Laszlo Ersek <lersek@redhat.com>:
>
>> This is not a QEMU build failure, but an issue in the downstream
>> packaging that not only tries to build QEMU, but performs a
>> maintainer build on binary artifacts.
>
> I'm sure everyone will rebuild the things from source that can be
> rebuilt.

Define "everyone".

- Every direct end-user of upstream QEMU? (That is, every human user
  that runs configure and make and make install?) Absolutely not. Those
  users are already not rebuilding the full contents of pc-bios. Look
  for INSTALL_BLOBS in the top-level makefile.

- Every *packager* / distribution that provides QEMU packages? Yes, they
  will definitely rebuild whatever they can from source. That's only
  prudent and ethical. That's what I called a "maintainer build".

> Who would ship random binary blobs from unknown origin?

I don't expect you to, and any of the patches related to the edk2
submodule don't force you to.

commit f590a812c21074e82228de3e1dfb57b75fc02b62
Author: Laszlo Ersek <lersek@redhat.com>
Date:   Mon Feb 4 17:03:22 2019 +0100

    roms: build the EfiRom utility from the roms/edk2 submodule

    Building the EfiRom utility from "roms/edk2/BaseTools" should make
    "roms/Makefile" more self-contained. Otherwise, we'd call the system-wide
    EfiRom for building the combined iPXE option ROMs, but call the sibling
    utilities from "roms/edk2/BaseTools" for building "roms/edk2" content.

Without this patch, if you ran "make -C roms", you'd use one instance of
EfiRom (from who knows where) for producing the combined iPXE oproms,
and another EfiRom, from the edk2.git submodule, for anything inside
that same edk2.git submodule that requires EfiRom. That's *wrong*.

- You are invoking "make -C roms" in QEMU, so you should use precisely
  the same EfiRom for all purposes that need EfiRom.

- And given that the EfiRom source code is available in the submodule,
  the one EfiRom used (for whatever purpose) should be *that* EfiRom
  (i.e., built from source).

If you need to inject specific compiler/linker flags, into the building
of EfiRom itself, you can already do that; you just need to update your
spec file to take advantage of that edk2 BaseTools build feature.

Laszlo

Re: [Qemu-devel] edk2 fails to compile in v4.0.0-rc2

[Laszlo Ersek]

On 04/08/19 11:09, Olaf Hering wrote:
> Am Mon, 8 Apr 2019 11:04:09 +0200
> schrieb Laszlo Ersek <lersek@redhat.com>:
>
>> This is not a QEMU build failure, but an issue in the downstream
>> packaging that not only tries to build QEMU, but performs a
>> maintainer build on binary artifacts.
>
> I'm sure everyone will rebuild the things from source that can be
> rebuilt.

Define "everyone".

- Every direct end-user of upstream QEMU? (That is, every human user
  that runs configure and make and make install?) Absolutely not. Those
  users are already not rebuilding the full contents of pc-bios. Look
  for INSTALL_BLOBS in the top-level makefile.

- Every *packager* / distribution that provides QEMU packages? Yes, they
  will definitely rebuild whatever they can from source. That's only
  prudent and ethical. That's what I called a "maintainer build".

> Who would ship random binary blobs from unknown origin?

I don't expect you to, and any of the patches related to the edk2
submodule don't force you to.

commit f590a812c21074e82228de3e1dfb57b75fc02b62
Author: Laszlo Ersek <lersek@redhat.com>
Date:   Mon Feb 4 17:03:22 2019 +0100

    roms: build the EfiRom utility from the roms/edk2 submodule

    Building the EfiRom utility from "roms/edk2/BaseTools" should make
    "roms/Makefile" more self-contained. Otherwise, we'd call the system-wide
    EfiRom for building the combined iPXE option ROMs, but call the sibling
    utilities from "roms/edk2/BaseTools" for building "roms/edk2" content.

Without this patch, if you ran "make -C roms", you'd use one instance of
EfiRom (from who knows where) for producing the combined iPXE oproms,
and another EfiRom, from the edk2.git submodule, for anything inside
that same edk2.git submodule that requires EfiRom. That's *wrong*.

- You are invoking "make -C roms" in QEMU, so you should use precisely
  the same EfiRom for all purposes that need EfiRom.

- And given that the EfiRom source code is available in the submodule,
  the one EfiRom used (for whatever purpose) should be *that* EfiRom
  (i.e., built from source).

If you need to inject specific compiler/linker flags, into the building
of EfiRom itself, you can already do that; you just need to update your
spec file to take advantage of that edk2 BaseTools build feature.

Laszlo