Adding the Linaro OE mailing list.
I am not familiar with the details of what you are doing, but it looks
like your layer needs to be updated. See
https://bugzilla.yoctoproject.org/show_bug.cgi?id=3314, the getVar()
function was updated and that requires updating your layer.
nico
On Thu, Oct 18, 2018 at 9:06 PM Park, Kyung Min
<kyung.min.park(a)intel.com> wrote:
>
> Copying Nicolas/Fathi here.
>
>
>
> Hi Nicolas/Fathi,
>
> Can you comment on this?
>
>
>
> Thanks,
>
> Kyung Min
>
>
>
> From: Dey, Megha
> Sent: Wednesday, October 17, 2018 4:40 PM
> To: Park, Kyung Min <kyung.min.park(a)intel.com>; koen.kooi(a)linaro.org
> Subject: RE: oe-rpb-manifest sumo branch?
>
>
>
> Hi Koen,
>
>
>
> We are trying to configure LUV (Linux UEFI Validation) using the OE-RPB model, as per our discussion at the Linaro connect.
>
>
>
> As a start, we tried to build the oe-rpb-manifest with the default morty branch and everything builds fine. However, if we switch to the sumo branch, we see the error below.
>
>
>
> We wanted to confirm if the sumo branch build fine on your end and if we are missing something on our end.
>
>
>
> Please let us know.
>
>
>
> Thanks,
>
> Megha
>
>
>
> From: Park, Kyung Min
> Sent: Tuesday, October 9, 2018 5:22 PM
> To: koen.kooi(a)linaro.org
> Cc: Dey, Megha <megha.dey(a)intel.com>
> Subject: oe-rpb-manifest sumo branch?
>
>
>
> Hi Koen,
>
>
>
> We’ve been trying to build the oe-rpb-manifest with ‘sumo’ branch. But, we’re getting an error in data_smart.py as below.
>
> Do you know if anybody tried sumo branch or validated? Everything went well with ‘morty’ branch.
>
>
>
> # git repo
>
> https://github.com/96boards/oe-rpb-manifest
>
>
>
> # error log when build
>
> ERROR: Unable to parse /home/km/Documents/rpb-yocto-tue/oe-rpb-manifest/bitbake/lib/bb/data_smart.py
>
> Traceback (most recent call last):
>
> File "/home/km/Documents/rpb-yocto-tue/oe-rpb-manifest/bitbake/lib/bb/data_smart.py", line 401, in DataSmart.ex pandWithRefs(s="${(a)os.path.dirname(bb.utils.which(d.getVar('PATH'),'bitbake'))}:${HOSTTOOLS_DIR}", varname='PATH[ :=]'):
>
> raise ExpansionError(varname, s, exc) from exc
>
>
>
> bb.data_smart.ExpansionError: Failure expanding variable PATH[:=], expression was ${(a)os.path.dirname(bb.utils.whi ch(d.getVar('PATH'),'bitbake'))}:${HOSTTOOLS_DIR} which triggered exception TypeError: getVar() missing 1 require d positional argument: 'expand'
>
>
>
> Thanks,
>
> Kyung Min
libcc1 is not included in gcc 4.9 so bad RPATHs fix not needed
in this version.
Signed-off-by: Daniel Gomez <daniel.gomez(a)silicon-gears.com>
---
meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb | 6 ---
---
1 file changed, 6 deletions(-)
diff --git a/meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-
4.9.bb b/meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb
index 3e0f4bc..68d3d92 100644
--- a/meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb
+++ b/meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb
@@ -7,12 +7,6 @@ require recipes-devtools/gcc/gcc-target.inc
# | gcc-4.8.1-r0/gcc-4.8.1/gcc/cp/decl.c:7442:(.text.unlikely+0x318):
additional relocation overflows omitted from the output
ARM_INSTRUCTION_SET_armv4 = "arm"
-do_configure_prepend() {
- # Easiest way to stop bad RPATHs getting into the library
since we have a
- # broken libtool here
- sed -i -e 's/hardcode_into_libs=yes/hardcode_into_libs=no/'
${S}/libcc1/configure
-}
-
BBCLASSEXTEND = "nativesdk"
DEPENDS += "gmp-native"
--
2.7.4
libcc1 is not included in gcc 4.9 so bad RPATHs fix not needed
in this version.
Signed-off-by: Daniel Gomez <daniel.gomez(a)silicon-gears.com>
---
meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb | 6 ---
---
1 file changed, 6 deletions(-)
diff --git a/meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-
4.9.bb b/meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb
index 3e0f4bc..68d3d92 100644
--- a/meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb
+++ b/meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb
@@ -7,12 +7,6 @@ require recipes-devtools/gcc/gcc-target.inc
# | gcc-4.8.1-r0/gcc-4.8.1/gcc/cp/decl.c:7442:(.text.unlikely+0x318):
additional relocation overflows omitted from the output
ARM_INSTRUCTION_SET_armv4 = "arm"
-do_configure_prepend() {
- # Easiest way to stop bad RPATHs getting into the library
since we have a
- # broken libtool here
- sed -i -e 's/hardcode_into_libs=yes/hardcode_into_libs=no/'
${S}/libcc1/configure
-}
-
BBCLASSEXTEND = "nativesdk"
DEPENDS += "gmp-native"
--
2.7.4
Hi,
I looked at https://github.com/96boards/meta-rpb/blame/rocko/recipes-overlayed/kselftes… today and noticed a common anti-pattern:
FOO += “bar”
FOO += “quix”
FOO += “something”
Please stop doing that and use this instead:
FOO = “bar \
quix \
something \
“
In OE += is a heavy operation that really slows down parsing due to the all the expansion and override roundtrips needed, so please stop abusing it as a way to do multiline variables. Thanks!
—
Koen Kooi
Builds and Baselines | Release Manager
Linaro.org | Open source software for ARM SoCs
Signed-off-by: Daniel Gomez <daniel.gomez(a)silicon-gears.com>
---
meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb b/meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb
index 3e0f4bc..5a26fa2 100644
--- a/meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb
+++ b/meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb
@@ -10,7 +10,9 @@ ARM_INSTRUCTION_SET_armv4 = "arm"
do_configure_prepend() {
# Easiest way to stop bad RPATHs getting into the library since we have a
# broken libtool here
- sed -i -e 's/hardcode_into_libs=yes/hardcode_into_libs=no/' ${S}/libcc1/configure
+ if [ -d "${S}/libcc1" ]; then
+ sed -i -e 's/hardcode_into_libs=yes/hardcode_into_libs=no/' ${S}/libcc1/configure
+ fi
}
BBCLASSEXTEND = "nativesdk"
--
2.7.4
Check libcc1 directory before trying to fix it
Signed-off-by: Daniel Gomez <daniel.gomez(a)silicon-gears.com>
---
meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb b/meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb
index 3e0f4bc..5a26fa2 100644
--- a/meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb
+++ b/meta-linaro-toolchain/recipes-devtools/gcc/gcc_linaro-4.9.bb
@@ -10,7 +10,9 @@ ARM_INSTRUCTION_SET_armv4 = "arm"
do_configure_prepend() {
# Easiest way to stop bad RPATHs getting into the library since we have a
# broken libtool here
- sed -i -e 's/hardcode_into_libs=yes/hardcode_into_libs=no/' ${S}/libcc1/configure
+ if [ -d "${S}/libcc1" ]; then
+ sed -i -e 's/hardcode_into_libs=yes/hardcode_into_libs=no/' ${S}/libcc1/configure
+ fi
}
BBCLASSEXTEND = "nativesdk"
--
2.7.4
Koen, Fathi,
Thanks for updating gcc recipe to 7.2 and merging it to rocko! I have some
matching fixes for the external toolchain recipe I'll try to submit soon...
I was wondering what are the plans for other toolchain components, like glibc,
gdb and binutils - there are recipes for glibc 2.20-2014.11, gdb 7.8-2014.09
and binutils 2.25/2.27 2016.10. All those correspond to when the last time a
tarball of that component was released by Linaro. I know these days all those
components are in git at https://git.linaro.org/toolchain/ - are there any
plans to provide corresponding recipes to build those components from sources?
--
Denys