[PATCH 0/6] mesa/go/binutils fixes

[PATCH 0/6] mesa/go/binutils fixes

[Khem Raj]

mesa failed to build with llvm installed on build host
go would not package target recipes correclty.
enable threaded linking for gold regardless of it being default linker or not

The following changes since commit 477805b913a6c4b4b630e42f08cd9e59f1e4e254:

  wic: selftest: account for occasional newline in debugfs file names (2017-03-14 14:39:34 +0000)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib kraj/pu
  http://cgit.openembedded.org/openembedded-core-contrib/log/?h=kraj/pu

Khem Raj (6):
  mesa: Contain configure search for llvm
  mesa-gl: Drop MESA_CRYPTO from PACKAGECONFIG
  go: Fix packaging for target go
  binutils: Enable threading when gold is enabled and is not default
    linker
  musl: Update to latest
  xserver-xf86-config: Remove X server module preload

 meta/recipes-core/musl/musl_git.bb                             |  2 +-
 meta/recipes-devtools/binutils/binutils.inc                    |  2 +-
 meta/recipes-devtools/go/go.inc                                |  8 +-------
 meta/recipes-graphics/mesa/mesa-gl_17.0.1.bb                   |  2 +-
 meta/recipes-graphics/mesa/mesa.inc                            |  2 +-
 .../xorg-xserver/xserver-xf86-config/10-preload-modules.conf   | 10 ----------
 meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb  |  8 --------
 7 files changed, 5 insertions(+), 29 deletions(-)
 delete mode 100644 meta/recipes-graphics/xorg-xserver/xserver-xf86-config/10-preload-modules.conf

-- 
2.12.0

[PATCH 1/6] mesa: Contain configure search for llvm

[Khem Raj]

Configure has an unbridled check for llvm and
when distro provided llvm is installed on build host it
will use that from /usr/bin to poke for llvm libs
and configs. This would result in a subtle errors
however do_qa_configure catches it as a host include/lib
contamination during configure checks

ERROR: mesa-gl-2_17.0.1-r0 do_configure: This autoconf log indicates errors, it looked at host include and/or library paths while determining system capabilities.
Rerun configure task after fixing this.

This is correct because when configure detects build host provided
llvm then it add the include/lib paths to compiler cmdline which are
looking into /usr/include and /usr/lib

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 meta/recipes-graphics/mesa/mesa.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
index 46d8d611c1..0f3dbb0397 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -22,7 +22,7 @@ inherit autotools pkgconfig pythonnative gettext distro_features_check
 
 REQUIRED_DISTRO_FEATURES = "opengl"
 
-EXTRA_OECONF = "--enable-shared-glapi"
+EXTRA_OECONF = "--enable-shared-glapi --with-llvm-prefix=${STAGING_BINDIR_NATIVE}"
 
 PACKAGECONFIG ??= "gbm egl gles dri \
 		${@bb.utils.filter('DISTRO_FEATURES', 'wayland x11', d)} \
-- 
2.12.0

[PATCH 2/6] mesa-gl: Drop MESA_CRYPTO from PACKAGECONFIG

[Khem Raj]

with mesa 17 crypto packageconfig has been removed

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 meta/recipes-graphics/mesa/mesa-gl_17.0.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/mesa/mesa-gl_17.0.1.bb b/meta/recipes-graphics/mesa/mesa-gl_17.0.1.bb
index 85cc396fe3..e3604f30bb 100644
--- a/meta/recipes-graphics/mesa/mesa-gl_17.0.1.bb
+++ b/meta/recipes-graphics/mesa/mesa-gl_17.0.1.bb
@@ -8,6 +8,6 @@ PROVIDES = "virtual/libgl virtual/mesa"
 
 S = "${WORKDIR}/mesa-${PV}"
 
-PACKAGECONFIG ??= "dri ${MESA_CRYPTO} ${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}"
+PACKAGECONFIG ??= "dri ${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}"
 
 EXCLUDE_FROM_WORLD = "1"
-- 
2.12.0

[PATCH 3/6] go: Fix packaging for target go

[Khem Raj]

We need all packaging tasks when building
go for target

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 meta/recipes-devtools/go/go.inc | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/meta/recipes-devtools/go/go.inc b/meta/recipes-devtools/go/go.inc
index 0b0cbf19ad..5ccbf73e23 100644
--- a/meta/recipes-devtools/go/go.inc
+++ b/meta/recipes-devtools/go/go.inc
@@ -74,12 +74,6 @@ do_install_class-cross() {
 		install -m755 $f ${D}${bindir}
 	done
 }
+do_package_qa[noexec] = "1"
 
-INSANE_SKIP_${PN} += "staticdev"
 RDEPENDS_${PN} += "perl"
-
-do_package[noexec] = "1"
-do_packagedata[noexec] = "1"
-do_package_write_ipk[noexec] = "1"
-do_package_write_deb[noexec] = "1"
-do_package_write_rpm[noexec] = "1"
-- 
2.12.0

[PATCH 4/6] binutils: Enable threading when gold is enabled and is not default linker

[Khem Raj]

Currently we enable threaded linking feature of gold linker only
when its used as default ld. There is no need to restrict it when
its not default linker either. As long as gold is enabled, which
is the case here, we should be able to do threaded linking.

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 meta/recipes-devtools/binutils/binutils.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/binutils/binutils.inc b/meta/recipes-devtools/binutils/binutils.inc
index 9b1192b6e7..37813dd864 100644
--- a/meta/recipes-devtools/binutils/binutils.inc
+++ b/meta/recipes-devtools/binutils/binutils.inc
@@ -78,7 +78,7 @@ EXTRA_OECONF = "--program-prefix=${TARGET_PREFIX} \
 
 LDGOLD_class-native = ""
 LDGOLD_class-crosssdk = ""
-LDGOLD ?= "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-gold', '--enable-gold=default --enable-threads', '--enable-gold --enable-ld=default', d)}"
+LDGOLD ?= "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-gold', '--enable-gold=default --enable-threads', '--enable-gold --enable-ld=default --enable-threads', d)}"
 
 # This is necessary due to a bug in the binutils Makefiles
 # EXTRA_OEMAKE = "configure-build-libiberty all"
-- 
2.12.0

[PATCH 5/6] musl: Update to latest

[Khem Raj]

Rich Felker (11):
      fix ld-behavior-dependent crash in ppc64 ldso startup
      rework ldso handling of global symbol table for consistency
      reorder addend handling before symbol lookup in relocation code
      emulate lazy relocation as deferrable relocation
      fix free of uninitialized buffer pointer on error in regexec
      in static dl_iterate_phdr, fix use of possibly-uninitialized aux data
      fix possible fd leak, unrestored cancellation state on dns socket fail
      fix wide scanf's use of a compound literal past its lifetime
      fix one-byte overflow in legacy getpass function
      avoid loading of multiple libc versions via explicit pathname
      remove unused refcnt field for shared libraries

Szabolcs Nagy (1):
      treat STB_WEAK and STB_GNU_UNIQUE like STB_GLOBAL in find_sym

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 meta/recipes-core/musl/musl_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/musl/musl_git.bb b/meta/recipes-core/musl/musl_git.bb
index 7156669064..fa87d7d3e3 100644
--- a/meta/recipes-core/musl/musl_git.bb
+++ b/meta/recipes-core/musl/musl_git.bb
@@ -3,7 +3,7 @@
 
 require musl.inc
 
-SRCREV = "827c4e6fbe46142049ef3d8bcb8f35951712797d"
+SRCREV = "cb525397bb053ea49cf160965477a17b17286eb3"
 
 PV = "1.1.16+git${SRCPV}"
 
-- 
2.12.0

[PATCH 6/6] xserver-xf86-config: Remove X server module preload

[Khem Raj]

This was a solution needed for musl but now musl has
got lazy loading.

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 .../xorg-xserver/xserver-xf86-config/10-preload-modules.conf   | 10 ----------
 meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb  |  8 --------
 2 files changed, 18 deletions(-)
 delete mode 100644 meta/recipes-graphics/xorg-xserver/xserver-xf86-config/10-preload-modules.conf

diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xf86-config/10-preload-modules.conf b/meta/recipes-graphics/xorg-xserver/xserver-xf86-config/10-preload-modules.conf
deleted file mode 100644
index 23fcdc7ef2..0000000000
--- a/meta/recipes-graphics/xorg-xserver/xserver-xf86-config/10-preload-modules.conf
+++ /dev/null
@@ -1,10 +0,0 @@
-Section "Module"
-    Load "fbdevhw"
-    Load "fb"
-    Load "shadow"
-    Load "shadowfb"
-    Load "int10"
-    Load "vbe"
-    Load "vgahw"
-    Load "glamoregl"
-EndSection
diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb b/meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb
index e07c204c74..4c442bc712 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb
@@ -7,10 +7,6 @@ PR = "r33"
 
 SRC_URI = "file://xorg.conf"
 
-SRC_URI_append_libc-musl = "\
-          file://10-preload-modules.conf \
-"
-
 S = "${WORKDIR}"
 
 CONFFILES_${PN} = "${sysconfdir}/X11/xorg.conf"
@@ -25,7 +21,3 @@ do_install () {
 		install -m 0644 ${WORKDIR}/xorg.conf ${D}/${sysconfdir}/X11/
 	fi
 }
-
-do_install_append_libc-musl () {
-	install -Dm 0644 ${WORKDIR}/10-preload-modules.conf ${D}/${sysconfdir}/X11/xorg.conf.d/10-preload-modules.conf
-}
-- 
2.12.0

Re: [PATCH 5/6] musl: Update to latest

[Jussi Kukkonen]

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

On 15 March 2017 at 01:35, Khem Raj <raj.khem@gmail.com> wrote:

> Rich Felker (11):
>       fix ld-behavior-dependent crash in ppc64 ldso startup
>       rework ldso handling of global symbol table for consistency
>       reorder addend handling before symbol lookup in relocation code
>       emulate lazy relocation as deferrable relocation
>       fix free of uninitialized buffer pointer on error in regexec
>       in static dl_iterate_phdr, fix use of possibly-uninitialized aux data
>       fix possible fd leak, unrestored cancellation state on dns socket
> fail
>       fix wide scanf's use of a compound literal past its lifetime
>       fix one-byte overflow in legacy getpass function
>       avoid loading of multiple libc versions via explicit pathname
>       remove unused refcnt field for shared libraries
>
> Szabolcs Nagy (1):
>       treat STB_WEAK and STB_GNU_UNIQUE like STB_GLOBAL in find_sym
>


Could the relocation changes here be responsible for these ovmf build
failures:
  "GenFw: ERROR 3000: Invalid ... unsupported ELF EM_386 relocation"
?

https://autobuilder.yocto.io/builders/nightly-musl/builds/196/steps/BuildImages/logs/stdio


Jussi

[-- Attachment #2: Type: text/html, Size: 1802 bytes --]

Re: [PATCH 5/6] musl: Update to latest

[Patrick Ohly]

On Mon, 2017-03-20 at 10:32 +0200, Jussi Kukkonen wrote:
> 
> On 15 March 2017 at 01:35, Khem Raj <raj.khem@gmail.com> wrote:
>         Rich Felker (11):
>               fix ld-behavior-dependent crash in ppc64 ldso startup
>               rework ldso handling of global symbol table for
>         consistency
>               reorder addend handling before symbol lookup in
>         relocation code
>               emulate lazy relocation as deferrable relocation
>               fix free of uninitialized buffer pointer on error in
>         regexec
>               in static dl_iterate_phdr, fix use of
>         possibly-uninitialized aux data
>               fix possible fd leak, unrestored cancellation state on
>         dns socket fail
>               fix wide scanf's use of a compound literal past its
>         lifetime
>               fix one-byte overflow in legacy getpass function
>               avoid loading of multiple libc versions via explicit
>         pathname
>               remove unused refcnt field for shared libraries
>         
>         Szabolcs Nagy (1):
>               treat STB_WEAK and STB_GNU_UNIQUE like STB_GLOBAL in
>         find_sym
> 
> 
> 
> 
> Could the relocation changes here be responsible for these ovmf build
> failures:
>   "GenFw: ERROR 3000: Invalid ... unsupported ELF EM_386 relocation"
> ?
> 
> 
> https://autobuilder.yocto.io/builders/nightly-musl/builds/196/steps/BuildImages/logs/stdio

That looks like a good guess.

I had tried to reproduce that error last week with poky/master-next, but
somehow it didn't trigger in my local setup.

I have no idea how to enhance ovmf such that can handle this, though.
Holding back an update of musl until someone can figure it out does not
very attractive. But nor is disabling the building of ovmf when musl is
selected, because then the wic tests which rely on ovmf will fail or
also need to get disabled.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: [PATCH 4/6] binutils: Enable threading when gold is enabled and is not default linker

[Burton, Ross]

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

On 14 March 2017 at 23:35, Khem Raj <raj.khem@gmail.com> wrote:

> Currently we enable threaded linking feature of gold linker only
> when its used as default ld. There is no need to restrict it when
> its not default linker either. As long as gold is enabled, which
> is the case here, we should be able to do threaded linking.
>

Turns out this broke meta-mingw's Windows SDKS (reproducible if you
set SDKMACHINE = "i686-mingw32" and build binutils-cross).  I've sent a
patch to set LDGOLD to '' on mingw, but your comments are welcome on
alternative fixes.

Ross

[-- Attachment #2: Type: text/html, Size: 1097 bytes --]

Re: [PATCH 5/6] musl: Update to latest

[Khem Raj]

On Mon, Mar 20, 2017 at 1:32 AM, Jussi Kukkonen
<jussi.kukkonen@intel.com> wrote:
>
> On 15 March 2017 at 01:35, Khem Raj <raj.khem@gmail.com> wrote:
>>
>> Rich Felker (11):
>>       fix ld-behavior-dependent crash in ppc64 ldso startup
>>       rework ldso handling of global symbol table for consistency
>>       reorder addend handling before symbol lookup in relocation code
>>       emulate lazy relocation as deferrable relocation
>>       fix free of uninitialized buffer pointer on error in regexec
>>       in static dl_iterate_phdr, fix use of possibly-uninitialized aux
>> data
>>       fix possible fd leak, unrestored cancellation state on dns socket
>> fail
>>       fix wide scanf's use of a compound literal past its lifetime
>>       fix one-byte overflow in legacy getpass function
>>       avoid loading of multiple libc versions via explicit pathname
>>       remove unused refcnt field for shared libraries
>>
>> Szabolcs Nagy (1):
>>       treat STB_WEAK and STB_GNU_UNIQUE like STB_GLOBAL in find_sym
>
>
>
> Could the relocation changes here be responsible for these ovmf build
> failures:
>   "GenFw: ERROR 3000: Invalid ... unsupported ELF EM_386 relocation"
> ?
>
Dont understand why musl would affect here.
its using native gcc to build the artifacts its complaining about,

> https://autobuilder.yocto.io/builders/nightly-musl/builds/196/steps/BuildImages/logs/stdio
>
>
> Jussi

ovmf fails to build with musl (was: Re: [PATCH 5/6] musl: Update to latest)

[Patrick Ohly]

On Mon, 2017-03-20 at 07:43 -0700, Khem Raj wrote:
> On Mon, Mar 20, 2017 at 1:32 AM, Jussi Kukkonen
> <jussi.kukkonen@intel.com> wrote:
> >
> > On 15 March 2017 at 01:35, Khem Raj <raj.khem@gmail.com> wrote:
> >>
> >> Rich Felker (11):
> >>       fix ld-behavior-dependent crash in ppc64 ldso startup
> >>       rework ldso handling of global symbol table for consistency
> >>       reorder addend handling before symbol lookup in relocation code
> >>       emulate lazy relocation as deferrable relocation
> >>       fix free of uninitialized buffer pointer on error in regexec
> >>       in static dl_iterate_phdr, fix use of possibly-uninitialized aux
> >> data
> >>       fix possible fd leak, unrestored cancellation state on dns socket
> >> fail
> >>       fix wide scanf's use of a compound literal past its lifetime
> >>       fix one-byte overflow in legacy getpass function
> >>       avoid loading of multiple libc versions via explicit pathname
> >>       remove unused refcnt field for shared libraries
> >>
> >> Szabolcs Nagy (1):
> >>       treat STB_WEAK and STB_GNU_UNIQUE like STB_GLOBAL in find_sym
> >
> >
> >
> > Could the relocation changes here be responsible for these ovmf build
> > failures:
> >   "GenFw: ERROR 3000: Invalid ... unsupported ELF EM_386 relocation"
> > ?
> >
> Dont understand why musl would affect here.
> its using native gcc to build the artifacts its complaining about,

Yes, it is a bit puzzling how the libc on the target can influence the
compilation of ovmf. However, ovmf gets compiled for the target, so
there is at least some correlation.

Why it uses "gcc" is a good question, and I don't know. It happens to
work in practice because there's a long list of additional parameters
which selects the actual target architecture (in particular, -m64 vs.
-m32).

Perhaps this use of the host gcc is the reason why I can't reproduce it
locally.

The recipe has some code which tries to change the "gcc" invocations
into something else. I think it is meant to work like this (don't ask
how long it took me to figure this out):
      * ovmf-native patches BaseTools/Conf/tools_def.template such that
        ${TARGET_PREFIX}gcc is used (do_fix_toolchain)
      * ovmf picks up the path to that modified tools_def.template and
        uses it as Conf/tools_def.txt
        (0002-ovmf-update-path-to-native-BaseTools.patch +
        do_fix_basetools_location)

Ricardo, is that correct?

However, TARGET_PREFIX is empty in ovmf-native. So instead of
i586-poky-linux-musl-gcc or i586-poky-linux-musl-gcc-ar we end up
building with gcc and gcc-ar from the host, which probably wasn't the
intention.

Below a patch which compiles for me using the right tools. More testing
has to wait until tomorrow.

diff --git a/meta/recipes-core/ovmf/ovmf_git.bb b/meta/recipes-core/ovmf/ovmf_git.bb
index a658c9d1154..9ee60feb1f1 100644
--- a/meta/recipes-core/ovmf/ovmf_git.bb
+++ b/meta/recipes-core/ovmf/ovmf_git.bb
@@ -11,7 +11,6 @@ PACKAGECONFIG ??= ""
 PACKAGECONFIG[secureboot] = ",,,"
 
 SRC_URI = "git://github.com/tianocore/edk2.git;branch=master \
-	file://0001-BaseTools-Force-tools-variables-to-host-toolchain.patch \
 	file://0002-ovmf-update-path-to-native-BaseTools.patch \
 	file://0003-BaseTools-makefile-adjust-to-build-in-under-bitbake.patch \
 	file://VfrCompile-increase-path-length-limit.patch \
@@ -53,8 +52,8 @@ OVMF_SECURE_BOOT_FLAGS = "-DSECURE_BOOT_ENABLE=TRUE ${OVMF_SECURE_BOOT_EXTRA_FLA
 
 do_patch_append_class-native() {
     bb.build.exec_func('do_fix_iasl', d)
-    bb.build.exec_func('do_fix_toolchain', d)
 }
+do_patch[postfuncs] += "do_fix_toolchain"
 
 do_fix_basetools_location() {
     sed -i -e 's#BBAKE_EDK_TOOLS_PATH#${STAGING_BINDIR_NATIVE}/${EDK_TOOLS_DIR}#' ${S}/OvmfPkg/build.sh
@@ -69,13 +68,42 @@ do_fix_iasl() {
     sed -i -e 's#/usr/bin/iasl#${STAGING_BINDIR_NATIVE}/iasl#' ${S}/BaseTools/Conf/tools_def.template
 }
 
-do_fix_toolchain(){
-    sed -i -e 's#DEF(ELFGCC_BIN)/#${TARGET_PREFIX}#' ${S}/BaseTools/Conf/tools_def.template
-    sed -i -e 's#DEF(GCC.*PREFIX)#${TARGET_PREFIX}#' ${S}/BaseTools/Conf/tools_def.template
-    sed -i -e "s#^LINKER\(.*\)#LINKER\1\nLFLAGS += ${BUILD_LDFLAGS}#" ${S}/BaseTools/Source/C/Makefiles/app.makefile
-    sed -i -e "s#^LINKER\(.*\)#LINKER\1\nCFLAGS += ${BUILD_CFLAGS}#" ${S}/BaseTools/Source/C/Makefiles/app.makefile
-    sed -i -e "s#^LINKER\(.*\)#LINKER\1\nLFLAGS += ${BUILD_LDFLAGS}#" ${S}/BaseTools/Source/C/VfrCompile/GNUmakefile
-    sed -i -e "s#^LINKER\(.*\)#LINKER\1\nCFLAGS += ${BUILD_CFLAGS}#" ${S}/BaseTools/Source/C/VfrCompile/GNUmakefile
+# Inject CC and friends into the build. LINKER already is in GNUmakefile.
+# Must be idempotent and thus remove old assignments that were inserted
+# earlier.
+do_fix_toolchain() {
+    sed -i \
+        -e '/^\(CC\|CXX\|AS\|AR\|LD\|LINKER\) =/d' \
+        -e '/^APPLICATION/a CC = ${CC}\nCXX = ${CXX}\nAS = ${AS}\nAR = ${AR}\nLD = ${LD}\nLINKER = $(CC)' \
+        ${S}/BaseTools/Source/C/Makefiles/app.makefile
+    sed -i \
+        -e '/^\(CC\|CXX\|AS\|AR\|LD\)/d' \
+        -e '/^VFR_CPPFLAGS/a CC = ${CC}\nCXX = ${CXX}\nAS = ${AS}\nAR = ${AR}\nLD = ${LD}' \
+        ${S}/BaseTools/Source/C/VfrCompile/GNUmakefile
+}
+do_fix_toolchain_append_class-native() {
+    # This tools_def.template is going to be used by the target ovmf, which uses
+    # the GCC*_BIN env variables to choose the right gcc for the target.
+    # We can't do that here because HOST_PREFIX and TARGET_PREFIX are both
+    # empty in a native recipe.
+    #
+    # However, tools_def.txt also uses the same variable (indirectly) for
+    # finding make, which wouldn't work. So we reduce that to just plain
+    # make without a prefix here.
+    sed -i \
+        -e 's#DEF(GCC.*_PREFIX)make#make#' \
+        ${S}/BaseTools/Conf/tools_def.template
+    sed -i \
+        -e '/^\(LFLAGS\|CFLAGS\) +=/d' \
+        -e '/^LINKER/a LFLAGS += ${BUILD_LDFLAGS}\nCFLAGS += ${BUILD_CFLAGS}' \
+        ${S}/BaseTools/Source/C/Makefiles/app.makefile \
+        ${S}/BaseTools/Source/C/VfrCompile/GNUmakefile
+}
+do_fix_toolchain_append_class-target() {
+    sed -i \
+        -e 's#DEF(ELFGCC_BIN)/#${HOST_PREFIX}#' \
+        -e 's#DEF(GCC.*PREFIX)#${HOST_PREFIX}#' \
+        ${S}/BaseTools/Conf/tools_def.template
 }
 
 GCC_VER="$(${CC} -v 2>&1 | tail -n1 | awk '{print $3}')"
@@ -129,6 +157,7 @@ do_compile_class-target() {
     fi
     FIXED_GCCVER=$(fixup_target_tools ${GCC_VER})
     bbnote FIXED_GCCVER is ${FIXED_GCCVER}
+    eval "${FIXED_GCCVER}_BIN=${HOST_PREFIX}; export ${FIXED_GCCVER}_BIN"
     build_dir="${S}/Build/Ovmf$OVMF_DIR_SUFFIX/RELEASE_${FIXED_GCCVER}"
 
     bbnote "Building without Secure Boot."


-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: ovmf fails to build with musl (was: Re: [PATCH 5/6] musl: Update to latest)

[Patrick Ohly]

On Mon, 2017-03-20 at 22:02 +0100, Patrick Ohly wrote:
> However, TARGET_PREFIX is empty in ovmf-native. So instead of
> i586-poky-linux-musl-gcc or i586-poky-linux-musl-gcc-ar we end up
> building with gcc and gcc-ar from the host, which probably wasn't the
> intention.
> 
> Below a patch which compiles for me using the right tools. More testing
> has to wait until tomorrow.

I've cleaned up the patch a bit more and tested it successfully with
refkit on intel-corei7-64. Building for musl on qemux86 also worked,
using i586-poky-linux-musl-gcc.

I propose that we include the patch (will send as reply) in master-next
to check whether it also fixes the problem on the AB.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

[PATCH] ovmf: fix toolchain selection

[Patrick Ohly]

For the native tools, a static patch inserted gcc/g++/ld/ar while later
adding BUILD_LDFLAGS and BUILD_CFLAGS with sed. Now it's all done with sed,
which has the advantage that it uses the actual compile variables. However,
in practice those are the same.

More importantly, picking the build tools for the target was
broken. ovmf-native tried to insert TARGET_PREFIX into the tools
definition file, but that variable is empty in a native recipe. As a
result, "gcc" was used instead of "${HOST_PREFIX}gcc", leading to an
undesirable dependency on the host compiler and potentially
(probably?!) causing some of the build issues that were seen for ovmf.

The new approach is to override the tool selection in ovmf-native so
that the HOST_PREFIX env variable is used, which then gets exported
during do_compile for the target.

While at it, Python code that gets appened to do_patch only to call
shell functions gets replaced with the do_patch[postfuncs] mechanism.

Incremental builds now always use the tools definition from the
current ovmf-native; previously, only the initial build copied the
template file.

Probably the entire split into ovmf-native and ovmf could be
removed. This merely hasn't been attempted yet.

Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
---
 meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch | 48 ------------------------------------------------
 meta/recipes-core/ovmf/ovmf_git.bb                                                       | 68 ++++++++++++++++++++++++++++++++++++++++++++++++++------------------
 2 files changed, 50 insertions(+), 66 deletions(-)
 delete mode 100644 meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch

diff --git a/meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch b/meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch
deleted file mode 100644
index 644b99d..0000000
--- a/meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch
+++ /dev/null
@@ -1,48 +0,0 @@
-From 6e24bde1979c2d7149b37d142fb882dfde0e9770 Mon Sep 17 00:00:00 2001
-From: Matt Fleming <matt.fleming@intel.com>
-Date: Fri, 27 Jun 2014 11:12:18 +0100
-Subject: [PATCH] BaseTools: Force tools variables to host toolchain
-
-Signed-off-by: Matt Fleming <matt.fleming@intel.com>
----
- BaseTools/Source/C/Makefiles/app.makefile | 7 +++++++
- BaseTools/Source/C/VfrCompile/GNUmakefile | 5 +++++
- 2 files changed, 12 insertions(+)
-
-diff --git a/BaseTools/Source/C/Makefiles/app.makefile b/BaseTools/Source/C/Makefiles/app.makefile
-index 19269a1..62aad0f 100644
---- a/BaseTools/Source/C/Makefiles/app.makefile
-+++ b/BaseTools/Source/C/Makefiles/app.makefile
-@@ -16,6 +16,13 @@ include $(MAKEROOT)/Makefiles/header.makefile
- 
- APPLICATION = $(MAKEROOT)/bin/$(APPNAME)
- 
-+CC = gcc
-+CXX = g++
-+AS = gcc
-+AR = ar
-+LD = ld
-+LINKER = $(CC)
-+
- .PHONY:all
- all: $(MAKEROOT)/bin $(APPLICATION) 
- 
-diff --git a/BaseTools/Source/C/VfrCompile/GNUmakefile b/BaseTools/Source/C/VfrCompile/GNUmakefile
-index 82005e1..5ac5f7e 100644
---- a/BaseTools/Source/C/VfrCompile/GNUmakefile
-+++ b/BaseTools/Source/C/VfrCompile/GNUmakefile
-@@ -26,6 +26,11 @@ OBJECTS = AParser.o DLexerBase.o ATokenBuffer.o EfiVfrParser.o VfrLexer.o VfrSyn
- 
- VFR_CPPFLAGS = -DPCCTS_USE_NAMESPACE_STD $(CPPFLAGS)
- 
-+CC = gcc
-+CXX = g++
-+AS = gcc
-+AR = ar
-+LD = ld
- LINKER = $(BUILD_CXX)
- 
- EXTRA_CLEAN_OBJECTS = EfiVfrParser.cpp EfiVfrParser.h VfrParser.dlg VfrTokens.h VfrLexer.cpp VfrLexer.h VfrSyntax.cpp tokens.h
--- 
-1.9.0
-
diff --git a/meta/recipes-core/ovmf/ovmf_git.bb b/meta/recipes-core/ovmf/ovmf_git.bb
index a658c9d..898c5b7 100644
--- a/meta/recipes-core/ovmf/ovmf_git.bb
+++ b/meta/recipes-core/ovmf/ovmf_git.bb
@@ -11,7 +11,6 @@ PACKAGECONFIG ??= ""
 PACKAGECONFIG[secureboot] = ",,,"
 
 SRC_URI = "git://github.com/tianocore/edk2.git;branch=master \
-	file://0001-BaseTools-Force-tools-variables-to-host-toolchain.patch \
 	file://0002-ovmf-update-path-to-native-BaseTools.patch \
 	file://0003-BaseTools-makefile-adjust-to-build-in-under-bitbake.patch \
 	file://VfrCompile-increase-path-length-limit.patch \
@@ -51,31 +50,54 @@ COMPATIBLE_HOST='(i.86|x86_64).*'
 OVMF_SECURE_BOOT_EXTRA_FLAGS ??= ""
 OVMF_SECURE_BOOT_FLAGS = "-DSECURE_BOOT_ENABLE=TRUE ${OVMF_SECURE_BOOT_EXTRA_FLAGS}"
 
-do_patch_append_class-native() {
-    bb.build.exec_func('do_fix_iasl', d)
-    bb.build.exec_func('do_fix_toolchain', d)
+do_patch[postfuncs] += "fix_basetools_location"
+fix_basetools_location () {
 }
-
-do_fix_basetools_location() {
+fix_basetools_location_class-target() {
+    # Replaces the fake path inserted by 0002-ovmf-update-path-to-native-BaseTools.patch.
+    # Necessary for finding the actual BaseTools from ovmf-native.
     sed -i -e 's#BBAKE_EDK_TOOLS_PATH#${STAGING_BINDIR_NATIVE}/${EDK_TOOLS_DIR}#' ${S}/OvmfPkg/build.sh
 }
 
-do_patch_append_class-target() {
-    bb.build.exec_func('do_fix_basetools_location', d)
+do_patch[postfuncs] += "fix_iasl"
+fix_iasl() {
 }
-
-
-do_fix_iasl() {
+fix_iasl_class-native() {
+    # iasl is not installed under /usr/bin when building with OE.
     sed -i -e 's#/usr/bin/iasl#${STAGING_BINDIR_NATIVE}/iasl#' ${S}/BaseTools/Conf/tools_def.template
 }
 
-do_fix_toolchain(){
-    sed -i -e 's#DEF(ELFGCC_BIN)/#${TARGET_PREFIX}#' ${S}/BaseTools/Conf/tools_def.template
-    sed -i -e 's#DEF(GCC.*PREFIX)#${TARGET_PREFIX}#' ${S}/BaseTools/Conf/tools_def.template
-    sed -i -e "s#^LINKER\(.*\)#LINKER\1\nLFLAGS += ${BUILD_LDFLAGS}#" ${S}/BaseTools/Source/C/Makefiles/app.makefile
-    sed -i -e "s#^LINKER\(.*\)#LINKER\1\nCFLAGS += ${BUILD_CFLAGS}#" ${S}/BaseTools/Source/C/Makefiles/app.makefile
-    sed -i -e "s#^LINKER\(.*\)#LINKER\1\nLFLAGS += ${BUILD_LDFLAGS}#" ${S}/BaseTools/Source/C/VfrCompile/GNUmakefile
-    sed -i -e "s#^LINKER\(.*\)#LINKER\1\nCFLAGS += ${BUILD_CFLAGS}#" ${S}/BaseTools/Source/C/VfrCompile/GNUmakefile
+# Inject CC and friends into the build. LINKER already is in GNUmakefile.
+# Must be idempotent and thus remove old assignments that were inserted
+# earlier.
+do_patch[postfuncs] += "fix_toolchain"
+fix_toolchain() {
+    sed -i \
+        -e '/^\(CC\|CXX\|AS\|AR\|LD\|LINKER\) =/d' \
+        -e '/^APPLICATION/a CC = ${CC}\nCXX = ${CXX}\nAS = ${AS}\nAR = ${AR}\nLD = ${LD}\nLINKER = $(CC)' \
+        ${S}/BaseTools/Source/C/Makefiles/app.makefile
+    sed -i \
+        -e '/^\(CC\|CXX\|AS\|AR\|LD\)/d' \
+        -e '/^VFR_CPPFLAGS/a CC = ${CC}\nCXX = ${CXX}\nAS = ${AS}\nAR = ${AR}\nLD = ${LD}' \
+        ${S}/BaseTools/Source/C/VfrCompile/GNUmakefile
+}
+fix_toolchain_append_class-native() {
+    # This tools_def.template is going to be used by the target ovmf and
+    # defines which compilers to use. For the GCC toolchain definitions,
+    # that will be ${HOST_PREFIX}gcc. However, "make" doesn't need that
+    # prefix.
+    #
+    # Injecting ENV(HOST_PREFIX) matches exporting that value as env
+    # variable in do_compile_class-target.
+    sed -i \
+        -e 's#\(ENV\|DEF\)(GCC.*_PREFIX)#ENV(HOST_PREFIX)#' \
+        -e 's#ENV(HOST_PREFIX)make#make#' \
+        ${S}/BaseTools/Conf/tools_def.template
+    sed -i \
+        -e '/^\(LFLAGS\|CFLAGS\) +=/d' \
+        -e '/^LINKER/a LFLAGS += ${BUILD_LDFLAGS}\nCFLAGS += ${BUILD_CFLAGS}' \
+        ${S}/BaseTools/Source/C/Makefiles/app.makefile \
+        ${S}/BaseTools/Source/C/VfrCompile/GNUmakefile
 }
 
 GCC_VER="$(${CC} -v 2>&1 | tail -n1 | awk '{print $3}')"
@@ -119,6 +141,16 @@ do_compile_class-target() {
         OVMF_ARCH="IA32"
     fi
 
+    # The build for the target uses BaseTools/Conf/tools_def.template
+    # from ovmf-native to find the compiler, which depends on
+    # exporting HOST_PREFIX.
+    export HOST_PREFIX="${HOST_PREFIX}"
+
+    # BaseTools/Conf gets copied to Conf, but only if that does not
+    # exist yet. To ensure that an updated template gets used during
+    # incremental builds, we need to remove the copy before we start.
+    rm -f `ls ${S}/Conf/*.txt | grep -v ReadMe.txt`
+
     # ${WORKDIR}/ovmf is a well-known location where do_install and
     # do_deploy will be able to find the files.
     rm -rf ${WORKDIR}/ovmf

base-commit: 30bea167e7c204be52b3f5af24e43d5f339e98b7
-- 
git-series 0.9.1

Re: [PATCH] ovmf: fix toolchain selection

[Khem Raj]

On Tue, Mar 21, 2017 at 1:56 AM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> For the native tools, a static patch inserted gcc/g++/ld/ar while later
> adding BUILD_LDFLAGS and BUILD_CFLAGS with sed. Now it's all done with sed,
> which has the advantage that it uses the actual compile variables. However,
> in practice those are the same.
>
> More importantly, picking the build tools for the target was
> broken. ovmf-native tried to insert TARGET_PREFIX into the tools
> definition file, but that variable is empty in a native recipe. As a
> result, "gcc" was used instead of "${HOST_PREFIX}gcc", leading to an
> undesirable dependency on the host compiler and potentially
> (probably?!) causing some of the build issues that were seen for ovmf.
>
> The new approach is to override the tool selection in ovmf-native so
> that the HOST_PREFIX env variable is used, which then gets exported
> during do_compile for the target.
>
> While at it, Python code that gets appened to do_patch only to call
> shell functions gets replaced with the do_patch[postfuncs] mechanism.
>
> Incremental builds now always use the tools definition from the
> current ovmf-native; previously, only the initial build copied the
> template file.
>

FWIW this patch looks good.

> Probably the entire split into ovmf-native and ovmf could be
> removed. This merely hasn't been attempted yet.
>
> Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
> ---
>  meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch | 48 ------------------------------------------------
>  meta/recipes-core/ovmf/ovmf_git.bb                                                       | 68 ++++++++++++++++++++++++++++++++++++++++++++++++++------------------
>  2 files changed, 50 insertions(+), 66 deletions(-)
>  delete mode 100644 meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch
>
> diff --git a/meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch b/meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch
> deleted file mode 100644
> index 644b99d..0000000
> --- a/meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch
> +++ /dev/null
> @@ -1,48 +0,0 @@
> -From 6e24bde1979c2d7149b37d142fb882dfde0e9770 Mon Sep 17 00:00:00 2001
> -From: Matt Fleming <matt.fleming@intel.com>
> -Date: Fri, 27 Jun 2014 11:12:18 +0100
> -Subject: [PATCH] BaseTools: Force tools variables to host toolchain
> -
> -Signed-off-by: Matt Fleming <matt.fleming@intel.com>
> ----
> - BaseTools/Source/C/Makefiles/app.makefile | 7 +++++++
> - BaseTools/Source/C/VfrCompile/GNUmakefile | 5 +++++
> - 2 files changed, 12 insertions(+)
> -
> -diff --git a/BaseTools/Source/C/Makefiles/app.makefile b/BaseTools/Source/C/Makefiles/app.makefile
> -index 19269a1..62aad0f 100644
> ---- a/BaseTools/Source/C/Makefiles/app.makefile
> -+++ b/BaseTools/Source/C/Makefiles/app.makefile
> -@@ -16,6 +16,13 @@ include $(MAKEROOT)/Makefiles/header.makefile
> -
> - APPLICATION = $(MAKEROOT)/bin/$(APPNAME)
> -
> -+CC = gcc
> -+CXX = g++
> -+AS = gcc
> -+AR = ar
> -+LD = ld
> -+LINKER = $(CC)
> -+
> - .PHONY:all
> - all: $(MAKEROOT)/bin $(APPLICATION)
> -
> -diff --git a/BaseTools/Source/C/VfrCompile/GNUmakefile b/BaseTools/Source/C/VfrCompile/GNUmakefile
> -index 82005e1..5ac5f7e 100644
> ---- a/BaseTools/Source/C/VfrCompile/GNUmakefile
> -+++ b/BaseTools/Source/C/VfrCompile/GNUmakefile
> -@@ -26,6 +26,11 @@ OBJECTS = AParser.o DLexerBase.o ATokenBuffer.o EfiVfrParser.o VfrLexer.o VfrSyn
> -
> - VFR_CPPFLAGS = -DPCCTS_USE_NAMESPACE_STD $(CPPFLAGS)
> -
> -+CC = gcc
> -+CXX = g++
> -+AS = gcc
> -+AR = ar
> -+LD = ld
> - LINKER = $(BUILD_CXX)
> -
> - EXTRA_CLEAN_OBJECTS = EfiVfrParser.cpp EfiVfrParser.h VfrParser.dlg VfrTokens.h VfrLexer.cpp VfrLexer.h VfrSyntax.cpp tokens.h
> ---
> -1.9.0
> -
> diff --git a/meta/recipes-core/ovmf/ovmf_git.bb b/meta/recipes-core/ovmf/ovmf_git.bb
> index a658c9d..898c5b7 100644
> --- a/meta/recipes-core/ovmf/ovmf_git.bb
> +++ b/meta/recipes-core/ovmf/ovmf_git.bb
> @@ -11,7 +11,6 @@ PACKAGECONFIG ??= ""
>  PACKAGECONFIG[secureboot] = ",,,"
>
>  SRC_URI = "git://github.com/tianocore/edk2.git;branch=master \
> -       file://0001-BaseTools-Force-tools-variables-to-host-toolchain.patch \
>         file://0002-ovmf-update-path-to-native-BaseTools.patch \
>         file://0003-BaseTools-makefile-adjust-to-build-in-under-bitbake.patch \
>         file://VfrCompile-increase-path-length-limit.patch \
> @@ -51,31 +50,54 @@ COMPATIBLE_HOST='(i.86|x86_64).*'
>  OVMF_SECURE_BOOT_EXTRA_FLAGS ??= ""
>  OVMF_SECURE_BOOT_FLAGS = "-DSECURE_BOOT_ENABLE=TRUE ${OVMF_SECURE_BOOT_EXTRA_FLAGS}"
>
> -do_patch_append_class-native() {
> -    bb.build.exec_func('do_fix_iasl', d)
> -    bb.build.exec_func('do_fix_toolchain', d)
> +do_patch[postfuncs] += "fix_basetools_location"
> +fix_basetools_location () {
>  }
> -
> -do_fix_basetools_location() {
> +fix_basetools_location_class-target() {
> +    # Replaces the fake path inserted by 0002-ovmf-update-path-to-native-BaseTools.patch.
> +    # Necessary for finding the actual BaseTools from ovmf-native.
>      sed -i -e 's#BBAKE_EDK_TOOLS_PATH#${STAGING_BINDIR_NATIVE}/${EDK_TOOLS_DIR}#' ${S}/OvmfPkg/build.sh
>  }
>
> -do_patch_append_class-target() {
> -    bb.build.exec_func('do_fix_basetools_location', d)
> +do_patch[postfuncs] += "fix_iasl"
> +fix_iasl() {
>  }
> -
> -
> -do_fix_iasl() {
> +fix_iasl_class-native() {
> +    # iasl is not installed under /usr/bin when building with OE.
>      sed -i -e 's#/usr/bin/iasl#${STAGING_BINDIR_NATIVE}/iasl#' ${S}/BaseTools/Conf/tools_def.template
>  }
>
> -do_fix_toolchain(){
> -    sed -i -e 's#DEF(ELFGCC_BIN)/#${TARGET_PREFIX}#' ${S}/BaseTools/Conf/tools_def.template
> -    sed -i -e 's#DEF(GCC.*PREFIX)#${TARGET_PREFIX}#' ${S}/BaseTools/Conf/tools_def.template
> -    sed -i -e "s#^LINKER\(.*\)#LINKER\1\nLFLAGS += ${BUILD_LDFLAGS}#" ${S}/BaseTools/Source/C/Makefiles/app.makefile
> -    sed -i -e "s#^LINKER\(.*\)#LINKER\1\nCFLAGS += ${BUILD_CFLAGS}#" ${S}/BaseTools/Source/C/Makefiles/app.makefile
> -    sed -i -e "s#^LINKER\(.*\)#LINKER\1\nLFLAGS += ${BUILD_LDFLAGS}#" ${S}/BaseTools/Source/C/VfrCompile/GNUmakefile
> -    sed -i -e "s#^LINKER\(.*\)#LINKER\1\nCFLAGS += ${BUILD_CFLAGS}#" ${S}/BaseTools/Source/C/VfrCompile/GNUmakefile
> +# Inject CC and friends into the build. LINKER already is in GNUmakefile.
> +# Must be idempotent and thus remove old assignments that were inserted
> +# earlier.
> +do_patch[postfuncs] += "fix_toolchain"
> +fix_toolchain() {
> +    sed -i \
> +        -e '/^\(CC\|CXX\|AS\|AR\|LD\|LINKER\) =/d' \
> +        -e '/^APPLICATION/a CC = ${CC}\nCXX = ${CXX}\nAS = ${AS}\nAR = ${AR}\nLD = ${LD}\nLINKER = $(CC)' \
> +        ${S}/BaseTools/Source/C/Makefiles/app.makefile
> +    sed -i \
> +        -e '/^\(CC\|CXX\|AS\|AR\|LD\)/d' \
> +        -e '/^VFR_CPPFLAGS/a CC = ${CC}\nCXX = ${CXX}\nAS = ${AS}\nAR = ${AR}\nLD = ${LD}' \
> +        ${S}/BaseTools/Source/C/VfrCompile/GNUmakefile
> +}
> +fix_toolchain_append_class-native() {
> +    # This tools_def.template is going to be used by the target ovmf and
> +    # defines which compilers to use. For the GCC toolchain definitions,
> +    # that will be ${HOST_PREFIX}gcc. However, "make" doesn't need that
> +    # prefix.
> +    #
> +    # Injecting ENV(HOST_PREFIX) matches exporting that value as env
> +    # variable in do_compile_class-target.
> +    sed -i \
> +        -e 's#\(ENV\|DEF\)(GCC.*_PREFIX)#ENV(HOST_PREFIX)#' \
> +        -e 's#ENV(HOST_PREFIX)make#make#' \
> +        ${S}/BaseTools/Conf/tools_def.template
> +    sed -i \
> +        -e '/^\(LFLAGS\|CFLAGS\) +=/d' \
> +        -e '/^LINKER/a LFLAGS += ${BUILD_LDFLAGS}\nCFLAGS += ${BUILD_CFLAGS}' \
> +        ${S}/BaseTools/Source/C/Makefiles/app.makefile \
> +        ${S}/BaseTools/Source/C/VfrCompile/GNUmakefile
>  }
>
>  GCC_VER="$(${CC} -v 2>&1 | tail -n1 | awk '{print $3}')"
> @@ -119,6 +141,16 @@ do_compile_class-target() {
>          OVMF_ARCH="IA32"
>      fi
>
> +    # The build for the target uses BaseTools/Conf/tools_def.template
> +    # from ovmf-native to find the compiler, which depends on
> +    # exporting HOST_PREFIX.
> +    export HOST_PREFIX="${HOST_PREFIX}"
> +
> +    # BaseTools/Conf gets copied to Conf, but only if that does not
> +    # exist yet. To ensure that an updated template gets used during
> +    # incremental builds, we need to remove the copy before we start.
> +    rm -f `ls ${S}/Conf/*.txt | grep -v ReadMe.txt`
> +
>      # ${WORKDIR}/ovmf is a well-known location where do_install and
>      # do_deploy will be able to find the files.
>      rm -rf ${WORKDIR}/ovmf
>
> base-commit: 30bea167e7c204be52b3f5af24e43d5f339e98b7
> --
> git-series 0.9.1
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core