Misc build failure fixes

The kernel configuration requires lzma to compress the kernel image (CONFIG_KERNEL_LZMA=y), so add a dependency on xz-native which provides it.

Op 14 mrt. 2012, om 01:36 heeft Paul Eggleton het volgende geschreven:

Quoted 3 lines

The kernel configuration requires lzma to compress the kernel image (CONFIG_KERNEL_LZMA=y), so add a dependency on xz-native which provides it.

Have a look at
https://github.com/Angstrom-distribution/meta-ti/commit/b72cb13fcf83b9d3428
08ea30379bfb6a1321b54 :)

Quoted 5 lines · On Wednesday 14 March 2012 09:21:06 Koen Kooi wrote:

Op 14 mrt. 2012, om 01:36 heeft Paul Eggleton het volgende geschreven:

Quoted 3 lines

The kernel configuration requires lzma to compress the kernel image (CONFIG_KERNEL_LZMA=y), so add a dependency on xz-native which provides it.

Quoted 3 lines

Have a look at
https://github.com/Angstrom-distribution/meta-ti/commit/b72cb13fcf83b9d3428
08ea30379bfb6a1321b54 :)

Right, I thought about that already - but we do not (by default) use defconfigs with linux-yocto*, so you'd have to go through all config fragments with this check. I figured it probably wasn't worth the effort in this case.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

In this case, you wouldn't go through the fragments, you'd just add one that turns it on when you want it. Don't audit a defconfig, push the few options that you want onto the build.

Hi Bruce,

Quoted 3 lines · On Wednesday 14 March 2012 08:29:20 Bruce Ashfield wrote:

In this case, you wouldn't go through the fragments, you'd just add one that turns it on when you want it. Don't audit a defconfig, push the few options that you want onto the build.

I'm not sure what you mean here, in the context of generically figuring out whether lzma is needed...?

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre

You could audit the constructed .config as well, since that's the final word on whether it actually makes it into the kernel build, but also not really required here.

Quoted 3 lines · On Wednesday 14 March 2012 08:59:34 Bruce Ashfield wrote:

You could audit the constructed .config as well, since that's the final word on whether it actually makes it into the kernel build, but also not really required here.

This is what I wanted to do, but I'm assuming the config construction happens far too late to add the dependency.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre

The following changes since commit 81379dc141e245307ca391a02b7490b199128991:

dates: Fix unpackaged files warning (2012-03-13 23:18:19 +0000)

are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib paule/fixes14
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/fixes14

Paul Eggleton (6):
scripts/bitbake: ensure user is in build directory
pulseaudio: add X library dependencies
gst-plugins-bad: disable directfb in configure
mx: add dependencies
ncurses: fix build when ENABLE_WIDEC is not set
linux-yocto-tiny: add dependency on xz-native

If the user is in any directory other than $BUILDDIR when the bitbake wrapper script is run, then show an error an exit.

Fixes [YOCTO #2071].

Signed-off-by Paul Eggleton <[email protected]>

---
 scripts/bitbake |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

scripts/bitbake +0 -0

index dda3b26..45c8697 100755

scripts/bitbake +2 -0

+fi
+
 buildpseudo="1"
 if [ $needpseudo = "1" ] && [ -e "$BUILDDIR/pseudodone" ]; then
     PSEUDOBINDIR=`cat $BUILDDIR/pseudodone`

If wide character support is disabled (as it is with poky-tiny, for example) then we won't have libncursesw.so.*, so skip moving these files in that case. (Fixes a regression introduced in OE-Core revision ccd370ab147b78de7a5bd74818f755f4d3ca6d81).

Signed-off-by Paul Eggleton <[email protected]>

---
 meta/recipes-core/ncurses/ncurses.inc |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

meta/recipes-core/ncurses/ncurses.inc +3 -2

index e450868..fe2c3e4 100644
@@ -6,7 +6,7 @@ LIC_FILES_CHKSUM = "file://ncurses/base/version.c;beginline=1;endline=27;md5=cbc
 SECTION = "libs"
 DEPENDS = "ncurses-native"
 DEPENDS_virtclass-native = ""
-INC_PR = "r5"
+INC_PR = "r6"
 
 inherit autotools binconfig multilib_header
 

@@ -185,7 +185,8 @@ shell_do_install() {
             # case will skip this code
             mkdir ${D}${base_libdir}
             mv ${D}${libdir}/libncurses.so.* ${D}${base_libdir}
-            mv ${D}${libdir}/libncursesw.so.* ${D}${base_libdir}
+            ! ${ENABLE_WIDEC} || \
+                mv ${D}${libdir}/libncursesw.so.* ${D}${base_libdir}
 
             mv ${D}${libdir}/libtinfo.so.* ${D}${base_libdir}
             rm ${D}${libdir}/libtinfo.so

Quoted 5 lines · Paul Eggleton

Quoted 3 lines · On Wednesday 14 March 2012 08:59:34 Bruce Ashfield wrote:

You could audit the constructed .config as well, since that's the final word on whether it actually makes it into the kernel build, but also not really required here.

Quoted 2 lines

This is what I wanted to do, but I'm assuming the config construction happens far too late to add the dependency.

Hmm. probably, I admit to not looking too deeply while trying to get enough coffee into my system to properly think :)

Should this have some kind of prefix? "ERROR: " or something along those lines for consistency with other output?

Quoted 2 lines · On Wednesday 14 March 2012 07:52:01 Darren Hart wrote:

Should this have some kind of prefix? "ERROR: " or something along those lines for consistency with other output?

I did wonder about that; in the end I elected to be consistent with the python version errors in the same script (although I was the one who added those IIRC... heh). Perhaps we ought to add the "ERROR: " prefix to all of the errors in the wrapper script.

If the user is in any directory other than $BUILDDIR when the bitbake wrapper script is run, then show an error an exit.

Fixes [YOCTO #2071].

Signed-off-by Paul Eggleton <[email protected]>

---
 scripts/bitbake |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

scripts/bitbake +5 -0

index dda3b26..45c8697 100755
@@ -47,6 +47,11 @@ float_test() {
 # but earlier versions do not
 float_test "$TARVERSION > 1.23" && needtar="0"
 
+if [ "`pwd`" != "$BUILDDIR" ] ; then
+    echo "BitBake must be run from your build directory: $BUILDDIR"
+    exit 1
+fi
+
 buildpseudo="1"
 if [ $needpseudo = "1" ] && [ -e "$BUILDDIR/pseudodone" ]; then
     PSEUDOBINDIR=`cat $BUILDDIR/pseudodone`

Quoted 2 lines · Paul Eggleton

If the user is in any directory other than $BUILDDIR when the bitbake wrapper script is run, then show an error an exit.

this patch broke my setup.

My $BUILDDIR points to tmp, so that pseudo doesn't get rebuilt for every machine. I have a shared tmp for many machines.

BUILDDIR doesn't seem to have any other use than pointing to the 'pseudodone' file. I don't understand why it's required to run bitbake from there.

Quoted 5 lines · On Thursday 15 March 2012 01:30:31 Andreas Oberritter wrote:

Quoted 2 lines · Paul Eggleton

If the user is in any directory other than $BUILDDIR when the bitbake wrapper script is run, then show an error an exit.

this patch broke my setup.

Ah, sorry about that.

Quoted 2 lines

My $BUILDDIR points to tmp, so that pseudo doesn't get rebuilt for every machine. I have a shared tmp for many machines.

So a couple of things:

1) Unless I'm missing something you can share the same TMPDIR between multiple build directories to get the same result.

2) pseudo is a native package. It shouldn't be rebuilt when changing MACHINE. In fact I just verified by creating a different build directory with only MACHINE changed in the config, it is not rebuilt.

Quoted 3 lines

BUILDDIR doesn't seem to have any other use than pointing to the 'pseudodone' file. I don't understand why it's required to run bitbake from there.

Well, it's required that bitbake is run from the build directory and when you use the setup script as intended that's where BUILDDIR points to. I hadn't anticipated that anyone would be changing BUILDDIR to point to anything other than the build dir, however I don't really think it's a good idea to support that.

Sorry, I messed up some details. In fact, pseudo-native doesn't get rebuilt, but bitbake pseudo-native still gets executed for every machine, unless $BUILDDIR/pseudodone is present and contains PSEUDOBINDIR. This just wastes time and confuses users who receive a message saying "Pseudo is not present but is required, building this first before the main build".

Quoted 9 lines

Quoted 3 lines

BUILDDIR doesn't seem to have any other use than pointing to the 'pseudodone' file. I don't understand why it's required to run bitbake from there.

Well, it's required that bitbake is run from the build directory and when you use the setup script as intended that's where BUILDDIR points to. I hadn't anticipated that anyone would be changing BUILDDIR to point to anything other than the build dir, however I don't really think it's a good idea to support that.

That's because BUILDDIR has no meaning outside oe-core's setup scripts. In scripts/bitbake, BUILDDIR would better be called PSEUDODONEDIR or similar, because that's what the variable really means in this context

In order to verify that scripts/bitbake is called from the build directory, you could as well just check whether $PWD/conf/local.conf exists.

I'm not using oe-core's scripts, because they make assumptions about the directory layout that don't fit my project's needs. I think they are overly complex

and they display texts that seem to suit yocto's needs but at least not mine.

Quoted 6 lines · On Friday 16 March 2012 01:20:44 Andreas Oberritter wrote:

Sorry, I messed up some details. In fact, pseudo-native doesn't get rebuilt, but bitbake pseudo-native still gets executed for every machine, unless $BUILDDIR/pseudodone is present and contains PSEUDOBINDIR. This just wastes time and confuses users who receive a message saying "Pseudo is not present but is required, building this first before the main build".

It takes a small amount of time just once. However if this is really an issue
perhaps we could address it directly rather than hacking around it?

Quoted 5 lines

Quoted 5 lines

Quoted 3 lines

BUILDDIR doesn't seem to have any other use than pointing to the 'pseudodone' file. I don't understand why it's required to run bitbake from there.

Well, it's required that bitbake is run from the build directory and

when

Quoted 8 lines

Quoted 4 lines

you use the setup script as intended that's where BUILDDIR points to. I hadn't anticipated that anyone would be changing BUILDDIR to point to anything other than the build dir, however I don't really think it's a good idea to support that.

That's because BUILDDIR has no meaning outside oe-core's setup scripts. In scripts/bitbake, BUILDDIR would better be called PSEUDODONEDIR or similar, because that's what the variable really means in this context

The naming is such that it should point to the build directory because that's
where pseudodone is meant to be written. I think when it was introduced there
was an idea that it might be useful in other contexts, thus the naming.

Quoted 2 lines

In order to verify that scripts/bitbake is called from the build directory, you could as well just check whether $PWD/conf/local.conf

exists.

Unfortunately it's not that simple. bitbake.conf pulls in local.conf using "include" and not "require", thus it doesn't actually have to exist anywhere.

Quoted 3 lines

I'm not using oe-core's scripts, because they make assumptions about the directory layout that don't fit my project's needs. I think they are overly complex

Could you perhaps elaborate on what needs those scripts are not fulfilling?

Quoted 2 lines

and they display texts that seem to suit yocto's needs but at least not mine.

We print these messages so that people know what to do and where to find further information. I don't think that's unreasonable. However if you have suggestions on how we might improve those messages or allow them to be customised if necessary, we could look at changing them.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Iam not specialist in this. I am just following the steps mentioned here

http://icedtea.classpath.org/wiki/CrossCompileOECoreTutorial

I am building from this path vj@ubuntu:/host/coreembedded/oe-core/build$ and it contains pseudodone file.

and in vj@ubuntu:/host/coreembedded/oe-core/build/conf local.conf exits..

and the same is calling bitbake which is present in scripts..

Quoted 6 lines · On Friday 16 March 2012 01:20:44 Andreas Oberritter wrote:

Sorry, I messed up some details. In fact, pseudo-native doesn't get rebuilt, but bitbake pseudo-native still gets executed for every machine, unless $BUILDDIR/pseudodone is present and contains PSEUDOBINDIR. This just wastes time and confuses users who receive a message saying "Pseudo is not present but is required, building this first before the main build".

It takes a small amount of time just once. However if this is really an issue perhaps we could address it directly rather than hacking around it?

Quoted 10 lines

Quoted 9 lines

Quoted 3 lines

BUILDDIR doesn't seem to have any other use than pointing to the 'pseudodone' file. I don't understand why it's required to run bitbake from there.

Well, it's required that bitbake is run from the build directory and when you use the setup script as intended that's where BUILDDIR points to. I hadn't anticipated that anyone would be changing BUILDDIR to point to anything other than the build dir, however I don't really think it's a good idea to support that.

Quoted 3 lines

That's because BUILDDIR has no meaning outside oe-core's setup scripts. In scripts/bitbake, BUILDDIR would better be called PSEUDODONEDIR or similar, because that's what the variable really means in this context

The naming is such that it should point to the build directory because that's where pseudodone is meant to be written. I think when it was introduced there was an idea that it might be useful in other contexts, thus the naming.

Quoted 2 lines

In order to verify that scripts/bitbake is called from the build directory, you could as well just check whether $PWD/conf/local.conf exists.

Unfortunately it's not that simple. bitbake.conf pulls in local.conf using "include" and not "require", thus it doesn't actually have to exist anywhere.

Quoted 3 lines

I'm not using oe-core's scripts, because they make assumptions about the directory layout that don't fit my project's needs. I think they are overly complex

Could you perhaps elaborate on what needs those scripts are not fulfilling?

Quoted 2 lines

and they display texts that seem to suit yocto's needs but at least not mine.

We print these messages so that people know what to do and where to find further information. I don't think that's unreasonable. However if you have suggestions on how we might improve those messages or allow them to be customised if necessary, we could look at changing them.

If the user is in any directory other than $BUILDDIR when the bitbake wrapper script is run, then show an error an exit.

Fixes [YOCTO #2071].

Signed-off-by Paul Eggleton <[email protected]>

---
 scripts/bitbake |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

scripts/bitbake +5 -0

index dda3b26..45c8697 100755
@@ -47,6 +47,11 @@ float_test() {
 # but earlier versions do not
 float_test "$TARVERSION > 1.23" && needtar="0"
 
+if [ "`pwd`" != "$BUILDDIR" ] ; then
+    echo "BitBake must be run from your build directory: $BUILDDIR"
+    exit 1
+fi
+
 buildpseudo="1"
 if [ $needpseudo = "1" ] && [ -e "$BUILDDIR/pseudodone" ]; then
     PSEUDOBINDIR=`cat $BUILDDIR/pseudodone`

Signature · 7 lines

1.7.5.4


_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Quoted 4 lines · Paul Eggleton

If the user is in any directory other than $BUILDDIR when the bitbake wrapper script is run, then show an error an exit.

Fixes [YOCTO #2071].

angstrom e.g. does not have this restriction but uses script/bitbake so this fix seems to be wrong here since its specific to OE-Core's default build env.

Quoted 6 lines · On Monday 02 April 2012 13:00:15 Khem Raj wrote:

Quoted 4 lines · Paul Eggleton

If the user is in any directory other than $BUILDDIR when the bitbake wrapper script is run, then show an error an exit.

Fixes [YOCTO #2071].

Quoted 3 lines

angstrom e.g. does not have this restriction but uses script/bitbake so this fix seems to be wrong here since its specific to OE-Core's default build env.

This has been implemented differently now:

http://cgit.openembedded.org/openembedded-core/commit/?id=769384decb095fb3c49eb13b8f7f69c978d0bcba

Quoted 4 lines · Paul Eggleton

This has been implemented differently now:

http://cgit.openembedded.org/openembedded-core/commit/?id=769384decb095fb3
c49eb13b8f7f69c978d0bcba

This'll break the ability to run bitbake from subdirs underneath BUILDDIR, which is perfectly valid, and supported by bitbake's code which traverses up the current working path to find conf/bblayers.conf.