Re: [oe] RFC: Support for R/W git in bitbake
On Wed, 18 Apr 2012 03:34:27 +0200 Ulf Samuelsson openembed...@emagii.com wrote: On 2012-04-18 01:07, Paul Eggleton wrote: On Wednesday 18 April 2012 00:35:29 Ulf Samuelsson wrote: Today bitbake supports read only git access in recipes. For various reasons, I would like to be able to do recipes which would check out in a read/write mode. Could you elaborate on various reasons? Would the new externalsrc bbclass be useful in your case? Cheers, Paul 1. If I am busy working on an application, then it simplifies the development process. I can modify the code in the tree and push. This is mainly for kernel development. for that you can pass protocol=file to make the git fetcher use the file transport, see http://ao2.it/en/blog/2010/05/27/neat-compilerun-cycle-git-and-openembedded basically, in the .bb recipe, you can fetch from a local clone where you do your normal work. 2. If I work on a prerelease of some S/W drivers/Applications under NDA, then I cannot make that code publicly available but I still want to put that on my Internet accessible git server. Typicailly this is before the release of a new chip and info about the chip should not be made public before the chip is released. 3. I want to be able to ship something similar to the Angstrom setup scripts to someone else, and have them build an image, but it should not be available to anyone not accepted (without public key at the git server). maybe you can pass protocol=ssh as well to the git fetcher as well, but I haven't tried that, when you say R/W mode you are basically saying ssh transport for git, right? Let us know if that works. There are other uses for such a functionality, but those are my immediate needs. As you see, this is mostly for development. Once the code is released, then the recipe would be changed to the normal git access. Didn't know anything about the externalsrc bbclass, but after checking, I would say no. It won't do the two things above. I do see the use of it though. Ciao, Antonio -- Antonio Ospite http://ao2.it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? pgpA6PWyQul2Q.pgp Description: PGP signature ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] RFC: Support for R/W git in bitbake
On Wednesday 18 April 2012 03:34:27 Ulf Samuelsson wrote: 1. If I am busy working on an application, then it simplifies the development process. I can modify the code in the tree and push. This is mainly for kernel development. 2. If I work on a prerelease of some S/W drivers/Applications under NDA, then I cannot make that code publicly available but I still want to put that on my Internet accessible git server. Typicailly this is before the release of a new chip and info about the chip should not be made public before the chip is released. 3. I want to be able to ship something similar to the Angstrom setup scripts to someone else, and have them build an image, but it should not be available to anyone not accepted (without public key at the git server). There are other uses for such a functionality, but those are my immediate needs. As you see, this is mostly for development. Once the code is released, then the recipe would be changed to the normal git access. Didn't know anything about the externalsrc bbclass, but after checking, I would say no. It won't do the two things above. I do see the use of it though. externalsrc should handle everything except automatically fetching the source; for that you need to have your own local git clone (which of course can be r/w). I guess it depends on whether you expect to be sending such recipes to non-developers; for developers it ought not to be too much of a hassle to have their own local git clone. The only problem with having an r/w checkout you are doing development in under WORKDIR is that if you bitbake -c clean the recipe you will lose whatever you are working on - externalsrc avoids this. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] meta-chromium
On Tue, Apr 17, 2012 at 10:40:28PM +0200, Eric Bénard wrote: Hi, we have pushed the begining of our (Eukréa Electromatique's team and especially Denis) work to get Chromium to build with OpenEmbedded Core to : git://github.com/eukrea/meta-chromium.git https://github.com/eukrea/meta-chromium For the moment it's only tested on ARMv7 platforms (i.MX515 and i.MX535 based) where it seems robust and quite fast on most of the HTML5 tests we ran (only WebGL doesn't yet work). Feel free to send patches to improve the recipes and add support for other platforms. TODO : - enable WebGL with OpenGL ES support - support other platforms than armv7 - merge with meta-mozilla to create a meta-browser layer Eric Cool and thanks. Bye Henning ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] RFC: Support for R/W git in bitbake
On 2012-04-18 09:28, Paul Eggleton wrote: On Wednesday 18 April 2012 03:34:27 Ulf Samuelsson wrote: 1. If I am busy working on an application, then it simplifies the development process. I can modify the code in the tree and push. This is mainly for kernel development. 2. If I work on a prerelease of some S/W drivers/Applications under NDA, then I cannot make that code publicly available but I still want to put that on my Internet accessible git server. Typicailly this is before the release of a new chip and info about the chip should not be made public before the chip is released. 3. I want to be able to ship something similar to the Angstrom setup scripts to someone else, and have them build an image, but it should not be available to anyone not accepted (without public key at the git server). There are other uses for such a functionality, but those are my immediate needs. As you see, this is mostly for development. Once the code is released, then the recipe would be changed to the normal git access. Didn't know anything about the externalsrc bbclass, but after checking, I would say no. It won't do the two things above. I do see the use of it though. externalsrc should handle everything except automatically fetching the source; for that you need to have your own local git clone (which of course can be r/w). I guess it depends on whether you expect to be sending such recipes to non-developers; for developers it ought not to be too much of a hassle to have their own local git clone. The only problem with having an r/w checkout you are doing development in under WORKDIR is that if you bitbake -c clean the recipe you will lose whatever you are working on - externalsrc avoids this. Cheers, Paul I am working with a company, which OEMs their solution to other companies. They get tons of questions from those customers, and based on that I would like to avoid anything which requires manual intervention of the developer. As for cleaning out changes, it might happen, but I am prepared to take the risk. Today I am initializing a git after the extract anyway. I am sure I will use externalsrc for something. -- Best Regards Ulf Samuelsson u...@emagii.com +46 722 427437 ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [oe-commits] Koen Kooi : gateone: silence systemd bbclass WARNING, ${PN}-systemd is unwanted
On Wed, Apr 18, 2012 at 08:56:10AM +, g...@git.openembedded.org wrote:
Module: meta-openembedded.git
Branch: master
Commit: ca5e7197524efef0961bdbbe111f6dd16f1d46b4
URL:
http://git.openembedded.org/?p=meta-openembedded.gita=commit;h=ca5e7197524efef0961bdbbe111f6dd16f1d46b4
Author: Koen Kooi k...@dominion.thruhere.net
Date: Wed Apr 18 10:45:41 2012 +0200
gateone: silence systemd bbclass WARNING, ${PN}-systemd is unwanted
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
.../recipes-connectivity/gateone/gateone_git.bb|1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/meta-oe/recipes-connectivity/gateone/gateone_git.bb
b/meta-oe/recipes-connectivity/gateone/gateone_git.bb
index 2469f9e..983dc24 100644
--- a/meta-oe/recipes-connectivity/gateone/gateone_git.bb
+++ b/meta-oe/recipes-connectivity/gateone/gateone_git.bb
@@ -24,6 +24,7 @@ do_install_append() {
install -m 0644 ${WORKDIR}/gateone-avahi.service
${D}${sysconfdir}/avahi/services/
}
+NATIVE_SYSTEMD_SUPPORT = 1
what exactly do you mean by native support?
gateone.service is added to SRC_URI like in other systemd supporting
recipes and packaging it in own subpackage would silence the warning
it too.
I'm fine with those changes, just wondering what's the advantage and
native here.
Cheers,
SYSTEMD_PACKAGES = ${PN}
SYSTEMD_SERVICE = gateone.service
___
Openembedded-commits mailing list
openembedded-comm...@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-commits
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Hard floating point support for armv7a wmmx2 processor in oe-core
Le 12 avril 2012 18:25, Mark Hatle mark.ha...@windriver.com a écrit : On 4/12/12 12:38 PM, Nicolas Aguirre wrote: Hi, I'm building an oe-core minimal image and toolchain for the cubox[1] which has a Marvell Armada 510 SoC, also known as Dove. It's a armv7 Arm processor with wmmx2 instruction set [2]. I setup a new machine for the cubox and added : require conf/machine/include/arm/arch-armv7a.inc in my cubox.conf file I also added ARM_FP_MODE = hardfp TARGET_FPU = hardfp in my local.conf file. That is not how to enable the mode with the newer tune infrastructure. You need to simply enable a tune, in your machine configuration, that matches the desired output. The following are the defined VFP (hard float requires VFP) tunes for hard float: armv7ahf armv7athf armv7ahf-neon armv7athf-neon the t varients support thumb, but don't have it enabled by default.. the -neon variants also enabled the neon instructions. I do not know what the wmmx2 instructions are, if they are different from VFP and Neon, then it sounds like you need a custom tune. Your machine configure should set DEFAULTTUNE = ... where ... is the tune you want for that given machine. (armv7ahf should be a safe place to start.) Hi Mark, Thanks for your detailed explanation I'm now able to build a minimal core image with hardfp enabled. The detail of the OE Build : TUNE_FEATURES = armv7a vfp callconvention-hard TARGET_FPU= vfp I pushed my layer on github : https://github.com/naguirre/meta-cubox Nothing interesting for now and binaries have not been tested. I encountered some problems during the build, due to a bad fetch operation of mime-support package. I need to fetch it by hand, the .tar.gz was corrupted and contains an html page. Another problem i encountered, was during the build of cpufrequtils. And it seems that this point is related to harfp. cpufreq is linked against libcpufreq which are not compatible each other. I don't know if it's a problem in cpufreq recipe, i need to investigate more. Another problem was during the build of libvpx which seems to be not compatible with armv7ahf, only with armv7a. ERROR: Logfile of failure stored in: /home/nico/e17_src/cubox/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv7ahf-vfp-angstrom-linux-gnueabi/libvpx-0.9.5-r3.0/temp/log.do_configure.9887 Log data follows: | ERROR: Function failed: do_configure (see /home/nico/e17_src/cubox/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv7ahf-vfp-angstrom-linux-gnueabi/libvpx-0.9.5-r3.0/temp/log.do_configure.9887 for further information) | Configuring selected codecs | enabling vp8_encoder | enabling vp8_decoder | Configuring for target 'armv7-linux-gcc' | enabling armv7 | enabling armv6 | enabling armv5te | enabling fast_unaligned | Toolchain is unable to link executables | | Configuration failed. This could reflect a misconfiguration of your | toolchains, improper options selected, or another problem. If you | don't see any useful error messages above, the next step is to look | at the configure error log file (config.err) to determine what | configure was trying to do when it died. NOTE: package libvpx-0.9.5-r3.0: task do_configure: Failed I now understand why Koen said that hardfp is not compatible with anything :) Figure out the correct set of commands for gcc to support this processor, and I can help you define a custom tune file. I need to dig more about wmmx2 instructions set, to see how to enable it in gcc I will maybe come back with more questions :) Thanks for your time, Nicolas The few references I found in a quick google search seem to indicate that the core does support thumb, it should use the armv7-a compilation, and there is little to no support for the wmmx2 instructions. --Mark Any help would be appreciate :) [1] http://www.solid-run.com/products/cubox [2] http://www.marvell.com/application-processors/armada-500/ regards, ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel -- Nicolas Aguirre Mail: aguirre.nico...@gmail.com Web: http://enna.geexbox.org Blog: http://dev.enlightenment.fr/~captainigloo/ ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH] mime-support: Update to version 3.48
From: Luca Vaudano vaud...@gmail.com
Signed-off-by: Luca Vaudano vaud...@gmail.com
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
.../{mime-support_3.44.bb = mime-support_3.48.bb} |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
rename meta-oe/recipes-support/mime-support/{mime-support_3.44.bb =
mime-support_3.48.bb} (93%)
diff --git a/meta-oe/recipes-support/mime-support/mime-support_3.44.bb
b/meta-oe/recipes-support/mime-support/mime-support_3.48.bb
similarity index 93%
rename from meta-oe/recipes-support/mime-support/mime-support_3.44.bb
rename to meta-oe/recipes-support/mime-support/mime-support_3.48.bb
index fe84a63..f281f6d 100644
--- a/meta-oe/recipes-support/mime-support/mime-support_3.44.bb
+++ b/meta-oe/recipes-support/mime-support/mime-support_3.48.bb
@@ -5,7 +5,6 @@ LIC_FILES_CHKSUM =
file://debian/README;md5=36bbe2ace0a05c3fb684b73208fbf30b
DEPENDS = file
RRECOMMENDS_${PN} = file
-PR = r2
SRC_URI = ${DEBIAN_MIRROR}/main/m/mime-support/mime-support_${PV}-1.tar.gz
S = ${WORKDIR}/${PN}
@@ -55,5 +54,5 @@ do_install () {
cd ${D}${mandir}/man1; ln -s run-mailcap.1.gz print.1.gz
}
-SRC_URI[md5sum] = 048aa29c31f067382cd669ee20934b9e
-SRC_URI[sha256sum] =
4f65183200955540c097b82bfb18f5d21b636ca79f47cd018a4ea8b89cd2998c
+SRC_URI[md5sum] = d6e5d715e331147352c50c158dbdec6d
+SRC_URI[sha256sum] =
a529c7892cb786f514af71f4ca5a4c3ebc58b538a49ff959c0d97592d38f040a
--
1.7.8.5
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH] gpsd: fix gpsd init script
Replace return with exit where appropriate.
Current init script uses return outside of functions resulting in
warnings such as the following when using bash as interpreter:
/etc/init.d/gpsd: line 98: return: can only `return' from a function or sourced
script
Signed-off-by: Johan Hovold johan.hov...@lundinova.se
---
meta-oe/recipes-navigation/gpsd/gpsd-2.96/gpsd | 10 +-
meta-oe/recipes-navigation/gpsd/gpsd_2.96.bb |2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/meta-oe/recipes-navigation/gpsd/gpsd-2.96/gpsd
b/meta-oe/recipes-navigation/gpsd/gpsd-2.96/gpsd
index 3687d24..ba73daf 100755
--- a/meta-oe/recipes-navigation/gpsd/gpsd-2.96/gpsd
+++ b/meta-oe/recipes-navigation/gpsd/gpsd-2.96/gpsd
@@ -95,19 +95,19 @@ case $1 in
start)
echo Starting $DESC $NAME
do_start
- return $?
+ exit $?
;;
stop)
echo Stopping $DESC $NAME
do_stop
- return $?
+ exit $?
;;
status)
;;
reload|force-reload)
echo Reloading $DESC $NAME
do_reload
- return $?
+ exit $?
;;
restart)
#
@@ -119,11 +119,11 @@ case $1 in
case $? in
0|1)
do_start
- return $?
+ exit $?
;;
*)
# Failed to stop
- return 1
+ exit 1
;;
esac
;;
diff --git a/meta-oe/recipes-navigation/gpsd/gpsd_2.96.bb
b/meta-oe/recipes-navigation/gpsd/gpsd_2.96.bb
index 927107a..7e2a96c 100644
--- a/meta-oe/recipes-navigation/gpsd/gpsd_2.96.bb
+++ b/meta-oe/recipes-navigation/gpsd/gpsd_2.96.bb
@@ -5,7 +5,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=d217a23f408e91c94359447735bc1800
DEPENDS = dbus-glib ncurses python libusb1
PROVIDES = virtual/gpsd
-PR = r2
+PR = r3
EXTRA_OECONF = --x-includes=${STAGING_INCDIR}/X11 \
--x-libraries=${STAGING_LIBDIR} \
--
1.7.8.5
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [oe-core] build for 32bit architecture
Hi All, I need to build the native packages for a 32bit architecture, although I'm working on a 64bit machine. So I need to pass the -m32 option to the compiler and my question is about the right place where to put it to be inherited by all native packages. Please let me know, best regards. Giuseppe ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [oe-core] build for 32bit architecture
On 2012-04-18 07:48, Giuseppe Condorelli wrote: Hi All, I need to build the native packages for a 32bit architecture, although I'm working on a 64bit machine. So I need to pass the -m32 option to the compiler and my question is about the right place where to put it to be inherited by all native packages. Why would you need 32bit native packages when your build host is 64bit? The native packages are only used to provide functionality during the build and hence (it makes sense to me at least) they should match the build host native environment. -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [oe-core] build for 32bit architecture
2012/4/18 Gary Thomas g...@mlbassoc.com On 2012-04-18 07:48, Giuseppe Condorelli wrote: Hi All, I need to build the native packages for a 32bit architecture, although I'm working on a 64bit machine. So I need to pass the -m32 option to the compiler and my question is about the right place where to put it to be inherited by all native packages. Why would you need 32bit native packages when your build host is 64bit? The native packages are only used to provide functionality during the build and hence (it makes sense to me at least) they should match the build host native environment. I need to build cross tools at 32bit for my goal. -- --**-- Gary Thomas | Consulting for the MLB Associates |Embedded world --**-- __**_ Openembedded-devel mailing list Openembedded-devel@lists.**openembedded.orgOpenembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/**cgi-bin/mailman/listinfo/**openembedded-develhttp://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [meta-kde] Test images (was: Re: [OE-core] RFC: Porting KDE Plasma Active (WIP))
2012/4/1 Paul Eggleton paul.eggle...@linux.intel.com: On Thursday 02 February 2012 12:50:16 Samuel Stirtzel wrote: There are other CMake configure pitfalls (all cross compiling scripts in kdelibs are commented out) but it seems that at least the most of them showed already during build time. Unfortunately when I tried to build kdelibs4 I got the following: | cd /home/paul/poky/poky/build-kde/tmp/work/i586-poky- linux/kdelibs4-4.8.0+git1+1439483a67135f483632f4c4cd239e96d2ed61fc- r0/git/build/kjs /home/paul/poky/poky/build-kde/tmp/sysroots/x86_64- linux/usr/bin/icemaker /home/paul/poky/poky/build-kde/tmp/work/i586-poky- linux/kdelibs4-4.8.0+git1+1439483a67135f483632f4c4cd239e96d2ed61fc- r0/git/kjs/bytecode | /bin/sh: /home/paul/poky/poky/build-kde/tmp/sysroots/x86_64- linux/usr/bin/icemaker: No such file or directory | make[2]: *** [kjs/opcodes.h] Error 127 | make[2]: Leaving directory `/home/paul/poky/poky/build-kde/tmp/work/i586- poky-linux/kdelibs4-4.8.0+git1+1439483a67135f483632f4c4cd239e96d2ed61fc- r0/git/build' Any ideas? Is this a PARALLEL_MAKE issue? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre Hi, these issues should now be resolved thanks to Kai Kang. It requires to rebuild qt4-native, also it is recommended to use Qt 4.8.0 Currently I'm testing the images, so there hopefully won't be any build errors on them. Sysvinit images seem to be a bit tougher, since they fail postinsts for me; So I can't login on them. As of now I have a working KDE Plasma Desktop image (based on Angstrom's systemd image) that runs well on my overo. If anyone wants to try the image, there is a branch at the git repository [1] named sst-test-images. It is planned to have Poky standalone images too, as well as Plasma Active images for both Poky and Angstrom (after Plasma Active is working). Feel free to comment on the images. Notes: The Plasma Desktop image for Poky (see [2]) could work too, but I didn't try to build it on Poky yet. This branch will probably not parse on Poky due to the Angstrom images (I'm working on it). [1] https://gitorious.org/openembedded-core-layers/meta-kde [2] https://gitorious.org/openembedded-core-layers/meta-kde/blobs/sst-test-images/recipes-images/plasma-desktop-image.bb -- Regards Samuel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [oe-commits] Koen Kooi : gateone: silence systemd bbclass WARNING, ${PN}-systemd is unwanted
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Op 18-04-12 11:29, Martin Jansa schreef:
On Wed, Apr 18, 2012 at 08:56:10AM +, g...@git.openembedded.org
wrote:
Module: meta-openembedded.git Branch: master Commit:
ca5e7197524efef0961bdbbe111f6dd16f1d46b4 URL:
http://git.openembedded.org/?p=meta-openembedded.gita=commit;h=ca5e7197524efef0961bdbbe111f6dd16f1d46b4
Author: Koen Kooi k...@dominion.thruhere.net
Date: Wed Apr 18 10:45:41 2012 +0200
gateone: silence systemd bbclass WARNING, ${PN}-systemd is unwanted
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
.../recipes-connectivity/gateone/gateone_git.bb|1 + 1 files
changed, 1 insertions(+), 0 deletions(-)
diff --git a/meta-oe/recipes-connectivity/gateone/gateone_git.bb
b/meta-oe/recipes-connectivity/gateone/gateone_git.bb index
2469f9e..983dc24 100644 ---
a/meta-oe/recipes-connectivity/gateone/gateone_git.bb +++
b/meta-oe/recipes-connectivity/gateone/gateone_git.bb @@ -24,6 +24,7 @@
do_install_append() { install -m 0644 ${WORKDIR}/gateone-avahi.service
${D}${sysconfdir}/avahi/services/ }
+NATIVE_SYSTEMD_SUPPORT = 1
what exactly do you mean by native support?
gateone.service is added to SRC_URI like in other systemd supporting
recipes and packaging it in own subpackage would silence the warning it
too.
I'm fine with those changes, just wondering what's the advantage and
native here.
if your recipe only has systemd support and no sysvinit, it makes little
sense to split out a ${PN}-systemd.
Anyway, the warnings about stuff that isn't going to get fixed are gone now.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQIcBAEBAgAGBQJPjvP/AAoJEHZqAkdh1vT6NesP/1A9An6hjLXNTufcBoE2a0Fo
J4eDzAzttJtfjnhsd9bKywDyKh5KfyFqccCKm2/vnUsvRwsyoqIy8bveFYWFXvKQ
NRYAjqmLXYSXrnU4Dyg1/oDgZIIkstl8mUJbByT2sZYjv1VYcRHA02ph7pRVnES1
tDWMckzpesCc8506xd1qBCF4zphB+llE6T0YwaeP13EL6h2XtQJYm+5iepDusnjv
eFFZwbFJHWUHOfkWdDFP5fCRmXqDPSlt86nj1AEA3EDHFVaaGkxBbH0zqCuHbYQy
OcXIEo/TYuonU4croavQtrKxYgNbm4a74Ypsx4JT31wtGteCC8YLpQ8ZWbg39UX1
v7tmNMV4u9UBeveobc0pZ29Trr9rDYWvBVYueP0YziBiF4gMkXfW8c/rmekVhnnb
uHqlr/RF+5c2hKg7CZE3PN6DbsvfDTKxgYcXaMbvETXlgXgV/L+Ev7Cf52t+rJF+
HB90RDLcmUaBERm35zDMPaxo7mk7YK/cY5XbC42eKkOXrwzqxiq321LETKJ0Ci72
SJVrRnvNdhi0fcDMkWddOk/IQQ/7gvrU/VYusTUMuAbnhzS0uAJoqDMmKepWRQOy
hgy7DjrromIKcIR3LP4Xcqgb6Xv+NcFrTRpuN2iVWvTcEuTlFhA3ML5UlCDKkOoL
QSgigGMh+ZlcvqV3jSoP
=3sHA
-END PGP SIGNATURE-
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [oe-core] build for 32bit architecture
On Wed, Apr 18, 2012 at 8:48 AM, Giuseppe Condorelli giuseppe.condore...@gmail.com wrote: Hi All, I need to build the native packages for a 32bit architecture, although I'm working on a 64bit machine. So I need to pass the -m32 option to the compiler and my question is about the right place where to put it to be inherited by all native packages. We use setarch with chroot and it works well. -M ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [meta-kde] Test images (was: Re: [OE-core] RFC: Porting KDE Plasma Active (WIP))
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Op 18-04-12 17:19, Samuel Stirtzel schreef: 2012/4/1 Paul Eggleton paul.eggle...@linux.intel.com: On Thursday 02 February 2012 12:50:16 Samuel Stirtzel wrote: There are other CMake configure pitfalls (all cross compiling scripts in kdelibs are commented out) but it seems that at least the most of them showed already during build time. Unfortunately when I tried to build kdelibs4 I got the following: | cd /home/paul/poky/poky/build-kde/tmp/work/i586-poky- linux/kdelibs4-4.8.0+git1+1439483a67135f483632f4c4cd239e96d2ed61fc- r0/git/build/kjs /home/paul/poky/poky/build-kde/tmp/sysroots/x86_64- linux/usr/bin/icemaker /home/paul/poky/poky/build-kde/tmp/work/i586-poky- linux/kdelibs4-4.8.0+git1+1439483a67135f483632f4c4cd239e96d2ed61fc- r0/git/kjs/bytecode | /bin/sh: /home/paul/poky/poky/build-kde/tmp/sysroots/x86_64- linux/usr/bin/icemaker: No such file or directory | make[2]: *** [kjs/opcodes.h] Error 127 | make[2]: Leaving directory `/home/paul/poky/poky/build-kde/tmp/work/i586- poky-linux/kdelibs4-4.8.0+git1+1439483a67135f483632f4c4cd239e96d2ed61fc- r0/git/build' Any ideas? Is this a PARALLEL_MAKE issue? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre Hi, these issues should now be resolved thanks to Kai Kang. It requires to rebuild qt4-native, also it is recommended to use Qt 4.8.0 Currently I'm testing the images, so there hopefully won't be any build errors on them. Sysvinit images seem to be a bit tougher, since they fail postinsts for me; So I can't login on them. As of now I have a working KDE Plasma Desktop image (based on Angstrom's systemd image) that runs well on my overo. If anyone wants to try the image, there is a branch at the git repository [1] named sst-test-images. It is planned to have Poky standalone images too, as well as Plasma Active images for both Poky and Angstrom (after Plasma Active is working). Feel free to comment on the images. Giving them a spin now :) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJPjvbrAAoJEHZqAkdh1vT6H+EP/3+am7AdZK5y1smlgtApcMm+ Gh7ruIoJwedSICKp6rqRyM1lUssIrC/7QKri+5Ae0Cjw7h5aglEPIYXCoB39NRqw o2aOUyTjVDxk4nbv+z/3WFxwHHx0053GYztJUWPBNVL77HPn+8rq5ALaMydCCheR jjdS/+/2tuD+DxAeFOsFMj3zoh9CrKR605+AkxjTAtMNRZl7QjCdP9J1wjrXrDQ0 ZnSnTEIH8ycZPjCL3b5LvGxfjRdah1y9uCjlaRu9rjMXY/UHA3Nzr84TjvCW3iiN s3R21ggaSPKINZ3irigViXOeKPDhr3FThNhsLVkLY41JBe0xXqt9LCs1GxYIMGfC phP7wpsiFLLtePwcBPn5X3lL3JFBXVXqwgqo8Eb0W9u3tLypiV50C6+0L7XwZNVW ERNmxw0fdd1UN9wzRxpOcKofmxwO2ZW4BfkS8xbxfXLIXz4AktCHb7IDtXJCr5nT 7rrH2iMvbDyzNnVssYS3Yl2GGNlbG6jwwyd6/09kDo4OJdMWFs1soAw2QiEEWY5A jc7lW9o7Z3rlwtUiUIktLF2rkGv63IDuN9+xXNyKwBHoTqwjcGFG/8M7EPGc2hTQ HmNxTdEiLTdEjsvjzTqwFP5hjtFznMGmFl1BtDfEb3/aw4GSbcCbrkU/LylXqkGs Jcu04IswcM3pi2RcaaVX =tuC9 -END PGP SIGNATURE- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [oe-core] build for 32bit architecture
On Wed, Apr 18, 2012 at 04:17:30PM +0200, Giuseppe Condorelli wrote: 2012/4/18 Gary Thomas g...@mlbassoc.com On 2012-04-18 07:48, Giuseppe Condorelli wrote: Hi All, I need to build the native packages for a 32bit architecture, although I'm working on a 64bit machine. So I need to pass the -m32 option to the compiler and my question is about the right place where to put it to be inherited by all native packages. Why would you need 32bit native packages when your build host is 64bit? The native packages are only used to provide functionality during the build and hence (it makes sense to me at least) they should match the build host native environment. I need to build cross tools at 32bit for my goal. Well, that's cross, not native, as you previously said. For what you want look at SDKMACHINE in your local.conf -- Denys ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH 1/1] Fixed the URL for git repo for meta-openembedded
Signed-off-by: Autif Khan aut...@gmail.com --- README |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/README b/README index 5fafd9d..9f441f5 100644 --- a/README +++ b/README @@ -10,7 +10,7 @@ URI: git://git.openembedded.org/openembedded-core branch: master revision: HEAD -URI: git://git.openembedded.net/meta-openembedded +URI: git://git.openembedded.org/meta-openembedded branch: master revision: HEAD -- 1.7.5.4 ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [meta-oe] README: fix meta-efl, meta-gpe and meta-xfce to point to openembedded.org
From: Denys Dmytriyenko de...@ti.com Fix README files for meta-efl, meta-gpe and meta-xfce to point to the correct openembedded.org address instead of the outdated openembedded.net in git URIs. Reported by Autif Khan for one of the layers. Signed-off-by: Denys Dmytriyenko de...@ti.com --- meta-efl/README |3 +-- meta-gpe/README |3 +-- meta-xfce/README |2 +- 3 files changed, 3 insertions(+), 5 deletions(-) diff --git a/meta-efl/README b/meta-efl/README index 25be47e..41effe6 100644 --- a/meta-efl/README +++ b/meta-efl/README @@ -4,7 +4,7 @@ URI: git://git.openembedded.org/openembedded-core branch: master revision: HEAD -URI: git://git.openembedded.net/meta-openembedded +URI: git://git.openembedded.org/meta-openembedded branch: master revision: HEAD @@ -13,4 +13,3 @@ Send pull requests to openembedded-devel@lists.openembedded.org with '[meta-efl] When sending single patches, please using something like 'git send-email -1 --to openembedded-devel@lists.openembedded.org --subject-prefix meta-efl' Interim layer maintainer: Koen Kooi k...@dominion.thruhere.net - diff --git a/meta-gpe/README b/meta-gpe/README index ebe0cea..d967dc1 100644 --- a/meta-gpe/README +++ b/meta-gpe/README @@ -4,11 +4,10 @@ URI: git://git.openembedded.org/openembedded-core branch: master revision: HEAD -URI: git://git.openembedded.net/meta-openembedded +URI: git://git.openembedded.org/meta-openembedded branch: master revision: HEAD Send pull requests to openembedded-devel@lists.openembedded.org with '[meta-gpe]' in the subject' Interim layer maintainer: Koen Kooi k...@dominion.thruhere.net - diff --git a/meta-xfce/README b/meta-xfce/README index 6e021e1..1a503c9 100644 --- a/meta-xfce/README +++ b/meta-xfce/README @@ -4,7 +4,7 @@ URI: git://git.openembedded.org/openembedded-core branch: master revision: HEAD -URI: git://git.openembedded.net/meta-openembedded +URI: git://git.openembedded.org/meta-openembedded branch: master revision: HEAD -- 1.7.8.5 ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [oe-commits] Koen Kooi : gateone: silence systemd bbclass WARNING, ${PN}-systemd is unwanted
On Wed, Apr 18, 2012 at 07:04:04PM +0200, Koen Kooi wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Op 18-04-12 11:29, Martin Jansa schreef:
On Wed, Apr 18, 2012 at 08:56:10AM +, g...@git.openembedded.org
wrote:
Module: meta-openembedded.git Branch: master Commit:
ca5e7197524efef0961bdbbe111f6dd16f1d46b4 URL:
http://git.openembedded.org/?p=meta-openembedded.gita=commit;h=ca5e7197524efef0961bdbbe111f6dd16f1d46b4
Author: Koen Kooi k...@dominion.thruhere.net
Date: Wed Apr 18 10:45:41 2012 +0200
gateone: silence systemd bbclass WARNING, ${PN}-systemd is unwanted
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
.../recipes-connectivity/gateone/gateone_git.bb|1 + 1 files
changed, 1 insertions(+), 0 deletions(-)
diff --git a/meta-oe/recipes-connectivity/gateone/gateone_git.bb
b/meta-oe/recipes-connectivity/gateone/gateone_git.bb index
2469f9e..983dc24 100644 ---
a/meta-oe/recipes-connectivity/gateone/gateone_git.bb +++
b/meta-oe/recipes-connectivity/gateone/gateone_git.bb @@ -24,6 +24,7 @@
do_install_append() { install -m 0644 ${WORKDIR}/gateone-avahi.service
${D}${sysconfdir}/avahi/services/ }
+NATIVE_SYSTEMD_SUPPORT = 1
what exactly do you mean by native support?
gateone.service is added to SRC_URI like in other systemd supporting
recipes and packaging it in own subpackage would silence the warning it
too.
I'm fine with those changes, just wondering what's the advantage and
native here.
if your recipe only has systemd support and no sysvinit, it makes little
sense to split out a ${PN}-systemd.
Well some people can type
/usr/bin/python gateone.py
to test it without sysvinit or systemd support.
Anyway, the warnings about stuff that isn't going to get fixed are gone now.
But this explains it enough, thanks.
Cheers,
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQIcBAEBAgAGBQJPjvP/AAoJEHZqAkdh1vT6NesP/1A9An6hjLXNTufcBoE2a0Fo
J4eDzAzttJtfjnhsd9bKywDyKh5KfyFqccCKm2/vnUsvRwsyoqIy8bveFYWFXvKQ
NRYAjqmLXYSXrnU4Dyg1/oDgZIIkstl8mUJbByT2sZYjv1VYcRHA02ph7pRVnES1
tDWMckzpesCc8506xd1qBCF4zphB+llE6T0YwaeP13EL6h2XtQJYm+5iepDusnjv
eFFZwbFJHWUHOfkWdDFP5fCRmXqDPSlt86nj1AEA3EDHFVaaGkxBbH0zqCuHbYQy
OcXIEo/TYuonU4croavQtrKxYgNbm4a74Ypsx4JT31wtGteCC8YLpQ8ZWbg39UX1
v7tmNMV4u9UBeveobc0pZ29Trr9rDYWvBVYueP0YziBiF4gMkXfW8c/rmekVhnnb
uHqlr/RF+5c2hKg7CZE3PN6DbsvfDTKxgYcXaMbvETXlgXgV/L+Ev7Cf52t+rJF+
HB90RDLcmUaBERm35zDMPaxo7mk7YK/cY5XbC42eKkOXrwzqxiq321LETKJ0Ci72
SJVrRnvNdhi0fcDMkWddOk/IQQ/7gvrU/VYusTUMuAbnhzS0uAJoqDMmKepWRQOy
hgy7DjrromIKcIR3LP4Xcqgb6Xv+NcFrTRpuN2iVWvTcEuTlFhA3ML5UlCDKkOoL
QSgigGMh+ZlcvqV3jSoP
=3sHA
-END PGP SIGNATURE-
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/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.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [oe-core] ld segfault cant figure it out
On Tue, Apr 17, 2012 at 10:40 PM, j vwyodap...@gmail.com wrote: Sorry to sound so dumb but if there is no recipe failing and 2 separate systems are segfaulting in similar manners and both result with not fully functioning images/packages where else can I look for info? I posted all the logs to one of the builds, and the QA log seems to be the only thing really spitting out anything. I am open to trying and or sharing any and all relevant info to help sort it out or get me on track to sorting it out. what I am hearing is that your build succeeds despite these ld segfaults. Am I right ? but then when you run the resulting images then the images dont function correctly on your target and you also mentioned that its expat package when being built that causes the ld segfaults. Are you sure about that ? You could somehow forge ulimit to unlimited that will dump on ubuntu edit /etc/security/limits.conf on build host and then add * softcoreunlimited that should generate core files. After this search for core* files in build tree and see if there are any then debug them with gdb to diagnose it further Now I am not sure if those segfaults directly relate to malfunction of image if thats the case but its likely. You should also try to explore the reasons why the image fails to behave as expected. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] Help with first compile
Hi. I am trying to bring up OE for the first time, following this guide:
http://docs.openembedded.org/usermanual/usermanual.html. Running on Ubuntu
11.10.
I've followed every step precisely through Building Software. Then I try
bitbake base-image, and get pages of errors. The top lines are listed
below. Is this doc out of date? Or, is it possible to divine from this what
error I may have made?
Thanks!
mb@mb:~/Source/oe/build$ echo $PATH
/home/mb/Source/oe/bitbake/bin:/opt/cs/arm-uclinux/bin:/home/mb/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
mb@mb:~/Source/oe/build$ echo $BBPATH
/home/mb/Source/oe/build:/home/mb/Source/oe/openembedded
mb@mb:~/Source/oe/build$ echo $OEBASE
/home/mb/Source/oe
mb@mb:~/Source/oe/build$ cat conf/local.conf
BBFILES = ${OEBASE}/openembedded/recipes/*/*.bb
DISTRO = angstrom-2008.1
MACHINE = om-gta01
ERROR: Could not inherit file classes/rootfs_${IMAGE_PKGTYPE}.bbclass while
parsing
/home/mb/Source/oe/openembedded/recipes/preboot/initramfs-preboot-image.bb
NOTE: type 'exceptions.SyntaxError':EOL while scanning string literal
(string, line 1) while evaluating:
${@':'.join(uniq(os.path.normpath(os.path.join(fp, p, o)) for fp in
'/home/mb/Source/oe/openembedded/recipes/angstrom'.split(':') for p in
'angstrom-version-2_${DISTRO_VERSION}-r9:angstrom-version-${DISTRO_VERSION}:angstrom-version:angstrom-version-${DISTRO_VERSION}:angstrom-version:files:.'.split(':')
for o in reversed([''] + filter(None,
'pn-angstrom-version:fail-fast:build-linux:arm:INVALID:angstrom-2008.1:om-gta01:local'.split(':')}
NOTE: type 'exceptions.SyntaxError':EOL while scanning string literal
(string, line 1) while evaluating:
${@patch_deps(d)}
ERROR: EOL while scanning string literal (string, line 1) while parsing
/home/mb/Source/oe/openembedded/recipes/angstrom/angstrom-version.bb
NOTE: type 'exceptions.TypeError':list indices must be integers, not NoneType
while evaluating:
http://projects.linuxtogo.org/frs/download.php/14/prismstumbler-0.7.4pre1.tar.gz
file://gpsapi.patch ${@['',
'file://wireless.patch'][bb.data.getVar('PREFERRED_VERSION_linux-libc-headers',
d, 1) and bb.data.getVar('PREFERRED_VERSION_linux-libc-headers', d,
1).split('.')[2] '30']}
file://fix-includes.patch;striplevel=0
file://libgps-check.patch file://replace-gps_query.patch
ERROR: Error in executing:
/home/mb/Source/oe/openembedded/recipes/prismstumbler/prismstumbler_0.7.3+0.7.4pre1.bb
ERROR: Exception:type 'exceptions.TypeError' Message:list indices must be
integers, not NoneType
ERROR: Printing the environment of the function
ERROR: 0001:def __anonfunc():
ERROR: 0002:
__anon_185__home_mb_Source_oe_openembedded_classes_staging_bbclass(d)
ERROR: 0003:
__anon_90__home_mb_Source_oe_openembedded_classes_packaged_staging_bbclass(d)
ERROR: 0004: __anon_419_classes_base_bbclass(d)
ERROR: 0005:
__anon_102__home_mb_Source_oe_openembedded_classes_siteinfo_bbclass(d)
ERROR: list indices must be integers, not NoneType while parsing
/home/mb/Source/oe/openembedded/recipes/prismstumbler/prismstumbler_0.7.3+0.7.4pre1.bb
NOTE: type 'exceptions.SyntaxError':EOL while scanning string literal
(string, line 1) while evaluating:
${@base_conditional(ONLINE_PACKAGE_MANAGEMENT, none, ,
${PREFERRED_PROVIDER_virtual/update-alternatives}, d)}
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 1/3] qt4-native: enable features to build kdelib4-native
On 2012年04月16日 18:50, Samuel Stirtzel wrote: 2012/4/16 Kang Kaikai.k...@windriver.com: add a bbappend file to enable qt4-native 4.7.4 to enable openssl and phonon support. Add flags '-no-pch -no-sm' to make qt4-native itself compiled successfully. Signed-off-by: Kang Kaikai.k...@windriver.com --- recipes-misc-support/qt4-native_4.7.4.bbappend |4 1 files changed, 4 insertions(+), 0 deletions(-) create mode 100644 recipes-misc-support/qt4-native_4.7.4.bbappend diff --git a/recipes-misc-support/qt4-native_4.7.4.bbappend b/recipes-misc-support/qt4-native_4.7.4.bbappend new file mode 100644 index 000..a11a23f --- /dev/null +++ b/recipes-misc-support/qt4-native_4.7.4.bbappend @@ -0,0 +1,4 @@ +# Needed by kdelibs4-native +EXTRA_OECONF += -no-pch -no-sm -openssl + +TOBUILD += src/phonon -- 1.7.5.4 Hi, this patch works although it is recommended to use Qt 4.8.0 for KDE 4.8.0. I renamed the patch to let it append to qt4-native_4.8.0.bb. Hi Samuel, Thanks for your guide. Kai ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [toolchain-layer][PATCH] gcc-4.5: Backport cpp honor sysroot patch
This patch is well vetted on gcc-4.6
Signed-off-by: Khem Raj raj.k...@gmail.com
---
toolchain-layer/recipes-devtools/gcc/gcc-4.5.inc |3 +-
.../gcc/gcc-4.5/cpp-honour-sysroot.patch | 36
2 files changed, 38 insertions(+), 1 deletion(-)
create mode 100644
toolchain-layer/recipes-devtools/gcc/gcc-4.5/cpp-honour-sysroot.patch
diff --git a/toolchain-layer/recipes-devtools/gcc/gcc-4.5.inc
b/toolchain-layer/recipes-devtools/gcc/gcc-4.5.inc
index ee4a434..8fabf30 100644
--- a/toolchain-layer/recipes-devtools/gcc/gcc-4.5.inc
+++ b/toolchain-layer/recipes-devtools/gcc/gcc-4.5.inc
@@ -14,7 +14,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552 \
PV = 4.5
-PR = r48
+PR = r49
# BINV should be incremented after updating to a revision
# after a minor gcc release (e.g. 4.5.1 or 4.5.2) has been made
@@ -38,6 +38,7 @@ SRC_URI =
svn://gcc.gnu.org/svn/gcc/branches;module=${BRANCH};proto=http \
file://gcc-armv4-pass-fix-v4bx-to-ld.patch \
file://sh4-multilib.patch \
file://arm-lib1funcs.as-fix-mismatch-between-conditions-of-an-IT-block.patch \
+ file://cpp-honour-sysroot.patch \
\
file://linaro/gcc-4.5-linaro-r99297.patch \
file://linaro/gcc-4.5-linaro-r99298.patch \
diff --git
a/toolchain-layer/recipes-devtools/gcc/gcc-4.5/cpp-honour-sysroot.patch
b/toolchain-layer/recipes-devtools/gcc/gcc-4.5/cpp-honour-sysroot.patch
new file mode 100644
index 000..cf4c77c
--- /dev/null
+++ b/toolchain-layer/recipes-devtools/gcc/gcc-4.5/cpp-honour-sysroot.patch
@@ -0,0 +1,36 @@
+Currently, if the gcc toolchain is relocated and installed from sstate, then
you try and compile
+preprocessed source (.i or .ii files), the compiler will try and access the
builtin sysroot location
+rather than the --sysroot option specified on the commandline. If access to
that directory is
+permission denied (unreadable), gcc will error.
+
+This happens when ccache is in use due to the fact it uses preprocessed source
files.
+
+The fix below adds %I to the cpp-output spec macro so the default
substitutions for -iprefix,
+-isystem, -isysroot happen and the correct sysroot is used.
+
+[YOCTO #2074]
+
+Upstream-Status: Pending
+
+RP 2012/04/13
+
+--- a/gcc/gcc.c
b/gcc/gcc.c
+@@ -1106,7 +1106,7 @@ static const struct compiler default_com
+ %W{o*:--output-pch=%*}%V}}, 0, 0, 0},
+ {.i, @cpp-output, 0, 1, 0},
+ {@cpp-output,
+- %{!M:%{!MM:%{!E:cc1 -fpreprocessed %i %(cc1_options)
%{!fsyntax-only:%(invoke_as), 0, 1, 0},
++ %{!M:%{!MM:%{!E:cc1 -fpreprocessed %i %I %(cc1_options)
%{!fsyntax-only:%(invoke_as), 0, 1, 0},
+ {.s, @assembler, 0, 1, 0},
+ {@assembler,
+%{!M:%{!MM:%{!E:%{!S:as %(asm_debug) %(asm_options) %i %A , 0, 1, 0},
+--- a/gcc/cp/lang-specs.h
b/gcc/cp/lang-specs.h
+@@ -63,5 +63,5 @@ along with GCC; see the file COPYING3.
+ {.ii, @c++-cpp-output, 0, 0, 0},
+ {@c++-cpp-output,
+%{!M:%{!MM:%{!E:\
+-cc1plus -fpreprocessed %i %(cc1_options) %2 %{+e*}\
++cc1plus -fpreprocessed %i %I %(cc1_options) %2 %{+e*}\
+ %{!fsyntax-only:%(invoke_as), 0, 0, 0},
--
1.7.9.5
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [oe-core] ld segfault cant figure it out
On 04/18/2012 03:00 PM, Khem Raj wrote: On Tue, Apr 17, 2012 at 10:40 PM, jvwyodap...@gmail.com wrote: Sorry to sound so dumb but if there is no recipe failing and 2 separate systems are segfaulting in similar manners and both result with not fully functioning images/packages where else can I look for info? I posted all the logs to one of the builds, and the QA log seems to be the only thing really spitting out anything. I am open to trying and or sharing any and all relevant info to help sort it out or get me on track to sorting it out. what I am hearing is that your build succeeds despite these ld segfaults. Am I right ? but then when you run the resulting images then the images dont function correctly on your target First off thank you all for your time and information, and putting up with me learning and trying to get things working!! Yes you are correct. Nothing in the images or packages fail, but the build machine itself segfaults. Then if I put the image on my BB-XM sdcard they boot and run but things are not right, such as directories that should not be there are, some do not build a fully functioning package, such as task-native-sdk. and you also mentioned that its expat package when being built that causes the ld segfaults. Are you sure about that ? You could somehow forge ulimit to unlimited that will dump No I am not sure about it. As I am just trying to watch it build and look for the build machine to segfault and see what packages it is working on. Though after further messing with expat I think you are correct in doubting that is the one causing it. I just did a clean build of perl with no rm_work enabled, and I am trying to dig through the logs and info. From your earlier advice/mentioning of libtool-cross I do notice some things while it is building according to the info. I will post some of what stood out to me, which may in turn mean nothing. If I can post anymore of the logs or anything please let me know. I did notice today setting things to build one at a time, that it does appear that its working on libtool-cross, but again I could be wrong. on ubuntu edit /etc/security/limits.conf on build host and then add * softcoreunlimited that should generate core files. After this search for core* files in build tree and see if there are any then debug them with gdb to diagnose it further Now I am not sure if those segfaults directly relate to malfunction of image if thats the case but its likely. You should also try to explore the reasons why the image fails to behave as expected. I will do as suggested as well as do a full image build again and see if I can find out all that is not working. Thank you for the extra debugging info and suggestions. Are there any keywords to search through all the files for including the normal log files, it may help me track down things even further. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel I really am not trying to be a pain in the a** and would like to get things sorted out and understood on my side. Honestly if the resulting images worked and did not get any extra folders in their paths I would not care about the resulting segfaults on the build machine. Another side note, I am borrowing another build machine for a few days to see, this is a non nvidia machine just in case that is the bad variable in both machines. libtool-cross info:: log.do_configure /configure: WARNING: unrecognized options: --disable-silent-rules, --with-sysroot/ log.do_compile: help2man is installed on the system, whereis help2man help2man: /usr/bin/help2man /usr/lib/help2man /usr/share/man/man1/help2man.1.gz /WARNING: `help2man' is missing on your system. You should only need it if you modified a dependency of a manual page. You may need the `Help2man' package in order for those modifications to take effect. You can get `Help2man' from any GNU archive site. PATH=.:$PATH; export PATH; /bin/sh /home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/libtool-cross-2.4.2-r2.1/libtool-2.4.2/libltdl/config/missing --run help2man --output=doc/libtoolize.1 libtoolize WARNING: `help2man' is missing on your system. You should only need it if you modified a dependency of a manual page. You may need the `Help2man' package in order for those modifications to take effect. You can get `Help2man' from any GNU archive site./ log.do_package /DEBUG: Preparing tree /home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/libtool-cross-2.4.2-r2.1/shlibs for packaging at /home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/libtool-cross-2.4.2-r2.1/sstate-build-package/shlibs sed: no
