Re: [yocto] Luajit Compile Error
Hi, I also build the package luajit ,but it has the following errors. Can someone help me? Thanks. --- [lixin@ubinux-yocto-15 temp]$ cat log.do_compile.14752 DEBUG: Executing shell function do_compile NOTE: make -j 10 CROSS=i586-poky-linux- TARGET_CFLAGS= --sysroot=/yocto/work001/fnst/lixin/poky/build.x86/tmp/sysroots/qemux86 -m32 -march=i586 TARGET_LDFLAGS= --sysroot=/yocto/work001/fnst/lixin/poky/build.x86/tmp/sysroots/qemux86 TARGET_SHLDFLAGS= --sysroot=/yocto/work001/fnst/lixin/poky/build.x86/tmp/sysroots/qemux86 HOST_CC=gcc -m32 Building LuaJIT 2.0.3 make -C src make[1]: Entering directory `/yocto/work001/fnst/lixin/poky/build.x86/tmp/work/i586-poky-linux/luajit/2.0.3-r0/LuaJIT-2.0.3/src' BUILDVM lj_vm.s BUILDVM lj_ffdef.h BUILDVM lj_bcdef.h Error: pointer size mismatch in cross-build. Try: make HOST_CC=gcc -m32 CROSS=... make[1]: *** [lj_vm.s] Error 1 Error: pointer size mismatch in cross-build. Try: make HOST_CC=gcc -m32 CROSS=... make[1]: *** Waiting for unfinished jobs make[1]: *** [lj_ffdef.h] Error 1 Error: pointer size mismatch in cross-build. Try: make HOST_CC=gcc -m32 CROSS=... make[1]: *** [lj_bcdef.h] Error 1 make[1]: Leaving directory `/yocto/work001/fnst/lixin/poky/build.x86/tmp/work/i586-poky-linux/luajit/2.0.3-r0/LuaJIT-2.0.3/src' make: *** [default] Error 2 ERROR: oe_runmake failed WARNING: /yocto/work001/fnst/lixin/poky/build.x86/tmp/work/i586-poky-linux/luajit/2.0.3-r0/temp/run.do_compile.14752:1 exit 1 from exit 1 ERROR: Function failed: do_compile (log file is located at /yocto/work001/fnst/lixin/poky/build.x86/tmp/work/i586-poky-linux/luajit/2.0.3-r0/temp/log.do_compile.14752) [lixin@ubinux-yocto-15 temp]$ -- -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Albert K Sent: Monday, September 29, 2014 1:34 PM To: Khem Raj Cc: yocto@yoctoproject.org Subject: Re: [yocto] Luajit Compile Error Dear Sir, Thanks a million. Adding the gcc-multilib to the build host did the trick. Works like a charm. Thanks again. On Mon, Sep 29, 2014 at 12:57 PM, Khem Raj raj.k...@gmail.com wrote: On Sun, Sep 28, 2014 at 7:22 PM, Albert K alb...@gmail.com wrote: Dear all, I am getting error when i include luajit package from the meta-embedded and this is build from the core-image-minimal layer(yocto daisy). Can someone help to point me the right direction for fixing the compile error as show below? Thanks. its expecting 32bit gcc to be available on your build host. So install gcc-multilib on build machine and it should go on. yocto@ubuntu-yocto:/yocto/poky/build/tmp/work/i586-poky-linux/luajit/ 2.0.2-r0/temp$ cat log.do_compile.16806 DEBUG: Executing shell function do_compile NOTE: make -j 4 CROSS=i586-poky-linux- TARGET_CFLAGS= --sysroot=/yocto/poky/build/tmp/sysroots/qemux86 TARGET_LDFLAGS= --sysroot=/yocto/poky/build/tmp/sysroots/qemux86 TARGET_SHLDFLAGS= --sysroot=/yocto/poky/build/tmp/sysroots/qemux86 HOST_CC=gcc -m32 Building LuaJIT 2.0.2 make -C src make[1]: Entering directory `/yocto/poky/build/tmp/work/i586-poky-linux/luajit/2.0.2-r0/LuaJIT-2.0.2/src' HOSTCChost/minilua.o HOSTCChost/buildvm_asm.o HOSTCChost/buildvm_peobj.o HOSTCChost/buildvm_lib.o In file included from host/buildvm_peobj.c:9:0: host/buildvm.h:9:23: fatal error: sys/types.h: No such file or directory #include sys/types.h ^ In file included from host/buildvm_asm.c:6:0: host/buildvm.h:9:23: fatal error: sys/types.h: No such file or directory #include sys/types.h ^ compilation terminated. In file included from host/buildvm_lib.c:6:0: host/buildvm.h:9:23: fatal error: sys/types.h: No such file or directory #include sys/types.h ^ compilation terminated. compilation terminated. make[1]: *** [host/buildvm_asm.o] Error 1 make[1]: *** Waiting for unfinished jobs make[1]: *** [host/buildvm_peobj.o] Error 1 make[1]: *** [host/buildvm_lib.o] Error 1 In file included from /usr/include/limits.h:25:0, from /usr/lib/gcc/x86_64-linux-gnu/4.8/include-fixed/limits.h:168, from /usr/lib/gcc/x86_64-linux-gnu/4.8/include-fixed/syslimits.h:7, from /usr/lib/gcc/x86_64-linux-gnu/4.8/include-fixed/limits.h:34, from host/minilua.c:32: /usr/include/features.h:374:25: fatal error: sys/cdefs.h: No such file or directory # include sys/cdefs.h ^ compilation terminated. make[1]: *** [host/minilua.o] Error 1 make[1]: Leaving directory `/yocto/poky/build/tmp/work/i586-poky-linux/luajit/2.0.2-r0/LuaJIT-2.0.2/src' make: *** [default] Error 2 ERROR: oe_runmake
Re: [yocto] Yocto Daisy - Beaglebone Black - core-image-minimal - Error: do_compile
Dear Paul Eggleton, Thanks for the help. That seems to work! Have a good day. Regards, Prashanth On Fri, 24 Oct 2014 19:31:02 +0530 Paul Eggletonlt;paul.eggle...@linux.intel.comgt; wrote On Friday 24 October 2014 17:10:19 prashanthg wrote: gt; @PaulEggleton Thanks a lot. I tried 'bitbake -c clean file-native' but it gt; didn't seem to solve the issue. Ah right, I now know how to trigger this. Did you perhaps switch from the dora to the daisy branch whilst keeping your existing TMPDIR? I would recommend you delete just your TMPDIR (by default the tmp directory under your build directory) and then try again. There was a change between dora and daisy that meant that the system could not remove old files from the sysroot, and thus the old magic file was getting in the way. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] PERL5LIB not properly reflecting target_sdk_dir
Dear Joseph Andrew de la Peña, In message cajrrhk4q_bnrv2g1kup9btjj9gvmufkmsltmbx8k5hmp7me...@mail.gmail.com you wrote: anyone? I confirm the problem. I have seen a problem in SDK installation where PERL5LIB does not reflect vendor_perl location. I have specified SDK installtion path as /bonus/scratch/sdk. Yet when I executed -V no vendor_perl is included in PERL5LIB. To be more precise, PERL5LIB is not set in the environment, and the installation routine cannot fix the built-in strings in the perl binary. @INC: /bonus/scratch/sdk/sysroots/i686-pokysdk-linux//usr/lib/perl/5.14.3 /bonus/scratch/sdk/sysroots/i686-pokysdk-linux//usr/lib/perl /bonus/scratch/sdk/sysroots/i686-pokysdk-linux//usr/lib/perl/5.14.3 /opt/sdk/1.5.1/sysroots/i686-pokysdk-linux//usr/lib/perl/site_perl/5.14.3/ /opt/sdk/1.5.1/sysroots/i686-pokysdk-linux//usr/lib/perl/site_perl/5.14.3 /opt/sdk/1.5.1/sysroots/i686-pokysdk-linux//usr/lib/perl/vendor_perl/5.14.3/ /opt/sdk/1.5.1/sysroots/i686-pokysdk-linux//usr/lib/perl/vendor_perl/5.14.3 /opt/sdk/1.5.1/sysroots/i686-pokysdk-linux//usr/lib/perl/5.14.3/ /opt/sdk/1.5.1/sysroots/i686-pokysdk-linux//usr/lib/perl/5.14.3 /opt/sdk/1.5.1/sysroots/i686-pokysdk-linux//usr/lib/perl/5.14.3 As you can see, even though you install into a non-standard directory (/bonus/scratch/sdk), perl still references the built-in path (/opt/sdk/...). The problem is present in all versions of Yocto, up to and including the upcoming 1.7. I've opened a bug for it, see https://bugzilla.yoctoproject.org/show_bug.cgi?id=6890 Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You know, after a woman's raised a family and so on, she wants to start living her own life. Whose life she's _been_ living, then? - Terry Pratchett, _Witches Abroad_ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [PATCH] opkg-utils: update-alternatives fails for [ and [[ in busybox
On 27 October 2014 09:35, Liu Jian jian@windriver.com wrote:
Building a small filesystem with busybox gives the following error lines:
sed: -e expression #1, char 41: unterminated address regex
sed: -e expression #1, char 42: unterminated address regex
This is caused by the script update-alternatives.
[ can not be used directly in sed expression.
Signed-off-by: Jian Liu jian@windriver.com
---
...andle-leftbracket-for-update-alternatives.patch | 25
++
meta/recipes-devtools/opkg-utils/opkg-utils_git.bb | 4 +++-
2 files changed, 28 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-devtools/opkg-utils/opkg-utils/handle-leftbracket-for-update-alternatives.patch
diff --git
a/meta/recipes-devtools/opkg-utils/opkg-utils/handle-leftbracket-for-update-alternatives.patch
b/meta/recipes-devtools/opkg-utils/opkg-utils/handle-leftbracket-for-update-alternatives.patch
new file mode 100644
index 000..0cdc4e2
--- /dev/null
+++
b/meta/recipes-devtools/opkg-utils/opkg-utils/handle-leftbracket-for-update-alternatives.patch
@@ -0,0 +1,25 @@
+[ should be escaped in sed expression. This patch is suitable for
opkg-0.2.2
+
+diff -Nur utils.orig/update-alternatives utils/update-alternatives
+--- utils.orig/update-alternatives 2013-08-16 04:22:29.0 +0800
utils/update-alternatives 2014-09-19 10:55:22.238159317 +0800
+@@ -68,6 +68,10 @@
+ sed -e 's/\//\\\//g'
+ }
+
++protect_special_character() {
++ sed -e 's/\[/\\\[/g'
++}
++
+ remove_alt() {
+ [ $# -lt 2 ] return 1
+ local name=$1
+@@ -75,7 +79,7 @@
+
+ [ ! -f $ad/$name ] return 0
+
+- path=`echo $path | protect_slashes`
++ path=`echo $path | protect_slashes | protect_special_character`
+ sed -ne /^$path\.*/!p $ad/$name $ad/$name.new
+ mv $ad/$name.new $ad/$name
+ }
diff --git a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
index 693c216..04412d1 100644
--- a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
+++ b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
@@ -10,7 +10,9 @@ PROVIDES += virtual/update-alternatives
SRCREV = eae0d8fa44e8594aa90eadf06e5f4fbeef314509
PV = 0.1.8+git${SRCPV}
-SRC_URI = git://git.yoctoproject.org/opkg-utils
+SRC_URI = git://git.yoctoproject.org/opkg-utils \
+ file://handle-leftbracket-for-update-alternatives.patch \
+
S = ${WORKDIR}/git
--
1.8.5.2.233.g932f7e4
Sorry, you've sent a patch for oe-core to the wrong mailing lists here.
Also, this patch doesn't apply against oe-core anyway, it looks like
your email program has corrupted it by wrapping lines. Please use 'git
send-email' if you can.
To make this change, please submit a patch for opkg-utils itself
rather than for oe-core. In oe-core, we can then simply change SRCREV
rather than holding additional patches.
Thanks,
--
Paul Barker
Email: p...@paulbarker.me.uk
http://www.paulbarker.me.uk
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [PATCH] opkg-utils: update-alternatives fails for [ and [[ in busybox
On 27 October 2014 09:52, Paul Barker p...@paulbarker.me.uk wrote: Sorry, you've sent a patch for oe-core to the wrong mailing lists here. Also, this patch doesn't apply against oe-core anyway, it looks like your email program has corrupted it by wrapping lines. Please use 'git send-email' if you can. To make this change, please submit a patch for opkg-utils itself rather than for oe-core. In oe-core, we can then simply change SRCREV rather than holding additional patches. Thanks, Actually, that's a bit short worded. Hope it doesn't sound harsh, getting patches in the right format to the right list can be a pain if you're new to the project. If you've got any questions just ask, either on the mailing list or on IRC. I or someone else should be able to help you out. Thanks, -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [error-report-web][PATCH] parser: Check for tag markup in the metadata fields
Before we commit the error report metadata to the database do a rudimentary check on all fields that are passed to the graphs page to avoid any XSS happening. Signed-off-by: Michael Wood michael.g.w...@intel.com --- Post/parser.py | 13 + 1 file changed, 13 insertions(+) diff --git a/Post/parser.py b/Post/parser.py index fae9194..b180165 100644 --- a/Post/parser.py +++ b/Post/parser.py @@ -18,8 +18,21 @@ class Parser: def __init__(self, data): self.data = data +# returns true if the values contain '' char +# Ignore the failures field (which is an array anyway) +def contains_tags (self, data): +for key,val in data.items(): +if key == 'failures': +continue + +if '' in val: +return True +return False + def parse(self): jsondata = json.loads(self.data) +if self.contains_tags(jsondata) == True: +return MACHINE_NAME = str(jsondata['machine']) NATIVELSBSTRING = str(jsondata['nativelsb']) -- 1.9.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Is the build system SCM sensitive?
I had a complete build (details probably don't matter) using Poky master. I'm working on a fix to one of the core recipes, so I made a local branch: % git checkout -b fix-python-pygtk master I made a single line change in the recipe (removing a line from the do_install step). When I then rebuilt the recipe, to my surprise, there were more than 450 tasks (73 unique recipes) executed :-( How does this make any sense? unless the build system cares that I changed the branch? n.b. I'm happy to provide more details if necessary. Also, I did this twice in two different build trees and saw the same strangeness. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Best practices for changing a conf file
Hi all, I'm just looking for some advice on best practices. I want to change the configuration file for rsyslog called rsyslog.conf (poky/meta/recipes-extended/rsyslog), but there is a certain appeal to me of not changing the files in the meta directory. I like to keep those pristine and accomplish everything I need with recipes in a different layer. Is the best way to change this file to just go in and change that .conf file, or is there an easy way to use a .bbappend file to substitute my own configuration file? Thanks, -Nick Nick Crast Associate Software Engineer Saab Sensis Corporation Phone: 315-445-5703 Email: nicholas.cr...@saabsensis.commailto:nicholas.cr...@saabsensis.com This message is intended only for the addressee and may contain information that is company confidential or privileged. Any technical data in this message may be exported only in accordance with the U.S. International Traffic in Arms Regulations (22 CFR Parts 120-130) or the Export Administration Regulations (15 CFR Parts 730-774). Unauthorized use is strictly prohibited and may be unlawful. If you are not the intended recipient, or the person responsible for delivering to the intended recipient, you should not read, copy, disclose or otherwise use this message. If you have received this email in error, please delete it, and advise the sender immediately. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Is the build system SCM sensitive?
On 10/27/2014 09:50 AM, Gary Thomas wrote: I had a complete build (details probably don't matter) using Poky master. I'm working on a fix to one of the core recipes, so I made a local branch: % git checkout -b fix-python-pygtk master I made a single line change in the recipe (removing a line from the do_install step). When I then rebuilt the recipe, to my surprise, there were more than 450 tasks (73 unique recipes) executed :-( How does this make any sense? unless the build system cares that I changed the branch? n.b. I'm happy to provide more details if necessary. Also, I did this twice in two different build trees and saw the same strangeness. I think so additional info might be needed here, I am guessing that you are changing pygtk and somehow that is changing some dependency, you might try using bitbake-diffsigs between the 2 versions. Sau! -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Best practices for changing a conf file
Hi Nick,
On Mon, 27 Oct 2014 17:25:41 + Crast, Nicholas
nicholas.cr...@saabsensis.com wrote:
I’m just looking for some advice on best practices. I want to change
the configuration file for rsyslog called rsyslog.conf
(poky/meta/recipes-extended/rsyslog), but there is a certain appeal to
me of not changing the files in the meta directory. I like to keep
those pristine and accomplish everything I need with recipes in a
different layer. Is the best way to change this file to just go in and
change that .conf file, or is there an easy way to use a .bbappend
file to substitute my own configuration file?
I think the best approach is to add a bbappend file to your layer, which
installs your own config file.
If the config file is already in SRC_URI (like rsyslog's), it's just a
matter of creating a .bbappend like this:
$ cat rsyslog_%.bbappend
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
, and adding your custom config file to the ${PN} directory (i.e.,
rsyslog/rsyslog.conf). So, you'll have something like that in your
layer:
recipes-extended/
recipes-extended/rsyslog/
recipes-extended/rsyslog/rsyslog/
recipes-extended/rsyslog/rsyslog_%.bbappend
recipes-extended/rsyslog/rsyslog/rsyslog.conf
Best wishes.
Mario
--
http://www.ossystems.com.br
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Is the build system SCM sensitive?
On 2014-10-27 12:03, Saul Wold wrote: On 10/27/2014 09:50 AM, Gary Thomas wrote: I had a complete build (details probably don't matter) using Poky master. I'm working on a fix to one of the core recipes, so I made a local branch: % git checkout -b fix-python-pygtk master I made a single line change in the recipe (removing a line from the do_install step). When I then rebuilt the recipe, to my surprise, there were more than 450 tasks (73 unique recipes) executed :-( How does this make any sense? unless the build system cares that I changed the branch? n.b. I'm happy to provide more details if necessary. Also, I did this twice in two different build trees and saw the same strangeness. I think so additional info might be needed here, I am guessing that you are changing pygtk and somehow that is changing some dependency, you might try using bitbake-diffsigs between the 2 versions. I think I know what triggered this - a recent change in bitbake.conf redefined BUILD_CPP (and others). I had merged this change some six hours before my strange build and had been building many other recipes (also python with a similar set of dependencies) a number of times before I touched the python-pygtk recipe. Some dependency in that recipe set off the rebuild storm that my other recipes had not. So the large number of recipe rebuilds was [probably] warranted, but very unexpected given what I had been doing just prior. Sorry for the noise. Next time I'll try and remember bitbake-diffsigs and figure things out on my own. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Is the build system SCM sensitive?
On 27 October 2014 19:40, Gary Thomas g...@mlbassoc.com wrote: I think I know what triggered this - a recent change in bitbake.conf redefined BUILD_CPP (and others). I had merged this change some six hours before my strange build and had been building many other recipes (also python with a similar set of dependencies) a number of times before I touched the python-pygtk recipe. Some dependency in that recipe set off the rebuild storm that my other recipes had not. Ah yes, welcome back to master. There's been stuff building up for a while. :) This is where I point out that master between a release and M1 is known to be volatile. Whilst we obviously endeavour for it to be always buildable, deep and fundamental changes will be going in sooner rather than later. (ie this might be time to dust of my libexecdir-changing series) Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Strange ptest failure
I'm seeing a very strange failure on one of my build hosts.
This is my configuration:
BB_VERSION= 1.24.0
BUILD_SYS = i686-linux
NATIVELSBSTRING = Fedora-17
TARGET_SYS= arm-poky-linux-gnueabi
MACHINE = qemuarm
DISTRO= poky
DISTRO_VERSION= 1.7
TUNE_FEATURES = arm armv5 thumb dsp
TARGET_FPU= soft
meta
meta-yocto
meta-yocto-bsp= master:dacc4ce59e48129a1a1e5316e10780f7358e29ef
One one build host, I'm running a rather old Fedora 13. I've also
tried this on Ubuntu 13.10 and Fedora 17. The problem is that a
big chunk of the run.do_install_ptest_base script goes missing on
the Fedora 13 box:
--- /tmp/run.do_install_ptest_base.BAD 2014-10-27 17:50:42.803192266 -0600
+++ /tmp/run.do_install_ptest_base.OK 2014-10-27 17:48:42.507192280 -0600
@@ -119,6 +119,37 @@
}
+oe_runmake() {
+ oe_runmake_call $@ || die oe_runmake failed
+
+}
+
+do_install_ptest() {
+
t=/local/qemu_test/tmp/work/armv5te-poky-linux-gnueabi/diffutils/3.3-r0/image/usr/lib/diffutils/ptest
+ install -D
/local/qemu_test/tmp/work/armv5te-poky-linux-gnueabi/diffutils/3.3-r0/diffutils-3.3/build-aux/test-driver
$t/build-aux/test-driver
+ cp -r
/local/qemu_test/tmp/work/armv5te-poky-linux-gnueabi/diffutils/3.3-r0/diffutils-3.3/tests
$t/
+ install
/local/qemu_test/tmp/work/armv5te-poky-linux-gnueabi/diffutils/3.3-r0/build/tests/Makefile
$t/tests/
+ sed -e 's|^Makefile:|_Makefile:|' \
+ -e 's|bash|sh|' \
+ -e 's|^top_srcdir = \(.*\)|top_srcdir = ..\/|' \
+ -e 's|^srcdir = \(.*\)|srcdir = .|' \
+ -e 's|`$(built_programs)`|diff|' \
+ -e 's|gawk|awk|g' \
+ -i $t/tests/Makefile
+
+}
+
+die() {
+ bbfatal $*
+
+}
+
+oe_runmake_call() {
+ bbnote make $@
+ make $@
+
+}
+
bbfatal() {
echo ERROR: $*
exit 1
I can't for the life of me figure out how this chunk of code
can just go missing. There are many other recipes in my build
(core-image-minimal) that use ptest and they all succeed.
Any ideas what this could be? Or at least how I might discover
what's happening?
n.b. I know this is a really old host O.S. but I'm a bit leery
to update it at this time.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
#!/bin/sh
# Emit a useful diagnostic if something fails:
bb_exit_handler() {
ret=$?
case $ret in
0) ;;
*) case $BASH_VERSION in
) echo WARNING: exit code $ret from a shell command.;;
*)echo WARNING: ${BASH_SOURCE[0]}:${BASH_LINENO[0]} exit $ret from
$BASH_COMMAND;;
esac
exit $ret
esac
}
trap 'bb_exit_handler' 0
set -e
export prefix=/usr
export PSEUDO_DISABLED=0
export STRIP=arm-poky-linux-gnueabi-strip
export localstatedir=/var
export BUILD_CC=gcc
export USER=gary
export libexecdir=/usr/lib/diffutils
export PKG_CONFIG_SYSROOT_DIR=/local/qemu_test/tmp/sysroots/qemuarm
export BUILD_CXX=g++
export LD=arm-poky-linux-gnueabi-ld
--sysroot=/local/qemu_test/tmp/sysroots/qemuarm
export LDFLAGS=-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed
export TARGET_CXXFLAGS= -O2 -pipe -g -feliminate-unused-debug-types
export MAKE=make
export includedir=/usr/include
export BUILD_LDFLAGS=-L/local/qemu_test/tmp/sysroots/i686-linux/usr/lib
-L/local/qemu_test/tmp/sysroots/i686-linux/lib
-Wl,-rpath-link,/local/qemu_test/tmp/sysroots/i686-linux/usr/lib
-Wl,-rpath-link,/local/qemu_test/tmp/sysroots/i686-linux/lib
-Wl,-rpath,/local/qemu_test/tmp/sysroots/i686-linux/usr/lib
-Wl,-rpath,/local/qemu_test/tmp/sysroots/i686-linux/lib -Wl,-O1
unset TARGET_ARCH
export STRINGS=arm-poky-linux-gnueabi-strings
export CCACHE_DIR=/home/gary
export BUILD_LD=ld
export oldincludedir=/usr/include
export PSEUDO_PREFIX=/local/qemu_test/tmp/sysroots/i686-linux/usr
export BUILD_CCLD=gcc
export
CFLAGS_FOR_BUILD=-isystem/local/qemu_test/tmp/sysroots/i686-linux/usr/include
-O2 -pipe
export
BUILD_CFLAGS=-isystem/local/qemu_test/tmp/sysroots/i686-linux/usr/include -O2
-pipe
export
PSEUDO_LOCALSTATEDIR=/local/qemu_test/tmp/work/armv5te-poky-linux-gnueabi/diffutils/3.3-r0/pseudo/
export
CXXFLAGS_FOR_BUILD=-isystem/local/qemu_test/tmp/sysroots/i686-linux/usr/include
-O2 -pipe
export docdir=/usr/share/doc
export infodir=/usr/share/info
export base_prefix=
export CC=arm-poky-linux-gnueabi-gcc -march=armv5te -marm -mthumb-interwork
--sysroot=/local/qemu_test/tmp/sysroots/qemuarm
export TERM=xterm
export TARGET_CFLAGS= -O2 -pipe -g -feliminate-unused-debug-types
export CPPFLAGS=
export BUILD_CPP=gcc -E
export RANLIB=arm-poky-linux-gnueabi-ranlib
export base_sbindir=/sbin
export CXX=arm-poky-linux-gnueabi-g++ -march=armv5te -marm -mthumb-interwork
--sysroot=/local/qemu_test/tmp/sysroots/qemuarm
export HOME=/home/gary
export BUILD_RANLIB=ranlib
export BUILD_NM=nm
[yocto] How to get fw_env.config installed
I'm working on including the u-boot fw utility tools in my image, specifically
fw_printenv and fw_setenv.
For these to work the file fw_env.config needs to be placed at
/etc/fw_env.config.
I can see in oe-core/meta/recipes-bsp/u-boot/u-boot.inc there is a test that if
fw_env.config is in the working dir it will be installed in ${sysconfdir} and I
can see in the meta-ti/recipes-bsp/u-boot/u-boot-beagleboard_2011.09.bb they
simply include file://fw_env.conf in the SRC_URI list to get the file in the
working dir.
So I created a bbappend file for the ti u-boot recipe
(u-boot-ti-staging_2013.10.bb) that I'm using and build and I don't get the
file in my image root filesystem.
If I run bitbake -c install virtual/bootloader I can see that the file does get
copied into u-boot's working dir image/etc directory but it never makes it into
the final root filesystem.
What am I missing?
Thanks,
Matt S.
PS I should note that I'm working Dylan branch with the TI Arago layer.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
