Re: [yocto] RFC: Backwards compatibility checking sstate-cache
I haven't tried the patches, but I really like this idea (I was suggesting something like that since 2011 http://permalink.gmane.org/gmane.comp.handhelds.openembedded.core/10327) and I'm glad you weren't discouraged attempting to do this. It also implements 3) b) idea from https://bugzilla.yoctoproject.org/show_bug.cgi?id=5970 , you might be interested read that ticket. Thanks On Fri, Jun 30, 2017 at 11:48 AM, Michael Ho wrote: > Hi, at BMW Car IT we are working on an experimental feature to improve > sstate > cache hits and we are looking for comments on the approach who might have > some > insights to the problem and seeing if anyone is interested in the feature > for > mainline. > > The sstate-cache of a recipe is tied closely to its build dependencies, as > the > signature generated for a task includes all parent task's signatures as > part of > the signature information. This means that when changes occur in the parent > recipes, even if insignificant, all children recipes that have valid sstate > cache must invalidate their sstate cache objects. > > What this patchset does is propose to add another optional variable to > recipes, > CDEPENDS, which acts like DEPENDS for all RunQueue purposes but for > signature > generation it excludes any parent tasks that come from dependencies listed > in > it. This is to break the signature change domino effect. > > This patchset also proposes modifying RunQueue to then be able to run a > compatibility checker during task execution phase for recipes and tasks > that use > CDEPENDS and allow for deciding to re-execute a task despite being covered > by > sstate-cache. > > The patchset is based on the jethro branch for the poky repository, as > this is > the branch that we are using. If the general idea sounds good, we can > consider > porting it to master. > > Included is an patch that adds an example recipe and compatibility checker, > where compatibility is based on the file checksums of the parent recipes > packages. An example recipe, cdepends-test1, generates a compatibility > report > containing the file checksums of all files that it packages and which file > paths > they are at. Another recipe, cdepends-test2, can then strip this > compatibility > report to the minimal files it needs to be consistent and can compare the > latest > checksums it used to configure/compile/install with and if they have > changed, > trigger a rebuild. If not, the previous version restored from sstate-cache > is > used. > > We are still experimenting with the usages of this, including the use of > having > abi-compliance-checker to compare the ABI of shared libraries as a > compatibility > checker during RunQueue and using the results to avoid rebuilding child > recipes > when the .so files they depend on are still compatible. Example use cases > of > this are allowing recipes which provide multiple shared libraries to > change a > single .so file without rebuilding all its children that depend on the > other > shared libraries but not the one that changed. > > We're aware of the SIGGEN_EXCLUDERECIPES_ABISAFE feature but feel it > didn't meet > the feature requirements of what this compatibility checker callback is > doing, > although maybe when porting to master we could refactor to make better use > of > the work already done there. The current implementation is a bit hacky but > comments would be appreciated in regards to if the concept is feasible and > if > people are interested in making use of it and their use cases. > > Kind regards, > Michael Ho > > -- > BMW Car IT GmbH > Michael Ho > Spezialist Entwicklung - Linux Software Integration > Lise-Meitner-Str. 14 > 89081 Ulm > > Tel.: +49 731 3780 4071 > Mobil: +49 152 5498 0471 > Fax: +49-731-37804-001 > Mail: michael...@bmw-carit.de > Web: http://www.bmw-carit.de > > BMW Car IT GmbH > Gechäftsführer: Kai-Uwe Balszuweit und Alexis Trolin > Sitz und Registergericht: München HRB 134810 > > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] Added missing LDFLAGS in sample recipe for morty branch
This problem causes the following error :
ERROR: example-0.1-r0 do_package_qa: QA Issue: No GNU_HASH in the elf binary
Signed-off-by: Pierre FICHEUX
---
.../target/arch/layer/recipes-example/example/example-recipe-0.1.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/scripts/lib/bsp/substrate/target/arch/layer/recipes-example/example/example-recipe-0.1.bb
b/scripts/lib/bsp/substrate/target/arch/layer/recipes-example/example/example-recipe-0.1.bb
index 5fbf594..e534d36 100644
---
a/scripts/lib/bsp/substrate/target/arch/layer/recipes-example/example/example-recipe-0.1.bb
+++
b/scripts/lib/bsp/substrate/target/arch/layer/recipes-example/example/example-recipe-0.1.bb
@@ -14,7 +14,7 @@ SRC_URI = "file://helloworld.c"
S = "${WORKDIR}"
do_compile() {
-${CC} helloworld.c -o helloworld
+${CC} ${LDFLAGS} helloworld.c -o helloworld
}
do_install() {
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Raspberrypi3 with Kodi (as an exercise)
Hi everybody, I'm completely new to the Yocto project, just started playing with it and my rpi3 two days ago. As an exercise to learn how Yocto works, I'm trying to build a rpi image which can launch kodi. Right now I'm able of building an image which contains kodi,but when I try to launch it, it fails. It says that it cannot create the GUI. (I have tried kodi, kodi --standalone and kodi-standadlone, same result) In order to build the image, I had to add MACHINE_FEATURES += "vc4graphics" so it gets mesa as egl, gl and opengl provider. If I dont add that feature, kodi complains about not finding egl during configuration. I dont understand why it complains, since userland (the default) its a egl provider (as it says in the recipe at least, probably I am understanding something incorrectly). Could you please guide me a little bit with this? As I said, it's my first time playing with embedded devices and with yocto, so some explanations would be nice :-) Thanks! -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-java] Illegal instruction building jaxp1.3
Hello! I'm trying to add openjre-8 to my armv8 image. When I try to build, it seems to fail with this error: http://paste.ubuntu.com/24996638/. Illegal instruction seems to suggest it was built for another architecture. I tried to investigate a bit and it seems like the javac being used is not the system one, is this correct? I checked the javac executable being used and it seems to execute properly. I also tried to simply replace the javac command in the do_compile phase with /usr/bin/javac and the package builds properly. Any idea what is happening and how to fix properly? Regards. Luca -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] Added missing LDFLAGS in sample recipe for morty branch
On 7/1/17 12:52 AM, Pierre FICHEUX wrote:
> This problem causes the following error :
>
> ERROR: example-0.1-r0 do_package_qa: QA Issue: No GNU_HASH in the elf binary
>
> Signed-off-by: Pierre FICHEUX
> ---
> .../target/arch/layer/recipes-example/example/example-recipe-0.1.bb | 2
> +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
> a/scripts/lib/bsp/substrate/target/arch/layer/recipes-example/example/example-recipe-0.1.bb
>
> b/scripts/lib/bsp/substrate/target/arch/layer/recipes-example/example/example-recipe-0.1.bb
> index 5fbf594..e534d36 100644
> ---
> a/scripts/lib/bsp/substrate/target/arch/layer/recipes-example/example/example-recipe-0.1.bb
> +++
> b/scripts/lib/bsp/substrate/target/arch/layer/recipes-example/example/example-recipe-0.1.bb
> @@ -14,7 +14,7 @@ SRC_URI = "file://helloworld.c"
> S = "${WORKDIR}"
>
> do_compile() {
> - ${CC} helloworld.c -o helloworld
> + ${CC} ${LDFLAGS} helloworld.c -o helloworld
perhaps doing compile and link in two steps where CFLAGS and LDFLAGS are
used would be clearer
something like
${CC} ${CFLAGS} -c helloworld.c -o helloworld.o
${LD} ${LDFLAGS} helloworld.o -o helloworld
> }
>
> do_install() {
>
signature.asc
Description: OpenPGP digital signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Raspberrypi3 with Kodi (as an exercise)
On 7/1/17 4:10 AM, Juan José Casafranca wrote: > Hi everybody, > > I'm completely new to the Yocto project, just started playing with it > and my rpi3 two days ago. > > As an exercise to learn how Yocto works, I'm trying to build a rpi image > which can launch kodi. > > Right now I'm able of building an image which contains kodi,but when I > try to launch it, it fails. It says that it cannot create the GUI. (I > have tried kodi, kodi --standalone and kodi-standadlone, same result) > do you have x11 and opengl in your DISTRO_FEATURES ? you can check it with bitbake -e kodi | grep -e "^DISTRO_FEATURES=" > In order to build the image, I had to add > > MACHINE_FEATURES += "vc4graphics" so it gets mesa as egl, gl and opengl > provider. > it should work with both userland and vc4graphics. > If I dont add that feature, kodi complains about not finding egl during > configuration. I dont understand why it complains, since userland (the > default) its a egl provider (as it says in the recipe at least, probably > I am understanding something incorrectly). > > Could you please guide me a little bit with this? As I said, it's my > first time playing with embedded devices and with yocto, so some > explanations would be nice :-) This is good section to work on in OE in general. > > > Thanks! > signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Raspberrypi3 with Kodi (as an exercise)
Ive just tried adding X11 as you suggested (opengl was already added) but still not working. Something strange I'm finding is that there isn't any libGL.so in /usr/lib (in the rpi device). There is a libGLESv2. I'm not sure what I'm doing wrong. I have also tried to add Qt to the image to see if I can launch a qml example, but it's not even generating the image. It complains it cannot find any opengl or gles implementation :S On 01/07/17 17:08, Khem Raj wrote: On 7/1/17 4:10 AM, Juan José Casafranca wrote: Hi everybody, I'm completely new to the Yocto project, just started playing with it and my rpi3 two days ago. As an exercise to learn how Yocto works, I'm trying to build a rpi image which can launch kodi. Right now I'm able of building an image which contains kodi,but when I try to launch it, it fails. It says that it cannot create the GUI. (I have tried kodi, kodi --standalone and kodi-standadlone, same result) do you have x11 and opengl in your DISTRO_FEATURES ? you can check it with bitbake -e kodi | grep -e "^DISTRO_FEATURES=" In order to build the image, I had to add MACHINE_FEATURES += "vc4graphics" so it gets mesa as egl, gl and opengl provider. it should work with both userland and vc4graphics. If I dont add that feature, kodi complains about not finding egl during configuration. I dont understand why it complains, since userland (the default) its a egl provider (as it says in the recipe at least, probably I am understanding something incorrectly). Could you please guide me a little bit with this? As I said, it's my first time playing with embedded devices and with yocto, so some explanations would be nice :-) This is good section to work on in OE in general. Thanks! -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-autobuilder][PATCH] ScrapeTargets.py: improve target search algorithm
When scraping the build targets from refkit-ci.inc, grep would only
return the first line of the search result. By replacing grep with
awk, we are now searching for multi-line variables, and should now
scrape build targets even if they have line breaks between them.
Signed-off-by: Stephano Cetola
---
.../site-packages/autobuilder/buildsteps/ScrapeTargets.py| 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git
a/lib/python2.7/site-packages/autobuilder/buildsteps/ScrapeTargets.py
b/lib/python2.7/site-packages/autobuilder/buildsteps/ScrapeTargets.py
index 80153fe85..c5a2f8d6d 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/ScrapeTargets.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/ScrapeTargets.py
@@ -41,7 +41,9 @@ class ScrapeTargets(ShellCommand):
workerdir = os.path.join(os.path.join(YOCTO_ABBASE, "yocto-worker"))
buildername = self.getProperty("buildername")
src = os.path.join(workerdir, buildername, "build", self.source)
-self.command = "cat " + src + " | grep " + self.targetsvar
+# find targetsvar=", skip a line, then return lines up to a quote
+self.command = ["awk",
+'/%s="/{flag=1;next}/"/{flag=0}flag' % self.targetsvar, src]
ShellCommand.start(self)
def commandComplete(self, cmd):
@@ -49,10 +51,7 @@ class ScrapeTargets(ShellCommand):
return
result = cmd.logs['stdio'].getText()
-targets = result.replace(self.targetsvar, "")
-targets = targets.strip()
-targets = targets.replace('=', '')
-targets = targets.strip('"')
+targets = result.strip()
self.setProperty("scraped_targets",
targets,
'Targets "%s" scraped from %s' % (targets,
--
2.13.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RPi app built with SDK won't load
> From: Andrea Galbusera [mailto:giz...@gmail.com]
>
> Could you please post the exact source code of your test
> program and the steps you take to (a) build the SDK and (b)
> build your test executable? Is your running image a pretty
> standard one (core-image-minimal, rpi-test-image or so) or do
> your own with custom features?
It did have some custom features, so I did a plain build of core-image-minimal
using raspberrypi3 as the MACHINE. I also did a populate_sdk for it, and
installed the SDK in /opt/poky/2.2.1-a32 by running the install script.
The test program test.c is just "int main(void) { return 0; }". I normally use
Eclipse CDT to compile native programs, so I set up a cross project using the
SDK, which involves a few manual settings, including telling it the tools are
in /opt/poky/2.2.1-a32/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux,
and adding a --sysroot to the command lines. The compiler command line came out
as:
arm-poky-linux-gcc
--sysroot=/opt/poky/2.2.1-a32/sysroots/cortexa7hf-neon-vfpv4-poky-linux-gnueabi
-O3 -Wall -c -mfloat-abi=hard -MMD -MP -MF"test.d" -MT"test.o" -o "test.o"
"../test.c"
(without the line breaks). I had to add "-mfloat-abi-hard" to get it to link.
The link command line was:
arm-poky-linux-gcc
--sysroot=/opt/poky/2.2.1-a32/sysroots/cortexa7hf-neon-vfpv4-poky-linux-gnueabi
-s -o "test" ./test.o
(again, without the line breaks). After dd-ing the image to my SD card, I
mounted it and manually copied the "test" program into its rootfs. When I stuck
it in the RPi3 and ran it, I got
-sh: ./test: not found
The shell in this case is busybox, so the error message is slightly different
from bash.
I rechecked everything I had described before, analyzing the executable and
comparing it to some working executable from the rootfs. There must be
SOMETHING in my executable that the loader is barfing on, after it's
successfully opened the file but before it starts looking for libraries. But
it's an awfully small executable, so it's hard to imaging where that something
is hiding.
--
Ciao, Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
