Re: [oe] [OE-core] SRC_URI computing order
On Mon, Nov 4, 2013 at 12:10 AM, Richard Purdie
wrote:
> On Sun, 2013-11-03 at 23:16 +0100, Andrea Adami wrote:
>> On Sat, Nov 2, 2013 at 9:47 AM, Eric Bénard wrote:
>> > Hi Richard,
>> >
>> > Le Wed, 30 Oct 2013 15:15:12 +,
>> > Richard Purdie a écrit :
>> >
>> >> On Tue, 2013-10-29 at 08:28 +0100, Eric Bénard wrote:
>> >> > Hi Khem,
>> >> >
>> >> > Le Mon, 28 Oct 2013 20:45:21 -0700,
>> >> > Khem Raj a écrit :
>> >> >
>> >> > > On Mon, Oct 28, 2013 at 7:10 AM, Eric Bénard wrote:
>> >> > > > Hi Richard,
>> >> > > >
>> >> > > > I saw your patch fixing FILESPATH's and Kergoth's one fixing
>> >> > > > PACKAGECONFIG processing order and I think I'm also facing an order
>> >> > > > problem when SRC_URI is computed.
>> >> > > >
>> >> > > > So when building SRC_URI when two layers have bbappend which apply
>> >> > > > patches : the SRC_URI seems to be built using an order I fail to
>> >> > > > understand somewhere instead of priority or the overrides' order.
>> >> > > >
>> >> > > > The use case is a System on Module and its custom motherboard :
>> >> > > > - meta-fsl-arm :
>> >> > > > * linux-imx_xyz.bb :
>> >> > > > SRC_URI = "patchgeneric1 ..."
>> >> > > >
>> >> > > > - meta-som-support :
>> >> > > > * conf/machine/mysom.conf
>> >> > > >
>> >> > > > * linux-imx_xyz.bbappend :
>> >> > > > SRC_URI_append_mysom = "patchsom1 patchsom2 ..."
>> >> > > >
>> >> > > > - meta-custommotherboard (SOM + Cunstom Motherboard) :
>> >> > > > * conf/machine/myproduct.conf
>> >> > > > MACHINEOVERRIDES_prepend = "mysom:"
>> >> > > > include conf/machine/mysom.conf
>> >> > > >
>> >> > > > * linux-imx_xyz.bbappend :
>> >> > > > SRC_URI_append_myproduct = "patchproduct1 patchproduct2 ..."
>> >> > > >
>> >> > > > in the end I get :
>> >> > > > SRC_URI = "patchgeneric1 ... patchsoc1 ... patchproduct1 ...
>> >> > > > patchsom1 ..."
>> >> > > >
>> >> > > > and of course as patchproduct* are supposed to apply on top of
>> >> > > > patchsoc* the patch fail to apply.
>> >> > > >
>> >> > > > I didn't found a way to build SRC_URI in the order I would like (I
>> >> > > > tested : changing MACHINEOVERRIDES 's order, changing layers'
>> >> > > > priority,
>> >> > > > changing machine's name to see if that was an alphabetical order
>> >> > > > ...).
>> >> > > >
>> >> > > > In the end the only thing which worked was to add an (empty by
>> >> > > > default)
>> >> > > > variable in som's SRC_URI and filling this variables from the
>> >> > > > custommotherboard's bbappend.
>> >> > > >
>> >> > > > Is the behaviour I'm seeing expected or is there something wrong in
>> >> > > > my
>> >> > > > setup ?
>> >> > >
>> >> > > what is your OVERRIDES order.
>> >> > >
>> >> > "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}:forcevariable"
>> >> >
>> >> > so it follows the MACHINEOVERRIDES order (and I tried both append and
>> >> > prepend to hack MACHINEOVERRIDES without any behaviour change).
>> >>
>> >> I think what Khem is asking is what OVERRIDES expands to?
>> >>
>> >> You mean patchso* and not patchsoc* above, right? Or should patchsom1 be
>> >> patchsoc2?
>> >>
>> > oops :
>> > I expect SRC_URI = "patchgeneric1 ... patchsom1 ... patchproduct1 ..."
>> > and I get :
>> > SRC_URI = "patchgeneric1 ... patchproduct1 ... patchsom1 ..."
>> >
>> >> Its hard to follow and it might be easier if you could share a
>> >> simplified test case we could reproduce this with. I don't doubt there
>> >> is an issue in there but we need a way to reproduce and debug this.
>> >>
>> > OK, I'm preparing a simple testcase to reproduce that with oe-core +
>> > meta-fsl-arm + meta-som + meta-baseboard.
>> >
>> > Eric
>> > ___
>> > Openembedded-core mailing list
>> > openembedded-c...@lists.openembedded.org
>> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>>
>> I have to report an undesiderate behavior:
>>
>> the formfactor files in our .bbappend are not considered :/
>> DEBUG: Searching for machconfig in paths:
>> /oe/oe-core/meta/recipes-bsp/formfactor/formfactor-0.0/
>> /oe/oe-core/meta/recipes-bsp/formfactor/formfactor/
>> /oe/oe-core/meta/recipes-bsp/formfactor/files/
>> /oe/meta-handheld/recipes-bsp/formfactor/files/poodle
>>
>> so we end up with the empty machconfig of
>> /oe/oe-core/meta/recipes-bsp/formfactor/files/
>>
>> Surely this didn't happen when we tested the recipe.
>
> With which revision of OE-Core? Was this with the dora release tag,
> current dora head or master?
>
> Cheers,
>
> Richard
>
>
This was with fresh master:
Build Configuration:
BB_VERSION= "1.21.0"
BUILD_SYS = "i686-linux"
NATIVELSBSTRING = "Gentoo"
TARGET_SYS= "arm-oe-linux-gnueabi"
MACHINE = "poodle"
DISTRO_VERSION= "oe-core.0"
TUNE_FEATURES = "armv5 thumb dsp"
TARGET_FPU= "soft"
meta = "master:511b4194165ed7a5645169e09c27db280d5a5316"
meta-initramfs= "master:4d62e
Re: [oe] Still getting gd-2.0.36RC1.tar.gz errors in meta-oe/recipes-support/gd/gd_2.0.35+2.0.36rc1.bb
On Mon, Nov 04, 2013 at 04:09:22PM -0500, Brian Hutchinson wrote: > Hi, > > This has been going on for the last month or two. Apparently this upstream > project name changed and it no longer available at the URL. I looked into > it several weeks ago but it didn't look like a simple URL path fix as it > looked like other stuff depends on it. I've been coping the file from an > earlier build to my downloads directory to get my builds to complete. grab copy from http://ring.u-toyama.ac.jp/archives/graphics/gd/ and put it on your PREMIRROR. > > Regards, > > Brian > > Loading cache: 100% > || > ETA: 00:00:00 > Loaded 1877 entries from dependency cache. > Parsing recipes: 100% > |##| > Time: 00:00:00 > Parsing of 1471 .bb files complete (1470 cached, 1 parsed). 1876 targets, > 96 skipped, 0 masked, 0 errors. > NOTE: Resolving any missing task queue dependencies > NOTE: multiple providers are available for jpeg (jpeg, libjpeg-turbo) > NOTE: consider defining a PREFERRED_PROVIDER entry to match jpeg > > Build Configuration: > BB_VERSION= "1.21.0" > BUILD_SYS = "x86_64-linux" > NATIVELSBSTRING = "Debian-7.1" > TARGET_SYS= "arm-oe-linux-gnueabi" > MACHINE = "am180x-evm" > DISTRO_VERSION= "oe-core.0" > TUNE_FEATURES = "armv5 thumb dsp" > TARGET_FPU= "soft" > toolchain-layer > meta-oe > meta-multimedia > meta-networking > meta-webserver= "master:4d62e7f575e2a87197c74ab4639561b45eec0e60" > meta-ti = "master:15243e8ec3ce0652f7ddb7542df022306f40d888" > meta = "master:0636093711547957a8f5b25322bd3e0da367cfc4" > > NOTE: Preparing runqueue > NOTE: Executing SetScene Tasks > NOTE: Executing RunQueue Tasks > WARNING: Failed to fetch URL > http://www.libgd.org/releases/gd-2.0.36RC1.tar.gz, attempting MIRRORS if > available > ERROR: Fetcher failure: Fetch command failed with exit code 8, output: > http://libgd.bitbucket.org/releases/gd-2.0.36RC1.tar.gz: > 2013-11-04 15:43:25 ERROR 404: NOT FOUND. > > ERROR: Function failed: Fetcher failure for URL: ' > http://www.libgd.org/releases/gd-2.0.36RC1.tar.gz'. Unable to fetch URL > from any source. > ERROR: Logfile of failure stored in: > /home/hutch/arago_11_1_2013/tisdk/build/arago-tmp-eglibc/work/armv5te-oe-linux-gnueabi/gd/2.0.35+2.0.36rc1-r5/temp/log.do_fetch.32535 > ERROR: Task 1136 > (/home/hutch/arago_11_1_2013/tisdk/sources/meta-openembedded/meta-oe/recipes-support/gd/gd_2.0.35+ > 2.0.36rc1.bb, do_fetch) failed with exit code '1' > NOTE: Tasks Summary: Attempted 1581 tasks of which 1119 didn't need to be > rerun and 1 failed. > Waiting for 0 running tasks to finish: > > Summary: 1 task failed: > > /home/hutch/arago_11_1_2013/tisdk/sources/meta-openembedded/meta-oe/recipes-support/gd/gd_2.0.35+ > 2.0.36rc1.bb, do_fetch > Summary: There was 1 WARNING message shown. > Summary: There were 2 ERROR messages shown, returning a non-zero exit code. > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] Still getting gd-2.0.36RC1.tar.gz errors in meta-oe/recipes-support/gd/gd_2.0.35+2.0.36rc1.bb
Hi, This has been going on for the last month or two. Apparently this upstream project name changed and it no longer available at the URL. I looked into it several weeks ago but it didn't look like a simple URL path fix as it looked like other stuff depends on it. I've been coping the file from an earlier build to my downloads directory to get my builds to complete. Regards, Brian Loading cache: 100% || ETA: 00:00:00 Loaded 1877 entries from dependency cache. Parsing recipes: 100% |##| Time: 00:00:00 Parsing of 1471 .bb files complete (1470 cached, 1 parsed). 1876 targets, 96 skipped, 0 masked, 0 errors. NOTE: Resolving any missing task queue dependencies NOTE: multiple providers are available for jpeg (jpeg, libjpeg-turbo) NOTE: consider defining a PREFERRED_PROVIDER entry to match jpeg Build Configuration: BB_VERSION= "1.21.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "Debian-7.1" TARGET_SYS= "arm-oe-linux-gnueabi" MACHINE = "am180x-evm" DISTRO_VERSION= "oe-core.0" TUNE_FEATURES = "armv5 thumb dsp" TARGET_FPU= "soft" toolchain-layer meta-oe meta-multimedia meta-networking meta-webserver= "master:4d62e7f575e2a87197c74ab4639561b45eec0e60" meta-ti = "master:15243e8ec3ce0652f7ddb7542df022306f40d888" meta = "master:0636093711547957a8f5b25322bd3e0da367cfc4" NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks WARNING: Failed to fetch URL http://www.libgd.org/releases/gd-2.0.36RC1.tar.gz, attempting MIRRORS if available ERROR: Fetcher failure: Fetch command failed with exit code 8, output: http://libgd.bitbucket.org/releases/gd-2.0.36RC1.tar.gz: 2013-11-04 15:43:25 ERROR 404: NOT FOUND. ERROR: Function failed: Fetcher failure for URL: ' http://www.libgd.org/releases/gd-2.0.36RC1.tar.gz'. Unable to fetch URL from any source. ERROR: Logfile of failure stored in: /home/hutch/arago_11_1_2013/tisdk/build/arago-tmp-eglibc/work/armv5te-oe-linux-gnueabi/gd/2.0.35+2.0.36rc1-r5/temp/log.do_fetch.32535 ERROR: Task 1136 (/home/hutch/arago_11_1_2013/tisdk/sources/meta-openembedded/meta-oe/recipes-support/gd/gd_2.0.35+ 2.0.36rc1.bb, do_fetch) failed with exit code '1' NOTE: Tasks Summary: Attempted 1581 tasks of which 1119 didn't need to be rerun and 1 failed. Waiting for 0 running tasks to finish: Summary: 1 task failed: /home/hutch/arago_11_1_2013/tisdk/sources/meta-openembedded/meta-oe/recipes-support/gd/gd_2.0.35+ 2.0.36rc1.bb, do_fetch Summary: There was 1 WARNING message shown. Summary: There were 2 ERROR messages shown, returning a non-zero exit code. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] OE Changelog since 2013-10-27 until 2013-11-03
Changelog since 2013-10-27 until 2013-11-03. Projects included in this report: bitbake: git://git.openembedded.org/bitbake openembedded-core: git://git.openembedded.org/openembedded-core meta-openembedded: git://git.openembedded.org/meta-openembedded meta-angstrom: git://github.com/Angstrom-distribution/meta-angstrom.git meta-arago: git://arago-project.org/git/meta-arago.git meta-beagleboard: git://github.com/beagleboard/meta-beagleboard.git meta-browser: git://github.com/OSSystems/meta-browser.git meta-bug: git://github.com/buglabs/meta-bug.git meta-chicken: git://github.com/OSSystems/meta-chicken meta-efikamx: git://github.com/kraj/meta-efikamx.git meta-ettus: http://github.com/koenkooi/meta-ettus.git meta-fsl-arm: git://git.yoctoproject.org/meta-fsl-arm meta-fsl-arm-extra: git://github.com/Freescale/meta-fsl-arm-extra.git meta-fsl-ppc: git://git.yoctoproject.org/meta-fsl-ppc meta-guacamayo: git://github.com/Guacamayo/meta-guacamayo.git meta-gumstix: git://github.com/gumstix/meta-gumstix.git meta-gumstix-community: git://gitorious.org/schnitzeltony-oe-meta/meta-gumstix-community.git meta-handheld: git://git.openembedded.org/meta-handheld meta-igep: http://github.com/ebutera/meta-igep.git meta-intel: git://git.yoctoproject.org/meta-intel meta-ivi: git://git.yoctoproject.org/meta-ivi meta-java: git://github.com/woglinde/meta-java meta-kde: git://gitorious.org/openembedded-core-layers/meta-kde.git meta-micro: git://git.openembedded.org/meta-micro meta-mono: git://git.yoctoproject.org/meta-mono.git meta-netbookpro: git://github.com/tworaz/meta-netbookpro meta-nslu2: git://github.com/kraj/meta-nslu2 meta-opie: git://git.openembedded.org/meta-opie meta-qt3: git://git.yoctoproject.org/meta-qt3 meta-qt5: git://github.com/meta-qt5/meta-qt5.git meta-slugos: git://github.com/kraj/meta-slugos meta-systemd: git://git.yoctoproject.org/meta-systemd meta-raspberrypi: git://github.com/djwillis/meta-raspberrypi.git meta-smartphone: http://git.shr-project.org/repo/meta-smartphone.git meta-ti: git://git.yoctoproject.org/meta-ti meta-webos: git://github.com/openwebos/meta-webos.git meta-xilinx: git://git.yoctoproject.org/meta-xilinx meta-yocto: git://git.yoctoproject.org/meta-yocto openembedded: git://git.openembedded.org/openembedded Changelog for bitbake: Alexandru DAMIAN (7): toaster: fixes for null values from events cooker: add data to the dependency tree dump build, toaster: record proper task type cooker: do not recreate recipecache in buildfile mode toaster: fix timezone settings toaster: server shutdown on terminal exit toaster: enable required classes in the toaster startup script Cristiana Voicu (3): hob: populate error_msg when hob receives a CommandFailed event hob: do not display the "Package list may be incomplete!" dialog toaster: add variable description for prefixed/suffixed variables Nicolas Dechesne (1): fetch2/svn.py: use log instead of info to retrieve revision Volker Vogelhuber (1): fetch/hg: Improve user/password handling Changelog for openembedded-core: Andreas Müller (1): systemd-compat-units: run-postinsts fix script link Andreas Oberritter (1): cogl-1.0: depend on virtual/mesa Chen Qi (3): jpeg: enable postinst to run at rootfs time successfully groff: fix pkg_postinst and remove unneeded do_install_prepend sgml-common: make postinst run successfully at rootfs time Cristian Iorga (7): bluez5: upgrade to 5.10 glib-2.0: upgrade to 2.38.1 connman: upgrade to 1.19 libuser: upgrade to 0.60 iproute2: upgrade to 3.11.0 telepathy-mission-control: upgrade to 5.16.0 telepathy-glib: upgrade to 0.23.0 Cristiana Voicu (5): grep: upgrade to 2.15 at: upgrade to 3.1.14 curl: upgrade to 7.33.0 sudo: upgrade to 1.8.8 rxvt-unicode: upgrade to 9.19 Darren Hart (1): scripts: Add ksize.py and dirsize.py Gary Thomas (1): core-image-basic.bb: Allow user extensions Hongxu Jia (2): debugedit: fix segment fault while file's bss offset have a large number coreutils: support command arch Jackie Huang (1): busybox: fix sed auto insert newline testcase Jacob Kroon (2): update-rc.d.bbclass: Fix host/target test in postinst update-rc.d.bbclass: Cleanup package scripts Jason Wessel (2): syslinux.bbclass: Fix default serial port string grub-efi.bbclass: Fix startup.nsh to work on more EFI revs Joao Henrique Ferreira de Freitas (1): grub-efi.bbclass: Fixes GRUB_IMAGE when using boot-directdisk class Joe Slater (2): tzcode & tzdata: update to 2013h vala.bbclass: add dependency on vala Jonathan Liu (1): qt4: add upstream QTBUG-34218/QTBUG-34234 misaligned selection patch Khem Raj (2): pulseaudio: Fix build break on armeb elfutils-native: Update the patch to include the missing pieces needed for t Konrad Scherer (2): pigz: Add pigz to buildtools tarball pixbufcache.bbclass: gdk-pixbuf-query-loaders depends on libz L
Re: [oe] Pb compilation with BB_NUMBER_THREADS != 1
On 2013-11-04 09:44, MONDON Daniel wrote: I'm on a virtual Ubuntu 12.04 server, 16 cores, 8Go RAM free frequency (max = 163840MHz) With BB_NUMBER_THREADS = '1', the entire project is successfully build in 12h30. With BB_NUMBER_THREADS = '4' (same result with 12) | LD_LIBRARY_PATH=/home/xxbuild/tmp-angstrom_v2012_05-eglibc/work/x86_64-linux/perl-native-5.14.2-r0/perl-5.14.2:/home/xxbuild/tmp-angstrom_v2012_05-eglib c/sysroots/x86_64-linux/usr/bin/../lib/pseudo/lib:/home/xxbuild/tmp-angstrom_v2012_05-eglibc/sysroots/x86_64-linux/usr/bin/../lib/pseudo/lib64 ./perl -f -Ilib pod/buildtoc -- build-toc -q | | Making x2p stuff | make[1]: Entering directory `/home/xxbuild/tmp-angstrom_v2012_05-eglibc/work/x86_64-linux/perl-native-5.14.2-r0/perl-5.14.2/x2p' | | make[1]: Leaving directory `/home/xxbuild/tmp-angstrom_v2012_05-eglibc/work/x86_64-linux/perl-native-5.14.2-r0/perl-5.14.2/x2p' | pod/buildtoc: no pods at pod/buildtoc line 305. | make: *** [pod/perltoc.pod] Error 255 | ERROR: oe_runmake failed NOTE: package perl-native-5.14.2-r0: task do_compile: Failed NOTE: package perl-5.14.2-r6: task do_fetch: Started NOTE: package perl-5.14.2-r6: task do_fetch: Succeeded ERROR: Task 1239 (/home/xxsources/openembedded-core/meta/recipes-devtools/perl/perl-native_5.14.2.bb, do_compile) failed with exit code '1' NOTE: Tasks Summary: Attempted 4055 tasks of which 4053 didn't need to be rerun and 1 failed. Summary: 1 task failed: /home/xxsources/openembedded-core/meta/recipes-devtools/perl/perl-native_5.14.2.bb, do_compile Summary: There was 1 ERROR message shown, returning a non-zero exit code. Known problem ? Any solution ? More details are probably needed to be able to help much. Since this is a virtual server, have you tried reducing the number of cores (not BB threads)? I routinely use this on real Ubuntu-12.04/x86_84 with an Core2-duo (2x2 cores) with BB_NUMBER_THREADS=4 with no problems. -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] Pb compilation with BB_NUMBER_THREADS != 1
I'm on a virtual Ubuntu 12.04 server, 16 cores, 8Go RAM free frequency (max = 163840MHz) With BB_NUMBER_THREADS = '1', the entire project is successfully build in 12h30. With BB_NUMBER_THREADS = '4' (same result with 12) | LD_LIBRARY_PATH=/home/xxbuild/tmp-angstrom_v2012_05-eglibc/work/x86_64-linux/perl-native-5.14.2-r0/perl-5.14.2:/home/xxbuild/tmp-angstrom_v2012_05-eglib c/sysroots/x86_64-linux/usr/bin/../lib/pseudo/lib:/home/xxbuild/tmp-angstrom_v2012_05-eglibc/sysroots/x86_64-linux/usr/bin/../lib/pseudo/lib64 ./perl -f -Ilib pod/buildtoc -- build-toc -q | | Making x2p stuff | make[1]: Entering directory `/home/xxbuild/tmp-angstrom_v2012_05-eglibc/work/x86_64-linux/perl-native-5.14.2-r0/perl-5.14.2/x2p' | | make[1]: Leaving directory `/home/xxbuild/tmp-angstrom_v2012_05-eglibc/work/x86_64-linux/perl-native-5.14.2-r0/perl-5.14.2/x2p' | pod/buildtoc: no pods at pod/buildtoc line 305. | make: *** [pod/perltoc.pod] Error 255 | ERROR: oe_runmake failed NOTE: package perl-native-5.14.2-r0: task do_compile: Failed NOTE: package perl-5.14.2-r6: task do_fetch: Started NOTE: package perl-5.14.2-r6: task do_fetch: Succeeded ERROR: Task 1239 (/home/xxsources/openembedded-core/meta/recipes-devtools/perl/perl-native_5.14.2.bb, do_compile) failed with exit code '1' NOTE: Tasks Summary: Attempted 4055 tasks of which 4053 didn't need to be rerun and 1 failed. Summary: 1 task failed: /home/xxsources/openembedded-core/meta/recipes-devtools/perl/perl-native_5.14.2.bb, do_compile Summary: There was 1 ERROR message shown, returning a non-zero exit code. Known problem ? Any solution ? Thanks Daniel. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] ruby-native problem (on dylan)
Hello, On 10/04/2013 10:09 AM, Nicolas Dechesne wrote: hi, we got some build failures in our autobuilders last night, which seemed to be related to ruby-native. We use dylan, but I believe the same problem is there in master/dora too. The exact build error was in qtwebkit do_compile: ruby /mnt/ci_build/workspace/project/branches/dylan/label/oe_persistent_cloud/machines/genericarmv7a/build/tmp/work/armv7ahf-vfp-neon-project-linux-gnueabi/qtwebkit/5.0.2-r0.0/qtwebkit-opensource-src-5.0.2/Source/JavaScriptCore/offlineasm/generate_offset_extractor.rb /mnt/ci_build/workspace/project/branches/dylan/label/oe_persistent_cloud/machines/genericarmv7a/build/tmp/work/armv7ahf-vfp-neon-project-linux-gnueabi/qtwebkit/5.0.2-r0.0/qtwebkit-opensource-src-5.0.2/Source/JavaScriptCore/llint/LowLevelInterpreter.asm LLIntDesiredOffsets.h :1:in `require': cannot load such file -- rubygems.rb (LoadError) from :1:in `' Yesterday I had 'moved' our BUILDDIR location. However for every build, we: - delete the TMPDIR completely - reuse our sstate The problem seems to be that 'ruby' has hard coded paths in the binary. This is discussed in [1] or more at length in [2], and easy to check: $ strings tmp/sysroots/x86_64-linux/usr/bin/ruby | grep project /work/project/build/tmp/sysroots/x86_64-linux/usr /work/project/build/tmp/sysroots/x86_64-linux/usr/lib/ruby/site_ruby /work/project/build/tmp/sysroots/x86_64-linux/usr/lib/ruby/site_ruby/x86_64-linux /work/project/build/tmp/sysroots/x86_64-linux/usr/lib/ruby/vendor_ruby /work/project/build/tmp/sysroots/x86_64-linux/usr/lib/ruby/vendor_ruby/x86_64-linux /work/project/build/tmp/sysroots/x86_64-linux/usr/share/rubygems /work/project/build/tmp/sysroots/x86_64-linux/usr/lib/ruby /work/project/build/tmp/sysroots/x86_64-linux/usr/lib/ruby/x86_64-linux So, the 'ruby' binary which was in the sstate, knew about the *old* paths. When building today, ruby was pulled from sstate, but TMPDIR has changed now, and the hardcoded paths no longer exists, leading to the build failure. I verified that the following 'solved' the build issue: $ bitbake -c cleansstate ruby-native $ bitbake ruby-native $ bitbake qtwebkit There seems to be a configure option, --enable-load-relative, after using this option in ruby build, still ruby fails to start for the same reason. I might have done something wrong, but i wanted to bring it on the list, to see if anyone has a better solution, as it seems like a big issue. I saw the same issue in my setup and looked a bit deeper into it. The patch "ruby-1.9.3-custom-rubygems-location.patch" seems to break --enable-load-relative. When I remove this patch and add "--enable-load-relative" then ruby starts without an error. But this has the side effect that the rubygems directory is /usr/lib/ruby/rubygems instead of /usr/share/rubygems inside the sysroot. I don't know if this matters. Would it break anything else? thanks nicolas [1] http://stackoverflow.com/questions/10221387/moving-ruby-installation-causes-it-to-not-function-how-to-get-around-this [2] http://yehudakatz.com/2012/06/ Best Regards Tobias ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-multimedia][dora] backport request libao patch
Hello, Is it possible to backport this patch http://cgit.openembedded.org/meta-openembedded/commit/?id=153372542a75625cda97b864afc25b3cac54772d to dora? Without this we can't install libao plugins. Thanks, Patrick ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
