Re: [OE-core] Build failure in samba
Op 15 nov. 2011, om 01:11 heeft Richard Purdie het volgende geschreven: On Mon, 2011-11-14 at 18:47 -0500, Philip Balister wrote: Anyone have an idea about this failure building samba? http://pastebin.com/5PGX6MZr I'm going to look more tomorrow, just hoping someone sees something obvious. Maybe this might help: commit ce064001e628597cab9c5713f1351e03478a4aa5 Author: Richard Purdie richard.pur...@linuxfoundation.org Date: Wed Nov 2 14:24:37 2011 + samba: Force python disabled for now to avoid host contamination diff --git a/recipes-support/samba/samba_3.5.6.bb b/recipes-support/samba/samba_3.5.6.bb index d5945f9..a44ce02 100644 --- a/recipes-support/samba/samba_3.5.6.bb +++ b/recipes-support/samba/samba_3.5.6.bb Weird, samba is in recipes-connectivity over here: koen@dominion:/OE/tentacle/sources/meta-openembedded/meta-oe$ find . | grep samba_3.5.6 ./recipes-connectivity/samba/samba_3.5.6.bb signature.asc Description: Message signed with OpenPGP using GPGMail ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3] core-image-minimal-initramfs: force IMAGE_FSTYPES
On 11/04/2011 10:18 PM, Koen Kooi wrote: Op 4 nov. 2011, om 18:52 heeft Paul Eggleton het volgende geschreven: If the user has set their own value for IMAGE_FSTYPES, they may have disabled the cpio.gz image type, preventing the initramfs from being produced in the format that image-live.bbclass expects; so force IMAGE_FSTYPES to cpio.gz within the initramfs image recipe. Signed-off-by: Paul Eggletonpaul.eggle...@linux.intel.com --- .../images/core-image-minimal-initramfs.bb |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/meta/recipes-core/images/core-image-minimal-initramfs.bb b/meta/recipes-core/images/core-image-minimal-initramfs.bb index 0bac27a..e4d0e51 100644 --- a/meta/recipes-core/images/core-image-minimal-initramfs.bb +++ b/meta/recipes-core/images/core-image-minimal-initramfs.bb @@ -13,3 +13,4 @@ LICENSE = MIT inherit core-image IMAGE_ROOTFS_SIZE = 8192 +IMAGE_FSTYPES = cpio.gz _append or += would give less suprises. This was merged as IMAGE_FSTYPES =+ cpio.gz Now this brings problems if I have IMAGE_FSTYPES += live in my local.conf / BSP machine.conf. 1) OE tries to generate hddimg for this initramfs image, which is strange idea 2) If OE is trying to generate bootimg (hddimg) when the kernel is not yet deployed, building fails (as bootimg can't find a deployed kernel to put into hddimg). Please revert this back to original patch as proposed by Paul. -- With best wishes Dmitry ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] distcc: make distccmon-gnome optional and default to off
Am Montag, den 14.11.2011, 21:48 + schrieb Richard Purdie: On Mon, 2011-11-14 at 21:55 +0100, Koen Kooi wrote: Op 14 nov. 2011, om 21:39 heeft Richard Purdie het volgende geschreven: On Mon, 2011-11-14 at 20:17 +0100, Koen Kooi wrote: I think splitting distccmon-gnome into a seperate recipe is a better idea. I think that makes sense in some cases but I'd hate for it to become the default approach for issues like this as the duplication of code, parsing and build time etc. grate on me. Do we really need separate recipes? I think for this case, yes. And I'll happily trade needing extra buildtime for not needing USEFLAGS. The proposals for alternative recipes for the different combinations got voted down and PACKAGECONFIG was the preferred solution. Where is this vote (and discussion) documented? I found nothing in the OE Wiki and searching for it with »openembedded packageconfig vote oe-core list« brought up only some minutes [1]. I also do not remember anything on openembedded-devel where such general discussion definitely belong in my opinion. It would be great if somebody could help me by giving me an URL. I can't say I personally like everything about the outcome. I do however understand why we've ended up in that position and don't intend to undermine the usefulness of it. […] Thanks, Paul [1] http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/7688 signature.asc Description: This is a digitally signed message part ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] libx11-diet: update to 1.4.4
From: Xiaofeng Yan xiaofeng@windriver.com
The main changes are as follow:
* Remove patch nodolt.patch because it is no use in the new version
* Change patch include_fix.patch to keysymdef_include.patch from
libx11-1.4.4.
* Remove --without-xcb from EXTRA_OECONF because xcb is a necessary item for
new version.
Signed-off-by: Xiaofeng Yan xiaofeng@windriver.com
---
.../xorg-lib/libx11-diet-1.3/include_fix.patch | 25 --
.../xorg-lib/libx11-diet-1.3/nodolt.patch | 14
.../libx11-diet-1.3/x11_disable_makekeys.patch | 31 --
.../X18NCMSstubs.diff |1 +
.../fix-disable-xlocale.diff |1 +
.../fix-utf8-wrong-define.patch|2 +
.../libx11-diet-1.4.4/keysymdef_include.patch | 23 +
.../libx11-diet-1.4.4/x11_disable_makekeys.patch | 34
.../{libx11-diet_1.3.bb = libx11-diet_1.4.4.bb} | 17 +-
9 files changed, 70 insertions(+), 78 deletions(-)
delete mode 100644
meta/recipes-graphics/xorg-lib/libx11-diet-1.3/include_fix.patch
delete mode 100644 meta/recipes-graphics/xorg-lib/libx11-diet-1.3/nodolt.patch
delete mode 100644
meta/recipes-graphics/xorg-lib/libx11-diet-1.3/x11_disable_makekeys.patch
rename meta/recipes-graphics/xorg-lib/{libx11-diet-1.3 =
libx11-diet-1.4.4}/X18NCMSstubs.diff (99%)
rename meta/recipes-graphics/xorg-lib/{libx11-diet-1.3 =
libx11-diet-1.4.4}/fix-disable-xlocale.diff (90%)
rename meta/recipes-graphics/xorg-lib/{libx11-diet-1.3 =
libx11-diet-1.4.4}/fix-utf8-wrong-define.patch (88%)
create mode 100644
meta/recipes-graphics/xorg-lib/libx11-diet-1.4.4/keysymdef_include.patch
create mode 100644
meta/recipes-graphics/xorg-lib/libx11-diet-1.4.4/x11_disable_makekeys.patch
rename meta/recipes-graphics/xorg-lib/{libx11-diet_1.3.bb =
libx11-diet_1.4.4.bb} (51%)
diff --git a/meta/recipes-graphics/xorg-lib/libx11-diet-1.3/include_fix.patch
b/meta/recipes-graphics/xorg-lib/libx11-diet-1.3/include_fix.patch
deleted file mode 100644
index b3bcbab..000
--- a/meta/recipes-graphics/xorg-lib/libx11-diet-1.3/include_fix.patch
+++ /dev/null
@@ -1,25 +0,0 @@
-Upstream-Status: Inappropriate [configuration]
-
- configure.ac |6 +++---
- 1 file changed, 3 insertions(+), 3 deletions(-)
-
libX11-1.1.5.orig/configure.ac
-+++ libX11-1.1.5/configure.ac
-@@ -218,13 +218,13 @@ AC_SUBST(XDMCP_LIBS)
- AC_CHECK_FUNC(poll, [AC_DEFINE(USE_POLL, 1, [poll() function is available])],
)
-
- #
- # Find keysymdef.h
- #
--AC_MSG_CHECKING([keysymdef.h])
--dir=`pkg-config --variable=includedir xproto`
--KEYSYMDEF=$dir/X11/keysymdef.h
-+AC_ARG_WITH(keysymdef,
-+ AC_HELP_STRING([--with-keysymdef=DIR/keysymdef.h], [The location of
keysymdef.h]),
-+ KEYSYMDEF=$withval, KEYSYMDEF=)
- if test -f $KEYSYMDEF; then
- AC_MSG_RESULT([$KEYSYMDEF])
- else
- AC_MSG_ERROR([Cannot find keysymdef.h])
- fi
diff --git a/meta/recipes-graphics/xorg-lib/libx11-diet-1.3/nodolt.patch
b/meta/recipes-graphics/xorg-lib/libx11-diet-1.3/nodolt.patch
deleted file mode 100644
index cc05fdc..000
--- a/meta/recipes-graphics/xorg-lib/libx11-diet-1.3/nodolt.patch
+++ /dev/null
@@ -1,14 +0,0 @@
-Upstream-Status: Inappropriate [configuration]
-
-Index: libX11-1.2.1/configure.ac
-===
libX11-1.2.1.orig/configure.ac 2009-07-02 14:07:54.0 +0100
-+++ libX11-1.2.1/configure.ac 2009-07-02 14:08:01.0 +0100
-@@ -20,7 +20,6 @@
-
- # Checks for programs.
- AC_PROG_LIBTOOL
--DOLT
- AC_PROG_CC
- XORG_CWARNFLAGS
-
diff --git
a/meta/recipes-graphics/xorg-lib/libx11-diet-1.3/x11_disable_makekeys.patch
b/meta/recipes-graphics/xorg-lib/libx11-diet-1.3/x11_disable_makekeys.patch
deleted file mode 100644
index 0445835..000
--- a/meta/recipes-graphics/xorg-lib/libx11-diet-1.3/x11_disable_makekeys.patch
+++ /dev/null
@@ -1,31 +0,0 @@
-Upstream-Status: Inappropriate [configuration]
-
- src/util/Makefile.am | 17 -
- 1 file changed, 17 deletions(-)
-
-Index: libX11-1.2.1/src/util/Makefile.am
-===
libX11-1.2.1.orig/src/util/Makefile.am 2008-10-07 18:18:19.0
+0100
-+++ libX11-1.2.1/src/util/Makefile.am 2009-07-02 14:04:38.0 +0100
-@@ -1,20 +1,3 @@
- # $XdotOrg: lib/X11/src/util/Makefile.am,v 1.4 2006-02-19 02:14:12 jamey Exp $
-
--noinst_PROGRAMS=makekeys
--
--makekeys_CFLAGS=$(X11_CFLAGS)
--
--CC = @CC_FOR_BUILD@
--
- EXTRA_DIST = mkks.sh
--
--if LINT
--# Check source code with tools like lint sparse
--
--ALL_LINT_FLAGS=$(LINT_FLAGS) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
-- $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS)
--
--lint:
-- $(LINT) $(ALL_LINT_FLAGS) makekeys.c
--
--endif LINT
diff --git a/meta/recipes-graphics/xorg-lib/libx11-diet-1.3/X18NCMSstubs.diff
[OE-core] [PATCH 0/1] libx11-diet: update to 1.4.4
From: Xiaofeng Yan xiaofeng@windriver.com
Hi Saul,
I have modified my fault according to your suggestion.
Please review it again.
Pull URL: git://git.pokylinux.org/poky-contrib.git
Branch: xiaofeng/libx11-diet
Browse:
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=xiaofeng/libx11-diet
Thanks,
Xiaofeng Yan xiaofeng@windriver.com
---
Xiaofeng Yan (1):
libx11-diet: update to 1.4.4
.../xorg-lib/libx11-diet-1.3/include_fix.patch | 25 --
.../xorg-lib/libx11-diet-1.3/nodolt.patch | 14
.../libx11-diet-1.3/x11_disable_makekeys.patch | 31 --
.../X18NCMSstubs.diff |1 +
.../fix-disable-xlocale.diff |1 +
.../fix-utf8-wrong-define.patch|2 +
.../libx11-diet-1.4.4/keysymdef_include.patch | 23 +
.../libx11-diet-1.4.4/x11_disable_makekeys.patch | 34
.../{libx11-diet_1.3.bb = libx11-diet_1.4.4.bb} | 17 +-
9 files changed, 70 insertions(+), 78 deletions(-)
delete mode 100644
meta/recipes-graphics/xorg-lib/libx11-diet-1.3/include_fix.patch
delete mode 100644 meta/recipes-graphics/xorg-lib/libx11-diet-1.3/nodolt.patch
delete mode 100644
meta/recipes-graphics/xorg-lib/libx11-diet-1.3/x11_disable_makekeys.patch
rename meta/recipes-graphics/xorg-lib/{libx11-diet-1.3 =
libx11-diet-1.4.4}/X18NCMSstubs.diff (99%)
rename meta/recipes-graphics/xorg-lib/{libx11-diet-1.3 =
libx11-diet-1.4.4}/fix-disable-xlocale.diff (90%)
rename meta/recipes-graphics/xorg-lib/{libx11-diet-1.3 =
libx11-diet-1.4.4}/fix-utf8-wrong-define.patch (88%)
create mode 100644
meta/recipes-graphics/xorg-lib/libx11-diet-1.4.4/keysymdef_include.patch
create mode 100644
meta/recipes-graphics/xorg-lib/libx11-diet-1.4.4/x11_disable_makekeys.patch
rename meta/recipes-graphics/xorg-lib/{libx11-diet_1.3.bb =
libx11-diet_1.4.4.bb} (51%)
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] distcc: make distccmon-gnome optional and default to off
On Tue, 2011-11-15 at 08:58 +0100, Koen Kooi wrote: Op 14 nov. 2011, om 22:48 heeft Richard Purdie het volgende geschreven: On Mon, 2011-11-14 at 21:55 +0100, Koen Kooi wrote: Op 14 nov. 2011, om 21:39 heeft Richard Purdie het volgende geschreven: On Mon, 2011-11-14 at 20:17 +0100, Koen Kooi wrote: I think splitting distccmon-gnome into a seperate recipe is a better idea. I think that makes sense in some cases but I'd hate for it to become the default approach for issues like this as the duplication of code, parsing and build time etc. grate on me. Do we really need separate recipes? I think for this case, yes. And I'll happily trade needing extra buildtime for not needing USEFLAGS. The proposals for alternative recipes for the different combinations got voted down and PACKAGECONFIG was the preferred solution. I can't say I personally like everything about the outcome. I do however understand why we've ended up in that position and don't intend to undermine the usefulness of it. I'll probably take this patch as it improves the situation IMO (and is easy to change the configuration from a distro config if anyone does have an issue with it being disabled). This patch changes the default behaviour in a way that distros need to update their configs in order to keep the status quo. I know I use distccmon-gnome on my boards, but will I remember 2 months from now that this patch went in? I asked this before in a different context, but I'll ask again: do you expect distro maintainers to vet each and every commit that goes into OE-core to find out when default got (silently) changed? USEFLAGS should be a last resort when having seperate recipes doesn't work out, not a default cure. The discussion and decision went against this, rightly or wrongly PACKAGECONFIG is here and we should start to use it. In some cases it will help you a lot, in others it will cause you a bit more work. Such is life. Let's move this to the TSC and see if we can get this crap removed. Lets revisit the original problem - how can a user disable something like X11 from being built when they don't need/want/care about it? We have the layers mechanism but I don't think its reasonable for them to have to bbappend everything with an optional X dependency which was the only option previously available. I can't say I love the PACKAGECONFIG code but equally I'm not aware of any better proposal for solving a real world issue a significant portion of the userbase has in some form (be it X11, gstreamer plugins or other areas). There is already an existing ruling that USEFLAGS should be a last resort. There was a discussion about *not* calling these USEFLAGS... I'm tired of yocto-marketing feel good patches making life harder for people actually using oe-core and its output. I can think of several actual users who find PACKAGECONFIG makes their life much easier. I'd guess they're not proper users though? You keep talking about them and us and I'm really getting sick of it. The whole point is we work as one team on OE-Core. This also means we also take collective responsibility for actions (disagree and commit). There are a ton of hoops I jump through when trying to maintain OE-Core to ensure its not just me but everyone gets time for review, discussion etc. of patches and that there is a decision making process which involved others for major decisions (the TSC). Decisions around PACKAGECONFIG were nothing to do with Yocto, Yocto didn't ask for it. Since OE-Core committed to that direction, yes, Yocto people have written some patches using it. Yocto did ensure during the discussion about that feature it could solve some problems Yocto was aware of. Its ironic I'm now in the position I'm defending something I was never keen on (but I do understand why on balance we probably do need it). Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] distcc: make distccmon-gnome optional and default to off
On Tue, 2011-11-15 at 09:47 +0100, Paul Menzel wrote: Am Montag, den 14.11.2011, 21:48 + schrieb Richard Purdie: On Mon, 2011-11-14 at 21:55 +0100, Koen Kooi wrote: Op 14 nov. 2011, om 21:39 heeft Richard Purdie het volgende geschreven: On Mon, 2011-11-14 at 20:17 +0100, Koen Kooi wrote: I think splitting distccmon-gnome into a seperate recipe is a better idea. I think that makes sense in some cases but I'd hate for it to become the default approach for issues like this as the duplication of code, parsing and build time etc. grate on me. Do we really need separate recipes? I think for this case, yes. And I'll happily trade needing extra buildtime for not needing USEFLAGS. The proposals for alternative recipes for the different combinations got voted down and PACKAGECONFIG was the preferred solution. Where is this vote (and discussion) documented? I found nothing in the OE Wiki and searching for it with »openembedded packageconfig vote oe-core list« brought up only some minutes [1]. I also do not remember anything on openembedded-devel where such general discussion definitely belong in my opinion. It would be great if somebody could help me by giving me an URL. The reference I could find was: http://lists.linuxtogo.org/pipermail/tsc/2011-October/000302.html which asked for objections amongst the TSC members, non were received. I'm drawing a blank finding the previous discussion, I think there was a different term used and I can't think what it was which makes searching hard. There was also discussion of the actual patches on the mailing list (which IMO is where the discussion should really happen). Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Reproducible build problem with BB_NUMBER_THREADS=8
Hi, I often meet a problem related to C++ headers which are not found (despite existing)n often when bitbake starts compiling mysql directfb. I tested on 2 build hosts (both with Core i7, one i686 ubuntu, one x64_64 Fedora) and manage to reproduce the problem easily with BB_NUMBER_THREADS=8 in both cases. The configuration is quite simple : angstrom setup script + beagleboard machine + bitbake qt4e-demo-image with PARALLEL_MAKE = -j6 BB_NUMBER_THREADS = 8 Please find attached the 2 logs : - log1.txt (with one custom overlay containing a custom image) : mysql fails with | ../include/my_global.h:1516:15: fatal error: new: No such file or directory the file exists : build/tmp-angstrom_2010_x-eglibc/sysroots/beagleboard/usr/include/c++/new it seems that include/c++ is not in the header search path reducing BB_NUMBER_THREADS to 2 leads to the same kind of problem in libcgroup : | libcg_ba.cpp:18:18: fatal error: string: No such file or directory the file exists : build/tmp-angstrom_2010_x-eglibc/sysroots/beagleboard/usr/include/c++/debug/string = the only solution was to remove tmp and start again with a reduced BB_NUMBER_THREADS - log2.txt (plain oe-core + angstrom setup to remove the doubt of my overlay being the source of the problem) : directfb fails with mkdgifft.cpp:64:16: fatal error: list: No such file or directory the file exists : build/tmp-angstrom_2010_x-eglibc/sysroots/beagleboard/usr/include/c++/list here again, it seems that include/c++ is not in the header search path = I reduced BB_NUMBER_THREADS to 1 and launched again bitbake (build actually in progress). The workaround is to reduce BB_NUMBER_THREADS to =4 which seems to never bring the problem (at least for a dozen of builds). Does anyone meet the same problem ? Any idea of what could be wrong here ? Thanks, Eric Buyild host : CPU : Intel(R) Core(TM) i7-2720QM CPU @ 2.20GHz RAM : 8GB Distribution : Fedora release 15 (Lovelock) x86_64 Filesystem : /dev/mapper/vg_e6520eb-lv_home on /home type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered) PARALLEL_MAKE = -j6 BB_NUMBER_THREADS = 8 [ebenard@e6520eb setup-scripts]$ bitbake hardware-bringup-image eukrea-qtdemo-image qt4e-demo-image OE Build Configuration: BB_VERSION= 1.15.0 TARGET_ARCH = arm TARGET_OS = linux-gnueabi MACHINE = beagleboard DISTRO= angstrom DISTRO_VERSION= v2011.11-core TUNE_FEATURES = armv7a vfp neon cortexa8 TARGET_FPU= vfp-neon meta-angstrom = master:fcc61ee9da3c76db82fe780db9441555c8d5f115 meta-oe meta-efl meta-gpe meta-gnome meta-xfce = master:1e93fb3cb6d716ad811bd26154fdcec42195c360 meta-opie = master:bd11184f5b5a8037444b22019c73249a967a4eb7 meta-ti = master:a0b13fc0e549390c8e2e24004117d0275a0bb966 meta-ettus= master:f097bb61772d07610d84a668dc19a47e180962b3 meta-efikamx = master:2ef47fdd4e8232d766c0c63d9427253ee56e31d0 meta-nslu2= master:17853811179f2760791c6b138f96e9dd15493517 meta-htc meta-nokia meta-openmoko meta-palm = master:11f5fab0c4e382c99e2fb89de5121a93d7031816 meta-handheld = master:c83f57f0ec2b43c22f0fd628fe5ad17b330b972d meta-sugarbay meta-crownbay meta-emenlow meta-fishriver meta-jasperforest meta-n450 = master:2a41ae377613b1f14829179f437aa76bbb1bc39e meta-eukrea meta-eukrea-cpuimx35 = master:ddcc090984f1b55600aa948d6315e4b4815991ca meta = master:f2316ff39670ed99382411e15ac035550360fbdd | arm-angstrom-linux-gnueabi-g++ -march=armv7-a -fno-tree-vectorize -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 -mthumb-interwork -mno-thumb --sysroot=/home/ebenard/WORK/IMX/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/beagleboard -DDEFAULT_BASEDIR=\/usr\ -DMYSQL_DATADIR=\/var/mysql\ -DDEFAULT_CHARSET_HOME=\/usr\ -DSHAREDIR=\/usr/share/mysql\ -DDEFAULT_HOME_ENV=MYSQL_HOME -DDEFAULT_GROUP_SUFFIX_ENV=MYSQL_GROUP_SUFFIX -DDEFAULT_SYSCONFDIR=\/etc/mysql\ -DHAVE_CONFIG_H -I. -I../include -I../include -I../include -I.-O2 -pipe -g -feliminate-unused-debug-types -fpermissive -fvisibility-inlines-hidden -fvisibility-inlines-hidden -fno-implicit-templates -fno-exceptions -fno-rtti -c -o my_new.o my_new.cc | In file included from mysys_priv.h:16:0, | from my_new.cc:21: | ../include/my_global.h:1516:15: fatal error: new: No such file or directory | compilation terminated. | make[1]: *** [my_new.o] Error 1 | make[1]: Leaving directory `/home/ebenard/WORK/IMX/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/mysql5-5.1.40-r5/mysql-5.1.40/mysys' | make: *** [all-recursive] Error 1 | + die 'oe_runmake failed' | + bbfatal 'oe_runmake failed' | + echo 'ERROR: oe_runmake failed' | ERROR: oe_runmake failed | + exit 1 | ERROR: Function 'do_compile' failed (see
Re: [OE-core] [PATCH 3/4] distcc: make distccmon-gnome optional and default to off
On Tuesday 15 November 2011 08:58:00 Koen Kooi wrote: Let's move this to the TSC and see if we can get this crap removed. There is already an existing ruling that USEFLAGS should be a last resort. I'm tired of yocto-marketing feel good patches making life harder for people actually using oe-core and its output. Marketing has nothing to do with it. All I really want is to fix the problem that the build blows up if you try to build any image for any of the qemu* machines with x11 removed from DISTRO_FEATURES. I think it would have been nice to also be able to avoid having to build gtk+ and everything it depends upon for all such images regardless of whether or not it is really needed, but I can live without making that further cleanup if it's going to cause such an uproar. If PACKAGE_CONFIG is not an acceptable solution to this problem I'll accept checking for x11 in DISTRO_FEATURES alone, if that's what it takes to get the real problem fixed. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] mime.bbclass: fix typo
On Mon, 2011-11-14 at 23:16 -0500, Connor Abbott wrote: Before this patch, nautilus would fail with: ERROR: Error executing a python function in /home/connor/angstrom/sources/meta-openembedded/meta-gnome/recipes-gnome/nautilus/nautilus_2.32.2.bb: NameError: global name 'dgetVar' is not defined Signed-off-by: Connor Abbott cwabbo...@gmail.com --- meta/classes/mime.bbclass |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Merged to master, thanks. Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] distcc: make distccmon-gnome optional and default to off
Op 15 nov. 2011, om 12:44 heeft Paul Eggleton het volgende geschreven: On Tuesday 15 November 2011 08:58:00 Koen Kooi wrote: Let's move this to the TSC and see if we can get this crap removed. There is already an existing ruling that USEFLAGS should be a last resort. I'm tired of yocto-marketing feel good patches making life harder for people actually using oe-core and its output. Marketing has nothing to do with it. All I really want is to fix the problem that the build blows up if you try to build any image for any of the qemu* machines with x11 removed from DISTRO_FEATURES. Isn't a better question Why are all images for qemu machines forcing distcc to get built?? I think it would have been nice to also be able to avoid having to build gtk+ and everything it depends upon for all such images regardless of whether or not it is really needed, but I can live without making that further cleanup if it's going to cause such an uproar. If PACKAGE_CONFIG is not an acceptable solution to this problem I'll accept checking for x11 in DISTRO_FEATURES alone, if that's what it takes to get the real problem fixed. Or just make a seperate recipe for distccmon-gnome, that would avoid the need of any USEFLAGS. Should be just a matter of require distcc_$PV.bb ; EXTRA_OEOCONF = foo regards, Koen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] alsa-lib: use PKGSUFFIX for every package to resolve multiple runtime providers from target and nativesdk
On Mon, 2011-11-14 at 14:07 +0100, Martin Jansa wrote: Signed-off-by: Martin Jansa martin.ja...@gmail.com --- meta/recipes-multimedia/alsa/alsa-lib_1.0.24.1.bb | 19 +++ 1 files changed, 11 insertions(+), 8 deletions(-) Merged to master, thanks. Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libnss-mdns: avoid race condition in postinst
On Mon, 2011-11-14 at 13:06 +, Phil Blundell wrote: Writing to /tmp/nsswitch.conf leads to a race condition if two copies of the postinst are running simultaneously. Fix this by modifying /etc/nsswitch.conf in place using sed -i. Also make the same change to the prerm for consistency although the race will not occur here in practice. Signed-off-by: Phil Blundell ph...@gnu.org --- .../libnss-mdns/libnss-mdns_0.10.bb|8 +++- 1 files changed, 3 insertions(+), 5 deletions(-) Merged to master, thanks. Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH][oe-core 00/22] QT4, thumb, subversion, mesa, libsdl, time, util-linux, kbd changes
On Fri, 2011-11-11 at 17:28 +0100, Martin Jansa wrote: Martin Jansa: libatomics-ops: force ARM mode pulseaudio-0.9.23: force ARM mode aspell: force ARM mode webkit-gtk: force arm mode to work around binutils segfault subversion: add 1.7.0 with native support and negative D_P for now alsa-lib: add nativesdk BBCLASSEXTEND time: rename files dir to time-1.7 for faster lookup time: drop default S and 2 useless comments time: use u-a for time, conflicts with busybox util-linux: use u-a for flock and blockdev, conflicts with busybox util-linux: add missing u-a calls for setsid chrt util-linux: bump PR after u-a changes kbd: use u-a for chvt, deallocvt, fgconssole, openvt, conflicts with busybox Simon Busch (1): qt4-x11-free: bring back pkg-config fixups The above have all merged. base.bbclass: add subversion-native to DEPENDS if there is svn:// in SRC_URI I've taken this but I've also fixed the default ASSUME_PROVIDED to include subversion-native instead of svn-native in bitbake.conf. This may need some further thought but at least the system is more correct now. mesa: package gl/egl/osmesa to separate packages This one I really want to take but there are some PR bumps missing or some renaming missing somewhere as its causing build issues :/. I'm holding off until these are tracked down. mesa-common: install internal GL headers to libgl-dev This one is a WIP. libsdl: drop unused files libsdl: rename files dir to libsdl-1.2.14 for faster lookup libsdl: enable cdrom, alsa and tslib, disable rpath and add few fixes from meta-oe libsdl: enable alsa/opengl based on PACKAGECONFIG and respect DISTRO_FEATURES libsdl: replace tabs with spaces There were some issues Saul was seeing around libsdl so I've left these for now as we're having a few too many build issues atm :/. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] distcc: make distccmon-gnome optional and default to off
On Tue, 2011-11-15 at 13:15 +0100, Koen Kooi wrote: Op 15 nov. 2011, om 12:44 heeft Paul Eggleton het volgende geschreven: On Tuesday 15 November 2011 08:58:00 Koen Kooi wrote: Let's move this to the TSC and see if we can get this crap removed. There is already an existing ruling that USEFLAGS should be a last resort. I'm tired of yocto-marketing feel good patches making life harder for people actually using oe-core and its output. Marketing has nothing to do with it. All I really want is to fix the problem that the build blows up if you try to build any image for any of the qemu* machines with x11 removed from DISTRO_FEATURES. Isn't a better question Why are all images for qemu machines forcing distcc to get built?? Both questions are valid: a) If I build distcc and I have x11 disabled, it shouldn't break. b) Should qemu include distcc? Traditionally, qemu-config does pull it in. Why? The qemu scripts allow pass through of compilation to the build system instead of doing it under emulation for a significant speed up in compile time. It was originally felt that it should therefore maximally autoconfigure that stuff transparently to the user. If we don't think that is useful we can drop it. That is a separate discussion to a) which seems to be the contentious problem and solving b) is just hiding from the issue. Or just make a seperate recipe for distccmon-gnome, that would avoid the need of any USEFLAGS. Should be just a matter of require distcc_ $PV.bb ; EXTRA_OEOCONF = foo and the rest (resolving the various packaging conflicts so that distcc-gnome only packages the gnome pieces and removes everything else). To put this quite simply, I think there is no good reason we shouldn't use the mechanism we've selected to handle this kind of problem. We should have defaults the reflect backwards compatibility. Other than that where is the problem other than a general objection to PACKAGECONFIG? Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] distcc: make distccmon-gnome optional and default to off
Op 15 nov. 2011, om 14:43 heeft Richard Purdie het volgende geschreven: On Tue, 2011-11-15 at 13:15 +0100, Koen Kooi wrote: Op 15 nov. 2011, om 12:44 heeft Paul Eggleton het volgende geschreven: On Tuesday 15 November 2011 08:58:00 Koen Kooi wrote: Let's move this to the TSC and see if we can get this crap removed. There is already an existing ruling that USEFLAGS should be a last resort. I'm tired of yocto-marketing feel good patches making life harder for people actually using oe-core and its output. Marketing has nothing to do with it. All I really want is to fix the problem that the build blows up if you try to build any image for any of the qemu* machines with x11 removed from DISTRO_FEATURES. Isn't a better question Why are all images for qemu machines forcing distcc to get built?? Both questions are valid: a) If I build distcc and I have x11 disabled, it shouldn't break. b) Should qemu include distcc? Traditionally, qemu-config does pull it in. Why? The qemu scripts allow pass through of compilation to the build system instead of doing it under emulation for a significant speed up in compile time. It was originally felt that it should therefore maximally autoconfigure that stuff transparently to the user. If we don't think that is useful we can drop it. That is a separate discussion to a) which seems to be the contentious problem and solving b) is just hiding from the issue. Or just make a seperate recipe for distccmon-gnome, that would avoid the need of any USEFLAGS. Should be just a matter of require distcc_ $PV.bb ; EXTRA_OEOCONF = foo and the rest (resolving the various packaging conflicts so that distcc-gnome only packages the gnome pieces and removes everything else). To put this quite simply, I think there is no good reason we shouldn't use the mechanism we've selected to handle this kind of problem. We should have defaults the reflect backwards compatibility. Other than that where is the problem other than a general objection to PACKAGECONFIG? It forces a choice when there is a solution where things can coexist. regards, Koen signature.asc Description: Message signed with OpenPGP using GPGMail ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Reproducible build problem with BB_NUMBER_THREADS=8
Le 15/11/2011 12:03, Eric Bénard a écrit : - log2.txt (plain oe-core + angstrom setup to remove the doubt of my overlay being the source of the problem) : directfb fails with mkdgifft.cpp:64:16: fatal error: list: No such file or directory the file exists : build/tmp-angstrom_2010_x-eglibc/sysroots/beagleboard/usr/include/c++/list here again, it seems that include/c++ is not in the header search path = I reduced BB_NUMBER_THREADS to 1 and launched again bitbake (build actually in progress). this build also crashed a few hours later on gnutls with : | ./includes/gnutls/gnutlsxx.h:4:21: fatal error: exception: No such file or directory Here again the only solution is to remove tmp and start again with a reduced BB_NUMBER_THREADS. Eric ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] distcc: make distccmon-gnome optional and default to off
On Tue, 2011-11-15 at 14:59 +0100, Koen Kooi wrote: Op 15 nov. 2011, om 14:43 heeft Richard Purdie het volgende geschreven: To put this quite simply, I think there is no good reason we shouldn't use the mechanism we've selected to handle this kind of problem. We should have defaults the reflect backwards compatibility. Other than that where is the problem other than a general objection to PACKAGECONFIG? It forces a choice when there is a solution where things can coexist. There are multiple ways of coexisting and the configuration changing based on DISTRO_FEATURES doesn't force a choice either. Bottom line is we discussed and agreed a way of handling this and I'd really like to have one preferred way of doing so. IMO the two recipe approach duplicates build time and adds complexity into the recipe which we can avoid using PACKAGECONFIG. Yes that has complexities of its own but the sooner we start experimenting with it, the sooner we'll work through any issues. There are certainly ways we can make things neater. If it really does turn out to be a bad idea we can come up with good reasons why we should get rid of it. FWIW, if you want an example of how badly wrong a two recipe approach can get, see the dpkg/update-alternatives mess I fixed yesterday. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] distcc: make distccmon-gnome optional and default to off
Op 15 nov. 2011, om 15:42 heeft Richard Purdie het volgende geschreven: On Tue, 2011-11-15 at 14:59 +0100, Koen Kooi wrote: Op 15 nov. 2011, om 14:43 heeft Richard Purdie het volgende geschreven: To put this quite simply, I think there is no good reason we shouldn't use the mechanism we've selected to handle this kind of problem. We should have defaults the reflect backwards compatibility. Other than that where is the problem other than a general objection to PACKAGECONFIG? It forces a choice when there is a solution where things can coexist. There are multiple ways of coexisting and the configuration changing based on DISTRO_FEATURES doesn't force a choice either. It does force a choice, since you don't want to change DISTRO_FEATURES when distributing binaries. If changing it is safe, then it isn't a DISTRO_FEATURE. regards, Koen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] distcc: make distccmon-gnome optional and default to off
On Tue, 2011-11-15 at 15:55 +0100, Koen Kooi wrote: Op 15 nov. 2011, om 15:42 heeft Richard Purdie het volgende geschreven: On Tue, 2011-11-15 at 14:59 +0100, Koen Kooi wrote: Op 15 nov. 2011, om 14:43 heeft Richard Purdie het volgende geschreven: To put this quite simply, I think there is no good reason we shouldn't use the mechanism we've selected to handle this kind of problem. We should have defaults the reflect backwards compatibility. Other than that where is the problem other than a general objection to PACKAGECONFIG? It forces a choice when there is a solution where things can coexist. There are multiple ways of coexisting and the configuration changing based on DISTRO_FEATURES doesn't force a choice either. It does force a choice, since you don't want to change DISTRO_FEATURES when distributing binaries. If changing it is safe, then it isn't a DISTRO_FEATURE. I'd expect a given distro to be able to figure out in advance whether it intends to have X11 or not? If unsure you leave it present... I really don't see the problem here. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] distcc: make distccmon-gnome optional and default to off
Op 15 nov. 2011, om 16:12 heeft Richard Purdie het volgende geschreven: On Tue, 2011-11-15 at 15:55 +0100, Koen Kooi wrote: Op 15 nov. 2011, om 15:42 heeft Richard Purdie het volgende geschreven: On Tue, 2011-11-15 at 14:59 +0100, Koen Kooi wrote: Op 15 nov. 2011, om 14:43 heeft Richard Purdie het volgende geschreven: To put this quite simply, I think there is no good reason we shouldn't use the mechanism we've selected to handle this kind of problem. We should have defaults the reflect backwards compatibility. Other than that where is the problem other than a general objection to PACKAGECONFIG? It forces a choice when there is a solution where things can coexist. There are multiple ways of coexisting and the configuration changing based on DISTRO_FEATURES doesn't force a choice either. It does force a choice, since you don't want to change DISTRO_FEATURES when distributing binaries. If changing it is safe, then it isn't a DISTRO_FEATURE. I'd expect a given distro to be able to figure out in advance whether it intends to have X11 or not? If unsure you leave it present... I really don't see the problem here. The patch here doesn't use 'x11', but 'gui' as PACKAGECONFIG. Triggering on x11 is fine in this case. regards, Koen signature.asc Description: Message signed with OpenPGP using GPGMail ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] distcc: make distccmon-gnome optional and default to off
On Tuesday 15 November 2011 15:55:38 Koen Kooi wrote: Op 15 nov. 2011, om 15:42 heeft Richard Purdie het volgende geschreven: On Tue, 2011-11-15 at 14:59 +0100, Koen Kooi wrote: Op 15 nov. 2011, om 14:43 heeft Richard Purdie het volgende geschreven: To put this quite simply, I think there is no good reason we shouldn't use the mechanism we've selected to handle this kind of problem. We should have defaults the reflect backwards compatibility. Other than that where is the problem other than a general objection to PACKAGECONFIG? It forces a choice when there is a solution where things can coexist. There are multiple ways of coexisting and the configuration changing based on DISTRO_FEATURES doesn't force a choice either. It does force a choice, since you don't want to change DISTRO_FEATURES when distributing binaries. If changing it is safe, then it isn't a DISTRO_FEATURE. It forces nothing - in fact it allows a distro to make choices. DISTRO_FEATURES and PACKAGECONFIG are both expressions of distro policy which is intended to be set before binaries are produced; PACKAGECONFIG is simply on a per-recipe basis rather than across multiple recipes. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] distcc: make distccmon-gnome optional and default to off
On Tuesday 15 November 2011 16:23:07 Koen Kooi wrote: The patch here doesn't use 'x11', but 'gui' as PACKAGECONFIG. Triggering on x11 is fine in this case. Unless I've misunderstood, PACKAGECONFIG's namespace is specific to the package; so it does not really matter what it is called. If we're talking about changing to use DISTRO_FEATURES then yes, x11 would be the feature to check for. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 00/12] Recipe upgrades, fixes and additions
On 11/08/2011 06:18 AM, Richard Purdie wrote: On Mon, 2011-11-07 at 16:10 -0800, Joshua Lock wrote: All, Here's a series of patches I developed whilst trying to play around with some Clutter based software. The interesting pieces may be: Clutter 1.8 series recipes - do we want/need to keep clutter 1.6 around? Are we OK with continuing to namespace the clutter recipes by clutter version? Yes, I think this makes sense. Why do we want to continue the clutter the namespace with version numbers? Was this not for a past issue with mis-matched API/ABI? If that problem is solved, then next remove that version info. Sau! Gconf - I've pulled in GConf from upstream as the D-Bus backend is maintained there now. For this I pulled in the gnome-related classes from meta-oe as they simplified this recipe and I've been wanting to see them merged for some time. I had to drop this patch as the gnome classes need a bit more work. I'd like to get gconf resolved though. Pulseaudio - whilst adding a required build dependency I changed the recipe so that it doesn't require X unless the X11 distro feature is enabled. So I merged the series apart from the gnome class and gconf pieces. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Reproducible build problem with BB_NUMBER_THREADS=8
Date: Tue, 15 Nov 2011 15:32:36 +0100 From: Eric B?nard e...@eukrea.com Subject: Re: [OE-core] Reproducible build problem with BB_NUMBER_THREADS=8 To: Patches and discussions about the oe-core layer openembedded-core@lists.openembedded.org Message-ID: 4ec27804.7060...@eukrea.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Le 15/11/2011 12:03, Eric B?nard a ?crit : - log2.txt (plain oe-core + angstrom setup to remove the doubt of my overlay being the source of the problem) : directfb fails with mkdgifft.cpp:64:16: fatal error: list: No such file or directory the file exists : build/tmp-angstrom_2010_x- eglibc/sysroots/beagleboard/usr/include/c++/list here again, it seems that include/c++ is not in the header search path = I reduced BB_NUMBER_THREADS to 1 and launched again bitbake (build actually in progress). this build also crashed a few hours later on gnutls with : | ./includes/gnutls/gnutlsxx.h:4:21: fatal error: exception: No such file or directory Here again the only solution is to remove tmp and start again with a reduced BB_NUMBER_THREADS. Eric I actually just ran into this very problem late last week. I have narrowed it down to a problem with one of the gcc recipes (gcc-cross, gcc-cross-initial, gcc-cross-intermediate, gcc-runtime) being built. I seem to get the problem when my PARALLEL_MAKE 2. If I run into the problem, dial back PARALLEL_MAKE to 2, cleanall the above 4 recipes, and then continue, the problem seems to go away. I don't really have any extra cycles to continue my investigation, but hopefully that helps put someone on the right track. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Reproducible build problem with BB_NUMBER_THREADS=8
On Tue, Nov 15, 2011 at 12:03:45PM +0100, Eric Bénard wrote:
Hi,
I often meet a problem related to C++ headers which are not found
(despite existing)n often when bitbake starts compiling mysql
directfb.
I tested on 2 build hosts (both with Core i7, one i686 ubuntu, one
x64_64 Fedora) and manage to reproduce the problem easily with
BB_NUMBER_THREADS=8 in both cases.
The configuration is quite simple :
angstrom setup script + beagleboard machine + bitbake qt4e-demo-image
with
PARALLEL_MAKE = -j6
BB_NUMBER_THREADS = 8
Hi Eric,
I found another problem with the crosscompiler setup and c++,
while compile llvm with cmake.
In recipes-devtools/gcc/gcc-configure-cross.inc we set
EXTRA_OECONF_PATHS =
--with-local-prefix=${STAGING_DIR_TARGET}${target_exec_prefix} \
--with-gxx-include-dir=${target_includedir}/c++ \
--with-sysroot=${STAGING_DIR_TARGET} \
--with-build-sysroot=${STAGING_DIR_TARGET}
which results in a headersearch path for c++
.../usr/usr/include/c++
unfornatly I do not have the time to test it some more. But this little patch
plus INC bumping
sovled it for my setup:
-EXTRA_OECONF_PATHS =
--with-local-prefix=${STAGING_DIR_TARGET}${target_exec_prefix} \
+EXTRA_OECONF_PATHS = --with-local-prefix=${STAGING_DIR_TARGET} \
Bye Henning
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libconvert-asn1-perl/libtimedate-perl: Convert to use allarch
Both these recipes generate architecture independent packages.
They can safely use the allarch class to ensure they really
are indepentent from the target compiler and so forth and
hence ensure sstate packages with good dependencies.
[YOCTO #1075]
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/recipes-extended/perl/libconvert-asn1-perl_0.22.bb
b/meta/recipes-extended/perl/libconvert-asn1-perl_0.22.bb
index 48e107c..98ca804 100644
--- a/meta/recipes-extended/perl/libconvert-asn1-perl_0.22.bb
+++ b/meta/recipes-extended/perl/libconvert-asn1-perl_0.22.bb
@@ -11,10 +11,8 @@ SRC_URI[sha256sum] =
be63d5cc715d7306e54b41d3c68c3617ca306289cff619a2ca43505e35
S = ${WORKDIR}/Convert-ASN1-${PV}
-inherit cpan
+inherit cpan allarch
EXTRA_PERLFLAGS = -I
${STAGING_LIBDIR_NATIVE}/perl-native/perl/${@get_perl_version(d)}
-BBCLASSEXTEND=native
-
-PACKAGE_ARCH = all
+BBCLASSEXTEND = native
diff --git a/meta/recipes-extended/perl/libtimedate-perl_1.20.bb
b/meta/recipes-extended/perl/libtimedate-perl_1.20.bb
index c925980..67c5836 100644
--- a/meta/recipes-extended/perl/libtimedate-perl_1.20.bb
+++ b/meta/recipes-extended/perl/libtimedate-perl_1.20.bb
@@ -10,13 +10,12 @@ SRC_URI =
http://search.cpan.org/CPAN/authors/id/G/GB/GBARR/TimeDate-${PV}.tar.
S = ${WORKDIR}/TimeDate-${PV}
-inherit cpan
+inherit cpan allarch
-BBCLASSEXTEND=native
+BBCLASSEXTEND = native
RDEPENDS_${PN}_virtclass-native =
RDEPENDS_${PN} += perl-module-carp perl-module-exporter perl-module-strict
perl-module-time-local
-PACKAGE_ARCH = all
SRC_URI[md5sum] = 7da7452bce4c684e4238e6d09b390200
SRC_URI[sha256sum] =
f8251a791f6692c69952b4af697c01df93981ad1ab133279d034656a03cd3755
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Reproducible build problem with BB_NUMBER_THREADS=8
On Tue, 2011-11-15 at 21:19 +0100, Henning Heinold wrote:
On Tue, Nov 15, 2011 at 12:03:45PM +0100, Eric Bénard wrote:
Hi,
I often meet a problem related to C++ headers which are not found
(despite existing)n often when bitbake starts compiling mysql
directfb.
I tested on 2 build hosts (both with Core i7, one i686 ubuntu, one
x64_64 Fedora) and manage to reproduce the problem easily with
BB_NUMBER_THREADS=8 in both cases.
The configuration is quite simple :
angstrom setup script + beagleboard machine + bitbake qt4e-demo-image
with
PARALLEL_MAKE = -j6
BB_NUMBER_THREADS = 8
Hi Eric,
I found another problem with the crosscompiler setup and c++,
while compile llvm with cmake.
In recipes-devtools/gcc/gcc-configure-cross.inc we set
EXTRA_OECONF_PATHS =
--with-local-prefix=${STAGING_DIR_TARGET}${target_exec_prefix} \
--with-gxx-include-dir=${target_includedir}/c++ \
--with-sysroot=${STAGING_DIR_TARGET} \
--with-build-sysroot=${STAGING_DIR_TARGET}
which results in a headersearch path for c++
.../usr/usr/include/c++
unfornatly I do not have the time to test it some more. But this little patch
plus INC bumping
sovled it for my setup:
-EXTRA_OECONF_PATHS =
--with-local-prefix=${STAGING_DIR_TARGET}${target_exec_prefix} \
+EXTRA_OECONF_PATHS = --with-local-prefix=${STAGING_DIR_TARGET} \
How does that cause something which sometimes works and sometimes does
not? Either it would work or wouldn't if this were the problem but not
sometimes?
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED PULL 03/16] apr-util: extend sed call to fix libtool patch for case without SHELL in LIBTOOL variable
From: Martin Jansa martin.ja...@gmail.com
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/recipes-support/apr/apr-util_1.3.12.bb |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-support/apr/apr-util_1.3.12.bb
b/meta/recipes-support/apr/apr-util_1.3.12.bb
index 0064c51..62d72cf 100644
--- a/meta/recipes-support/apr/apr-util_1.3.12.bb
+++ b/meta/recipes-support/apr/apr-util_1.3.12.bb
@@ -40,6 +40,8 @@ do_configure_prepend_virtclass-native() {
}
do_configure_append_virtclass-native() {
sed -i s#LIBTOOL=\$(SHELL) \$(apr_builddir)#LIBTOOL=\$(SHELL)
${STAGING_BINDIR_NATIVE}# ${S}/build/rules.mk
+ # sometimes there isn't SHELL
+ sed -i s#LIBTOOL=\$(apr_builddir)#LIBTOOL=${STAGING_BINDIR_NATIVE}#
${S}/build/rules.mk
}
FILES_${PN} += ${libdir}/apr-util-1/apr_dbm_gdbm-1.so
--
1.7.6.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED PULL 00/16] Various Updates and Fixes
Richard,
This request has the patches to correctly build subversion-native,
I tested this and ensured we do not have a circular dependency issue.
I am not sure about the FILESDIR addition in the libx11-diet patch, so I
would like you review of that one.
Thanks
Sau!
The following changes since commit da8425174529f10e16cde21fbea7f804284c38ae:
alsa-lib: add nativesdk BBCLASSEXTEND (2011-11-15 12:22:58 +)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib sgw/stage
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/stage
Dmitry Eremin-Solenikov (2):
screenshot: rename to sato-screenshot
gobject-introspection: update frome meta-oe
Martin Jansa (3):
base.bbclass: add subversion-native to DEPENDS if there is svn:// in
SRC_URI
default-providers: add alsa to resolve multiple runtime providers
apr-util: extend sed call to fix libtool patch for case without SHELL
in LIBTOOL variable
Michael Brown (1):
gcc-4.6: fix toolchain build for SH4
Saul Wold (8):
libgcrypt: add BBCLASSEXTEND native for gnutls-native
libgpg-error: add BBCLASSEXTEND native for libgcrypts and
gnutls-native
file: update to 5.09
gnu-config: update to git HEAD
gnu-config: Create 201 release
bitbake.conf: Update ASSUME_PROVIDED
boost: Update to 1.47.0 Cleanup
distro_tracking: Refect Recipe Updates Status
Xiaofeng Yan (2):
libx11-diet: update to 1.4.4
directfb: update to 1.4.15
meta/classes/base.bbclass |8 +-
meta/conf/bitbake.conf |5 -
meta/conf/distro/include/default-providers.inc |1 +
.../conf/distro/include/distro_tracking_fields.inc | 50 ++--
.../file/file/fix_version_check.patch | 21 ++
.../file/{file_5.04.bb = file_5.09.bb}|9 +-
meta/recipes-devtools/gcc/gcc-cross4.inc |2 +
.../gnu-config/config-guess-uclibc.patch | 145 +--
.../gnu-config/gnu-config_2011.bb | 41 +++
.../{gnu-config_20080123.bb = gnu-config_git.bb} | 15 +-
.../gnome/gobject-introspection/configure.patch| 27 --
.../gnome/gobject-introspection/pathfix.patch | 27 --
.../use-usr-bin-env-for-python.patch | 20 ++
.../gnome/gobject-introspection_git.bb | 32 ++-
.../{directfb_1.4.12.bb = directfb_1.4.15.bb} |9 +-
.../directfb-1.2.x-fix-pkgconfig-cflags.patch | 36 ++--
.../xorg-lib/libx11-diet-1.3/include_fix.patch | 25 --
.../xorg-lib/libx11-diet-1.3/nodolt.patch | 14 -
.../X18NCMSstubs.diff |1 +
.../fix-disable-xlocale.diff |1 +
.../fix-utf8-wrong-define.patch|2 +
.../libx11-diet-1.4.4/keysymdef_include.patch | 23 ++
.../x11_disable_makekeys.patch | 23 +-
.../{libx11-diet_1.3.bb = libx11-diet_1.4.4.bb} | 17 +-
.../files/fix_ldadd_order.patch|0
.../sato-screenshot_git.bb}|2 +-
meta/recipes-sato/tasks/task-core-x11.bb |2 +-
meta/recipes-support/apr/apr-util_1.3.12.bb|2 +
meta/recipes-support/boost/boost-jam-native.inc| 32 ---
.../boost/boost-jam-native_3.1.18.bb |8 -
.../boost/{boost-36.inc = boost.inc} | 42 +++-
.../boost/{boost_1.44.0.bb = boost_1.47.0.bb} | 13 +-
.../recipes-support/boost/files/1.34.1-gcc43.patch | 226 -
.../boost/files/atomic_count_gcc_atomicity.patch | 15 --
meta/recipes-support/boost/files/gcc41.patch | 16 --
meta/recipes-support/boost/files/gcc43.patch | 258
.../recipes-support/boost/files/linux-uclibc.patch | 12 -
.../boost/files/unit_test_log10f.patch | 22 --
meta/recipes-support/libgcrypt/libgcrypt.inc |2 +
.../libgpg-error/libgpg-error_1.10.bb |2 +
40 files changed, 339 insertions(+), 869 deletions(-)
create mode 100644 meta/recipes-devtools/file/file/fix_version_check.patch
rename meta/recipes-devtools/file/{file_5.04.bb = file_5.09.bb} (79%)
create mode 100644 meta/recipes-devtools/gnu-config/gnu-config_2011.bb
rename meta/recipes-devtools/gnu-config/{gnu-config_20080123.bb =
gnu-config_git.bb} (73%)
delete mode 100644
meta/recipes-gnome/gnome/gobject-introspection/configure.patch
delete mode 100644 meta/recipes-gnome/gnome/gobject-introspection/pathfix.patch
create mode 100644
meta/recipes-gnome/gnome/gobject-introspection/use-usr-bin-env-for-python.patch
rename meta/recipes-graphics/directfb/{directfb_1.4.12.bb =
directfb_1.4.15.bb} (63%)
delete mode 100644
meta/recipes-graphics/xorg-lib/libx11-diet-1.3/include_fix.patch
delete mode 100644 meta/recipes-graphics/xorg-lib/libx11-diet-1.3/nodolt.patch
rename meta/recipes-graphics/xorg-lib/{libx11-diet-1.3 =
[OE-core] [CONSOLIDATED PULL 02/16] default-providers: add alsa to resolve multiple runtime providers
From: Martin Jansa martin.ja...@gmail.com Signed-off-by: Martin Jansa martin.ja...@gmail.com --- meta/conf/distro/include/default-providers.inc |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/meta/conf/distro/include/default-providers.inc b/meta/conf/distro/include/default-providers.inc index afea5e7..79785fb 100644 --- a/meta/conf/distro/include/default-providers.inc +++ b/meta/conf/distro/include/default-providers.inc @@ -19,6 +19,7 @@ VIRTUAL-RUNTIME_update-alternatives ?= update-alternatives-cworth # # Default recipe providers # +PREFERRED_PROVIDER_alsa-lib ?= alsa-lib PREFERRED_PROVIDER_dbus-glib ?= dbus-glib PREFERRED_PROVIDER_dbus-glib-native ?= dbus-glib-native PREFERRED_PROVIDER_gdk-pixbuf ?= gdk-pixbuf -- 1.7.6.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED PULL 06/16] libgcrypt: add BBCLASSEXTEND native for gnutls-native
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/recipes-support/libgcrypt/libgcrypt.inc |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-support/libgcrypt/libgcrypt.inc
b/meta/recipes-support/libgcrypt/libgcrypt.inc
index 989d556..088cd34 100644
--- a/meta/recipes-support/libgcrypt/libgcrypt.inc
+++ b/meta/recipes-support/libgcrypt/libgcrypt.inc
@@ -28,3 +28,5 @@ ARM_INSTRUCTION_SET = arm
# move libgcrypt-config into -dev package
FILES_${PN} = ${libdir}/lib*.so.*
FILES_${PN}-dev += ${bindir} ${libdir}/pkgconfig/*.pc
+
+BBCLASSEXTEND = native
--
1.7.6.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED PULL 05/16] directfb: update to 1.4.15
From: Xiaofeng Yan xiaofeng@windriver.com
The newest version for directfb is 1.5.3 but it's instruction set base on armv6.
The current qemuarm don't have some instructions for armv6 because some codes
of \
the new version of directfb more than 1.5 are realized with assemble
language,for example the lock. \
I update this recipe to 1.4.15 for directfb running more platform.
Signed-off-by: Xiaofeng Yan xiaofeng@windriver.com
---
.../{directfb_1.4.12.bb = directfb_1.4.15.bb} |9 -
.../directfb-1.2.x-fix-pkgconfig-cflags.patch | 36 +--
2 files changed, 24 insertions(+), 21 deletions(-)
rename meta/recipes-graphics/directfb/{directfb_1.4.12.bb =
directfb_1.4.15.bb} (63%)
diff --git a/meta/recipes-graphics/directfb/directfb_1.4.12.bb
b/meta/recipes-graphics/directfb/directfb_1.4.15.bb
similarity index 63%
rename from meta/recipes-graphics/directfb/directfb_1.4.12.bb
rename to meta/recipes-graphics/directfb/directfb_1.4.15.bb
index 4e8203b..71c0876 100644
--- a/meta/recipes-graphics/directfb/directfb_1.4.12.bb
+++ b/meta/recipes-graphics/directfb/directfb_1.4.15.bb
@@ -1,10 +1,15 @@
require directfb.inc
-RV = 1.4-5
+RV = 1.4-6
PR = r0
DEPENDS += sysfsutils
+SRC_URI = \
+http://directfb.org/downloads/Core/DirectFB-1.4/DirectFB-${PV}.tar.gz \
+file://directfb-1.2.x-fix-pkgconfig-cflags.patch \
+
+
EXTRA_OECONF = \
--enable-freetype=yes \
--enable-zlib \
@@ -14,7 +19,7 @@ EXTRA_OECONF = \
--disable-x11 \
-LEAD_SONAME = libdirectfb-1.4.so.5
+LEAD_SONAME = libdirectfb-1.4.so.6
SRC_URI[md5sum] = 2c779c9a8456790c6c29ad85459b2600
SRC_URI[sha256sum] =
b119ab9c5c0c505c23e32d41ae54bd04cb474c5e58900ec0f1cf9482f892f9b2
diff --git
a/meta/recipes-graphics/directfb/files/directfb-1.2.x-fix-pkgconfig-cflags.patch
b/meta/recipes-graphics/directfb/files/directfb-1.2.x-fix-pkgconfig-cflags.patch
index 274ad50..ee60718 100644
---
a/meta/recipes-graphics/directfb/files/directfb-1.2.x-fix-pkgconfig-cflags.patch
+++
b/meta/recipes-graphics/directfb/files/directfb-1.2.x-fix-pkgconfig-cflags.patch
@@ -1,9 +1,11 @@
+directfb: Get this patch from Openembedded
+
Upstream-Status: Inappropriate [configuration]
+Signed-off-by: Xiaofeng Yan xiaofeng@windriver.com
-Index: DirectFB-1.4.11/directfb-internal.pc.in
-===
DirectFB-1.4.11.orig/directfb-internal.pc.in 2010-10-08
05:43:46.0 -0700
-+++ DirectFB-1.4.11/directfb-internal.pc.in2011-04-06 13:48:23.120923997
-0700
+diff -Nur DirectFB-1.4.15/directfb-internal.pc.in
DirectFB-1.4.15.new//directfb-internal.pc.in
+--- DirectFB-1.4.15/directfb-internal.pc.in2011-09-29 17:51:21.0
+0800
DirectFB-1.4.15.new//directfb-internal.pc.in 2011-11-03
15:14:37.0 +0800
@@ -2,10 +2,10 @@
exec_prefix=@exec_prefix@
moduledir=@MODULEDIR@
@@ -17,31 +19,27 @@ Index: DirectFB-1.4.11/directfb-internal.pc.in
Requires: directfb = @VERSION@
-Cflags: @DFB_INTERNAL_CFLAGS@ -I@INTERNALINCLUDEDIR@
+Cflags: @DFB_INTERNAL_CFLAGS@ -I${includedir}/directfb -I${includedir}
-Index: DirectFB-1.4.11/directfb.pc.in
-===
DirectFB-1.4.11.orig/directfb.pc.in2010-11-15 13:13:59.0
-0800
-+++ DirectFB-1.4.11/directfb.pc.in 2011-04-06 14:09:33.528923998 -0700
-@@ -9,4 +9,5 @@
+diff -Nur DirectFB-1.4.15/directfb.pc.in DirectFB-1.4.15.new//directfb.pc.in
+--- DirectFB-1.4.15/directfb.pc.in 2011-09-29 17:51:21.0 +0800
DirectFB-1.4.15.new//directfb.pc.in2011-11-03 15:15:55.0
+0800
+@@ -9,4 +9,4 @@
Requires: @DEP_VOODOO@ fusion direct
Libs: -L${libdir} -ldirectfb @THREADLIB@ @OSX_LIBS@
- Libs.private: -L${libdir} @MEDIALIB@ @DYNLIB@ @ZLIB_LIBS@
+ Libs.private: -L${libdir} @LIBM@ @DYNLIB@ @ZLIB_LIBS@
-Cflags: @THREADFLAGS@ -I@INCLUDEDIR@
+Cflags: @THREADFLAGS@ -I${includedir}/directfb
-+
-Index: DirectFB-1.4.11/lib/fusion/fusion.pc.in
-===
DirectFB-1.4.11.orig/lib/fusion/fusion.pc.in 2010-10-08
05:43:46.0 -0700
-+++ DirectFB-1.4.11/lib/fusion/fusion.pc.in2011-04-06 13:48:23.120923997
-0700
+diff -Nur DirectFB-1.4.15/lib/fusion/fusion.pc.in
DirectFB-1.4.15.new//lib/fusion/fusion.pc.in
+--- DirectFB-1.4.15/lib/fusion/fusion.pc.in2011-09-29 17:51:21.0
+0800
DirectFB-1.4.15.new//lib/fusion/fusion.pc.in 2011-11-03
15:16:46.0 +0800
@@ -8,4 +8,4 @@
Version: @VERSION@
Requires: direct
Libs: -L${libdir} -lfusion
-Cflags: -I@INCLUDEDIR@
+Cflags: -I${includedir}/directfb -I${includedir}
-Index: DirectFB-1.4.11/lib/voodoo/voodoo.pc.in
-===
DirectFB-1.4.11.orig/lib/voodoo/voodoo.pc.in 2010-10-08
05:43:46.0 -0700
-+++ DirectFB-1.4.11/lib/voodoo/voodoo.pc.in2011-04-06 13:48:23.120923997
[OE-core] [CONSOLIDATED PULL 04/16] libx11-diet: update to 1.4.4
From: Xiaofeng Yan xiaofeng@windriver.com
I remove patch nodolt.patch because it is no use in the new version \
and change patch include_fix.patch to keysymdef_include.patch from
libx11-1.4.4.
Signed-off-by: Xiaofeng Yan xiaofeng@windriver.com
---
.../xorg-lib/libx11-diet-1.3/include_fix.patch | 25
.../xorg-lib/libx11-diet-1.3/nodolt.patch | 14 ---
.../X18NCMSstubs.diff |1 +
.../fix-disable-xlocale.diff |1 +
.../fix-utf8-wrong-define.patch|2 +
.../libx11-diet-1.4.4/keysymdef_include.patch | 23 ++
.../x11_disable_makekeys.patch | 23 ++
.../{libx11-diet_1.3.bb = libx11-diet_1.4.4.bb} | 17 -
8 files changed, 50 insertions(+), 56 deletions(-)
delete mode 100644
meta/recipes-graphics/xorg-lib/libx11-diet-1.3/include_fix.patch
delete mode 100644 meta/recipes-graphics/xorg-lib/libx11-diet-1.3/nodolt.patch
rename meta/recipes-graphics/xorg-lib/{libx11-diet-1.3 =
libx11-diet-1.4.4}/X18NCMSstubs.diff (99%)
rename meta/recipes-graphics/xorg-lib/{libx11-diet-1.3 =
libx11-diet-1.4.4}/fix-disable-xlocale.diff (90%)
rename meta/recipes-graphics/xorg-lib/{libx11-diet-1.3 =
libx11-diet-1.4.4}/fix-utf8-wrong-define.patch (88%)
create mode 100644
meta/recipes-graphics/xorg-lib/libx11-diet-1.4.4/keysymdef_include.patch
rename meta/recipes-graphics/xorg-lib/{libx11-diet-1.3 =
libx11-diet-1.4.4}/x11_disable_makekeys.patch (43%)
rename meta/recipes-graphics/xorg-lib/{libx11-diet_1.3.bb =
libx11-diet_1.4.4.bb} (49%)
diff --git a/meta/recipes-graphics/xorg-lib/libx11-diet-1.3/include_fix.patch
b/meta/recipes-graphics/xorg-lib/libx11-diet-1.3/include_fix.patch
deleted file mode 100644
index b3bcbab..000
--- a/meta/recipes-graphics/xorg-lib/libx11-diet-1.3/include_fix.patch
+++ /dev/null
@@ -1,25 +0,0 @@
-Upstream-Status: Inappropriate [configuration]
-
- configure.ac |6 +++---
- 1 file changed, 3 insertions(+), 3 deletions(-)
-
libX11-1.1.5.orig/configure.ac
-+++ libX11-1.1.5/configure.ac
-@@ -218,13 +218,13 @@ AC_SUBST(XDMCP_LIBS)
- AC_CHECK_FUNC(poll, [AC_DEFINE(USE_POLL, 1, [poll() function is available])],
)
-
- #
- # Find keysymdef.h
- #
--AC_MSG_CHECKING([keysymdef.h])
--dir=`pkg-config --variable=includedir xproto`
--KEYSYMDEF=$dir/X11/keysymdef.h
-+AC_ARG_WITH(keysymdef,
-+ AC_HELP_STRING([--with-keysymdef=DIR/keysymdef.h], [The location of
keysymdef.h]),
-+ KEYSYMDEF=$withval, KEYSYMDEF=)
- if test -f $KEYSYMDEF; then
- AC_MSG_RESULT([$KEYSYMDEF])
- else
- AC_MSG_ERROR([Cannot find keysymdef.h])
- fi
diff --git a/meta/recipes-graphics/xorg-lib/libx11-diet-1.3/nodolt.patch
b/meta/recipes-graphics/xorg-lib/libx11-diet-1.3/nodolt.patch
deleted file mode 100644
index cc05fdc..000
--- a/meta/recipes-graphics/xorg-lib/libx11-diet-1.3/nodolt.patch
+++ /dev/null
@@ -1,14 +0,0 @@
-Upstream-Status: Inappropriate [configuration]
-
-Index: libX11-1.2.1/configure.ac
-===
libX11-1.2.1.orig/configure.ac 2009-07-02 14:07:54.0 +0100
-+++ libX11-1.2.1/configure.ac 2009-07-02 14:08:01.0 +0100
-@@ -20,7 +20,6 @@
-
- # Checks for programs.
- AC_PROG_LIBTOOL
--DOLT
- AC_PROG_CC
- XORG_CWARNFLAGS
-
diff --git a/meta/recipes-graphics/xorg-lib/libx11-diet-1.3/X18NCMSstubs.diff
b/meta/recipes-graphics/xorg-lib/libx11-diet-1.4.4/X18NCMSstubs.diff
similarity index 99%
rename from meta/recipes-graphics/xorg-lib/libx11-diet-1.3/X18NCMSstubs.diff
rename to meta/recipes-graphics/xorg-lib/libx11-diet-1.4.4/X18NCMSstubs.diff
index 91ab180..be71d44 100644
--- a/meta/recipes-graphics/xorg-lib/libx11-diet-1.3/X18NCMSstubs.diff
+++ b/meta/recipes-graphics/xorg-lib/libx11-diet-1.4.4/X18NCMSstubs.diff
@@ -1,5 +1,6 @@
Upstream-Status: Pending
+Upstream-Status: Inappropriate [configuration]
Index: libX11-1.3/src/imConv.c
===
--- libX11-1.3.orig/src/imConv.c
diff --git
a/meta/recipes-graphics/xorg-lib/libx11-diet-1.3/fix-disable-xlocale.diff
b/meta/recipes-graphics/xorg-lib/libx11-diet-1.4.4/fix-disable-xlocale.diff
similarity index 90%
rename from
meta/recipes-graphics/xorg-lib/libx11-diet-1.3/fix-disable-xlocale.diff
rename to
meta/recipes-graphics/xorg-lib/libx11-diet-1.4.4/fix-disable-xlocale.diff
index 7dcdd6a..a7c3984 100644
--- a/meta/recipes-graphics/xorg-lib/libx11-diet-1.3/fix-disable-xlocale.diff
+++ b/meta/recipes-graphics/xorg-lib/libx11-diet-1.4.4/fix-disable-xlocale.diff
@@ -1,5 +1,6 @@
Upstream-Status: Pending
+Signed-off-by: Xiaofeng Yan xiaofeng@windriver.com
--- libX11-X11R7.0-1.0.0/src/Font.c.orig 2006-03-12 18:35:42.0
+0100
+++ libX11-X11R7.0-1.0.0/src/Font.c2006-03-12 18:40:27.0 +0100
@@ -701,7 +701,11 @@
diff --git
[OE-core] [CONSOLIDATED PULL 07/16] libgpg-error: add BBCLASSEXTEND native for libgcrypts and gnutls-native
Signed-off-by: Saul Wold s...@linux.intel.com
---
.../libgpg-error/libgpg-error_1.10.bb |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-support/libgpg-error/libgpg-error_1.10.bb
b/meta/recipes-support/libgpg-error/libgpg-error_1.10.bb
index 0c10b47..95f9e56 100644
--- a/meta/recipes-support/libgpg-error/libgpg-error_1.10.bb
+++ b/meta/recipes-support/libgpg-error/libgpg-error_1.10.bb
@@ -28,3 +28,5 @@ do_install_append() {
# we don't have common lisp in OE
rm -rf ${D}${datadir}/common-lisp/
}
+
+BBCLASSEXTEND = native
--
1.7.6.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED PULL 08/16] file: update to 5.09
Signed-off-by: Saul Wold s...@linux.intel.com
---
.../file/file/fix_version_check.patch | 21
.../file/{file_5.04.bb = file_5.09.bb}|9 +++
2 files changed, 25 insertions(+), 5 deletions(-)
create mode 100644 meta/recipes-devtools/file/file/fix_version_check.patch
rename meta/recipes-devtools/file/{file_5.04.bb = file_5.09.bb} (79%)
diff --git a/meta/recipes-devtools/file/file/fix_version_check.patch
b/meta/recipes-devtools/file/file/fix_version_check.patch
new file mode 100644
index 000..bd24ccb
--- /dev/null
+++ b/meta/recipes-devtools/file/file/fix_version_check.patch
@@ -0,0 +1,21 @@
+Since we are cross-compiling and need to have a cover script this
+version check sees file.real-5.09 not file-5.09, so fix the
+sed.
+
+Upstream-Status: Inapproriate [build-specific]
+
+Signed-off-by: Saul Wold s...@linux.intel.com
+
+Index: file-5.09/magic/Makefile.am
+===
+--- file-5.09.orig/magic/Makefile.am
file-5.09/magic/Makefile.am
+@@ -260,7 +260,7 @@ ${MAGIC}: $(EXTRA_DIST) $(FILE_COMPILE_D
+ @(if expr ${FILE_COMPILE} : '.*/.*' /dev/null; then \
+ echo Using ${FILE_COMPILE} to generate ${MAGIC} /dev/null; \
+ else \
+- v=$$(file --version | sed -e s/file-// -e q); \
++ v=$$(file --version | sed -e s/file.real-// -e q); \
+ if [ $$v != ${PACKAGE_VERSION} ]; then \
+ echo Cannot use the installed version of file ($$v) to; \
+ echo cross-compile file ${PACKAGE_VERSION}; \
diff --git a/meta/recipes-devtools/file/file_5.04.bb
b/meta/recipes-devtools/file/file_5.09.bb
similarity index 79%
rename from meta/recipes-devtools/file/file_5.04.bb
rename to meta/recipes-devtools/file/file_5.09.bb
index 1f9c78e..9b2f3a4 100644
--- a/meta/recipes-devtools/file/file_5.04.bb
+++ b/meta/recipes-devtools/file/file_5.09.bb
@@ -10,16 +10,15 @@ LIC_FILES_CHKSUM =
file://COPYING;beginline=2;md5=6a7382872edb68d33e1a9398b6e03
DEPENDS = zlib file-native
DEPENDS_virtclass-native = zlib-native
-PR = r2
+PR = r0
SRC_URI = ftp://ftp.astron.com/pub/file/file-${PV}.tar.gz \
- file://stringb-compat.patch \
- file://ge-le.patch \
+ file://fix_version_check.patch \
file://dump \
file://filesystems
-SRC_URI[md5sum] = accade81ff1cc774904b47c72c8aeea0
-SRC_URI[sha256sum] =
4c9e6e7994e74cb3386374ae91b055d26ac96b9d3e82fd157ae2d62e87a4260c
+SRC_URI[md5sum] = 6fd7cd6c4281e68fe9ec6644ce0fac6f
+SRC_URI[sha256sum] =
bde1c9830ee6c234871778faae8277fdcf775fbb16dea63c8251e24b7c2f869c
inherit autotools
--
1.7.6.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED PULL 09/16] gnu-config: update to git HEAD
Licence has update timestamp and Copyright year.
This change needs a coresponding change to ASSUME_PROVIDED
to add git-native
Signed-off-by: Saul Wold s...@linux.intel.com
---
.../gnu-config/config-guess-uclibc.patch | 145 +---
.../{gnu-config_20080123.bb = gnu-config_git.bb} | 15 +-
2 files changed, 75 insertions(+), 85 deletions(-)
rename meta/recipes-devtools/gnu-config/{gnu-config_20080123.bb =
gnu-config_git.bb} (73%)
diff --git
a/meta/recipes-devtools/gnu-config/gnu-config/config-guess-uclibc.patch
b/meta/recipes-devtools/gnu-config/gnu-config/config-guess-uclibc.patch
index f862c83..dc15d91 100644
--- a/meta/recipes-devtools/gnu-config/gnu-config/config-guess-uclibc.patch
+++ b/meta/recipes-devtools/gnu-config/gnu-config/config-guess-uclibc.patch
@@ -4,12 +4,14 @@ Patch courtesy
gentoo-portage/sys-devel/gnuconfig/files/automake-1.8.5-config-gu
updated to 20050516 by Marcin 'Hrw' Juszkiewicz (by hand)
updated to 20080123 by Nitin A Kamble (by hand)
+updated to 20111001 by Saul Wold (by hand)
+Signed-off-by: Saul Wold s...@linux.intel.com
-Index: config/config.guess
+Index: git/config.guess
===
config.orig/config.guess
-+++ config/config.guess
-@@ -139,6 +139,19 @@ UNAME_RELEASE=`(uname -r) 2/dev/null` |
+--- git.orig/config.guess 2011-10-20 15:15:25.0 -0700
git/config.guess 2011-10-20 16:56:43.810830229 -0700
+@@ -140,6 +140,19 @@
UNAME_SYSTEM=`(uname -s) 2/dev/null` || UNAME_SYSTEM=unknown
UNAME_VERSION=`(uname -v) 2/dev/null` || UNAME_VERSION=unknown
@@ -29,14 +31,26 @@ Index: config/config.guess
# Note: order is significant - the case branches are not exclusive.
case ${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION} in
-@@ -840,13 +853,13 @@ EOF
+@@ -871,15 +884,15 @@
+ EV68*) UNAME_MACHINE=alphaev68 ;;
+ esac
+ objdump --private-headers /bin/sh | grep -q ld.so.1
+- if test $? = 0 ; then LIBC=libc1 ; else LIBC= ; fi
+- echo ${UNAME_MACHINE}-unknown-linux-gnu${LIBC}
++ if test $? = 0 ; then LIBC=gnulibc1 ; else LIBC= ; fi
++ echo ${UNAME_MACHINE}-unknown-linux-${LIBC}
+ exit ;;
+ arm*:Linux:*:*)
+ eval $set_cc_for_build
if echo __ARM_EABI__ | $CC_FOR_BUILD -E - 2/dev/null \
| grep -q __ARM_EABI__
then
- echo ${UNAME_MACHINE}-unknown-linux-gnu
+ echo ${UNAME_MACHINE}-unknown-linux-${LIBC}
else
- echo ${UNAME_MACHINE}-unknown-linux-gnueabi
+ if echo __ARM_PCS_VFP | $CC_FOR_BUILD -E - 2/dev/null \
+ | grep -q __ARM_PCS_VFP
+@@ -891,19 +904,19 @@
fi
exit ;;
avr32*:Linux:*:*)
@@ -44,13 +58,25 @@ Index: config/config.guess
+ echo ${UNAME_MACHINE}-unknown-linux-${LIBC}
exit ;;
cris:Linux:*:*)
- echo cris-axis-linux-gnu
-@@ -855,16 +868,16 @@ EOF
- echo crisv32-axis-linux-gnu
+- echo cris-axis-linux-gnu
++ echo cris-axis-linux-${LIBC}
+ exit ;;
+ crisv32:Linux:*:*)
+- echo crisv32-axis-linux-gnu
++ echo crisv32-axis-linux-${LIBC}
exit ;;
frv:Linux:*:*)
-- echo frv-unknown-linux-gnu
-+ echo frv-unknown-linux-${LIBC}
+- echo frv-unknown-linux-gnu
++ echo frv-unknown-linux-${LIBC}
+ exit ;;
+ hexagon:Linux:*:*)
+- echo hexagon-unknown-linux-gnu
++ echo hexagon-unknown-linux-${LIBC}
+ exit ;;
+ i*86:Linux:*:*)
+ LIBC=gnu
+@@ -917,13 +930,13 @@
+ echo ${UNAME_MACHINE}-pc-linux-${LIBC}
exit ;;
ia64:Linux:*:*)
- echo ${UNAME_MACHINE}-unknown-linux-gnu
@@ -64,21 +90,12 @@ Index: config/config.guess
- echo ${UNAME_MACHINE}-unknown-linux-gnu
+ echo ${UNAME_MACHINE}-unknown-linux-${LIBC}
exit ;;
- mips:Linux:*:*)
+ mips:Linux:*:* | mips64:Linux:*:*)
eval $set_cc_for_build
-@@ -887,7 +900,7 @@ EOF
- s: ::g
- p
- }'`
-- test x${CPU} != x { echo ${CPU}-unknown-linux-gnu; exit; }
-+ test x${CPU} != x { echo ${CPU}-unknown-linux-${LIBC}; exit; }
- ;;
- mips64:Linux:*:*)
- eval $set_cc_for_build
-@@ -910,16 +923,16 @@ EOF
- s: ::g
- p
- }'`
+@@ -942,54 +955,54 @@
+ #endif
+ EOF
+ eval `$CC_FOR_BUILD -E $dummy.c 2/dev/null | grep '^CPU'`
- test x${CPU} != x { echo ${CPU}-unknown-linux-gnu; exit; }
+ test x${CPU} != x { echo ${CPU}-unknown-linux-${LIBC}; exit; }
;;
@@ -86,24 +103,13 @@ Index: config/config.guess
- echo or32-unknown-linux-gnu
+ echo or32-unknown-linux-${LIBC}
exit ;;
- ppc:Linux:*:*)
-- echo powerpc-unknown-linux-gnu
-+ echo powerpc-unknown-linux-${LIBC}
- exit ;;
- ppc64:Linux:*:*)
-- echo powerpc64-unknown-linux-gnu
-+ echo powerpc64-unknown-linux-${LIBC}
+ padre:Linux:*:*)
+- echo
[OE-core] [CONSOLIDATED PULL 11/16] bitbake.conf: Update ASSUME_PROVIDED
* Remove an obsolete comment about mercurial
* Remove cvs-native since we have removed cvs SRC_URIs
* Remove svn-native since it's subversion and we can build native correctly
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/conf/bitbake.conf |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 0d6b3b8..a0d7cea 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -146,18 +146,13 @@ DATETIME = ${DATE}${TIME}
# python-native should be here but python relies on building
# its own in staging
-# mercurial-native is required to pull mercurial repositories (hg://...)
-# we don't have it yet in the recipies so let's assume it's provided by
-# the underlying OS
ASSUME_PROVIDED = \
bzip2-native \
-cvs-native \
grep-native \
diffstat-native \
patch-native \
perl-native-runtime \
python-native-runtime \
-svn-native \
tar-native \
texinfo-native \
virtual/libintl-native \
--
1.7.6.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED PULL 13/16] gcc-4.6: fix toolchain build for SH4
From: Michael Brown michael_e_br...@dell.com Signed-off-by: Michael Brown michael_e_br...@dell.com Port patch from base openembedded. Since 4.6 already has fixes for config.gcc, the fix only requires a one line change to gcc-cross4.inc. The patch was imported from the OpenEmbedded git server (git://git.openembedded.org/openembedded) as of commit id 3aa8afe97e9cf1340feb9c4442a6ed88b7e32c96. gcc-4.5: Fix toolchain builds for SH4/SH3 Signed-off-by: Khem Raj raj.k...@gmail.com --- meta/recipes-devtools/gcc/gcc-cross4.inc |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/meta/recipes-devtools/gcc/gcc-cross4.inc b/meta/recipes-devtools/gcc/gcc-cross4.inc index ea20a24..4a20818 100644 --- a/meta/recipes-devtools/gcc/gcc-cross4.inc +++ b/meta/recipes-devtools/gcc/gcc-cross4.inc @@ -1 +1,3 @@ require gcc-cross.inc + +EXTRA_OECONF_append_sh4 = --with-multilib-list= --enable-incomplete-targets -- 1.7.6.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED PULL 14/16] screenshot: rename to sato-screenshot
From: Dmitry Eremin-Solenikov dbarysh...@gmail.com
To remove a name conflict with e17's screenshot tool (and possibly other
screenshot tools, as screenshot is a generic term), rename screenshot
to sato-screenshot.
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
.../files/fix_ldadd_order.patch|0
.../sato-screenshot_git.bb}|2 +-
meta/recipes-sato/tasks/task-core-x11.bb |2 +-
3 files changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-sato/{screenshot =
sato-screenshot}/files/fix_ldadd_order.patch (100%)
rename meta/recipes-sato/{screenshot/screenshot_git.bb =
sato-screenshot/sato-screenshot_git.bb} (92%)
diff --git a/meta/recipes-sato/screenshot/files/fix_ldadd_order.patch
b/meta/recipes-sato/sato-screenshot/files/fix_ldadd_order.patch
similarity index 100%
rename from meta/recipes-sato/screenshot/files/fix_ldadd_order.patch
rename to meta/recipes-sato/sato-screenshot/files/fix_ldadd_order.patch
diff --git a/meta/recipes-sato/screenshot/screenshot_git.bb
b/meta/recipes-sato/sato-screenshot/sato-screenshot_git.bb
similarity index 92%
rename from meta/recipes-sato/screenshot/screenshot_git.bb
rename to meta/recipes-sato/sato-screenshot/sato-screenshot_git.bb
index 917a27d..5e51d3d 100644
--- a/meta/recipes-sato/screenshot/screenshot_git.bb
+++ b/meta/recipes-sato/sato-screenshot/sato-screenshot_git.bb
@@ -12,7 +12,7 @@ SRCREV = c792e4edc758bab21e0b01814979eacf0b1af945
PV = 0.1+git${SRCPV}
PR = r0
-SRC_URI = git://git.yoctoproject.org/${BPN};protocol=git \
+SRC_URI = git://git.yoctoproject.org/screenshot;protocol=git \
file://fix_ldadd_order.patch
S = ${WORKDIR}/git
diff --git a/meta/recipes-sato/tasks/task-core-x11.bb
b/meta/recipes-sato/tasks/task-core-x11.bb
index 106bc0f..f1b06f9 100644
--- a/meta/recipes-sato/tasks/task-core-x11.bb
+++ b/meta/recipes-sato/tasks/task-core-x11.bb
@@ -61,7 +61,7 @@ RDEPENDS_task-core-apps-x11-core = \
leafpad \
${FILEMANAGER} \
matchbox-terminal \
-screenshot
+sato-screenshot
RDEPENDS_task-core-apps-x11-games = \
--
1.7.6.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED PULL 12/16] boost: Update to 1.47.0 Cleanup
Removed boost-jam-native since it was an older version
no incompatible with boost 1.47.
Modified boost to use BBCLASSEXTEND native for the bjam
native binary.
Removed older unused patches.
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/recipes-support/boost/boost-jam-native.inc| 32 ---
.../boost/boost-jam-native_3.1.18.bb |8 -
.../boost/{boost-36.inc = boost.inc} | 42 +++-
.../boost/{boost_1.44.0.bb = boost_1.47.0.bb} | 13 +-
.../recipes-support/boost/files/1.34.1-gcc43.patch | 226 -
.../boost/files/atomic_count_gcc_atomicity.patch | 15 --
meta/recipes-support/boost/files/gcc41.patch | 16 --
meta/recipes-support/boost/files/gcc43.patch | 258
.../recipes-support/boost/files/linux-uclibc.patch | 12 -
.../boost/files/unit_test_log10f.patch | 22 --
10 files changed, 43 insertions(+), 601 deletions(-)
delete mode 100644 meta/recipes-support/boost/boost-jam-native.inc
delete mode 100644 meta/recipes-support/boost/boost-jam-native_3.1.18.bb
rename meta/recipes-support/boost/{boost-36.inc = boost.inc} (88%)
rename meta/recipes-support/boost/{boost_1.44.0.bb = boost_1.47.0.bb} (66%)
delete mode 100644 meta/recipes-support/boost/files/1.34.1-gcc43.patch
delete mode 100644
meta/recipes-support/boost/files/atomic_count_gcc_atomicity.patch
delete mode 100644 meta/recipes-support/boost/files/gcc41.patch
delete mode 100644 meta/recipes-support/boost/files/gcc43.patch
delete mode 100644 meta/recipes-support/boost/files/linux-uclibc.patch
delete mode 100644 meta/recipes-support/boost/files/unit_test_log10f.patch
diff --git a/meta/recipes-support/boost/boost-jam-native.inc
b/meta/recipes-support/boost/boost-jam-native.inc
deleted file mode 100644
index c5a9d99..000
--- a/meta/recipes-support/boost/boost-jam-native.inc
+++ /dev/null
@@ -1,32 +0,0 @@
-# The Boost web site provides free peer-reviewed portable
-# C++ source libraries. The emphasis is on libraries which
-# work well with the C++ Standard Library. The libraries are
-# intended to be widely useful, and are in regular use by
-# thousands of programmers across a broad spectrum of applications.
-DESCRIPTION = Make system for boost (native)
-HOMEPAGE = http://www.boost.org/;
-SECTION = devel
-LICENSE = Boost
-INC_PR = r1
-
-LIC_FILES_CHKSUM =
file://LICENSE_1_0.txt;md5=e4224ccaecb14d942c71d31bef20d78c
-
-SRC_URI = ${SOURCEFORGE_MIRROR}/boost/boost-jam-${PV}.tgz
-S = ${WORKDIR}/boost-jam-${PV}
-
-inherit native
-
-do_compile() {
- set -ex
- rm -rf bin.*
- ./build.sh gcc
-}
-
-# This is too terrible - the build script doesn't give any good
-# way I can see to find out where the binaries are placed, so
-# rely on only one bin.foo directory being created.
-do_install () {
- set -ex
- install -d ${D}${bindir}/
- install -c -m 755 bin.*/bjam ${D}${bindir}/
-}
diff --git a/meta/recipes-support/boost/boost-jam-native_3.1.18.bb
b/meta/recipes-support/boost/boost-jam-native_3.1.18.bb
deleted file mode 100644
index 7a0b1a8..000
--- a/meta/recipes-support/boost/boost-jam-native_3.1.18.bb
+++ /dev/null
@@ -1,8 +0,0 @@
-include boost-jam-native.inc
-
-PR = ${INC_PR}.0
-
-SRC_URI = ${SOURCEFORGE_MIRROR}/boost/boost-jam-${PV}.tgz
-
-SRC_URI[md5sum] = f790e022d658db38db5cc4aeeccad3f1
-SRC_URI[sha256sum] =
85dbb72c29837ba89cb5408782c82459b34fdecaedea8b54ce1cb3cb9990121a
diff --git a/meta/recipes-support/boost/boost-36.inc
b/meta/recipes-support/boost/boost.inc
similarity index 88%
rename from meta/recipes-support/boost/boost-36.inc
rename to meta/recipes-support/boost/boost.inc
index 8b0622f..ddb65b7 100644
--- a/meta/recipes-support/boost/boost-36.inc
+++ b/meta/recipes-support/boost/boost.inc
@@ -6,15 +6,22 @@
DESCRIPTION = Free peer-reviewed portable C++ source libraries
HOMEPAGE = http://www.boost.org/;
SECTION = libs
-DEPENDS = boost-jam-native zlib
+DEPENDS = boost-native zlib
+DEPENDS_virtclass-native =
LICENSE = Boost
-PR = r4
ARM_INSTRUCTION_SET = arm
+
BOOST_VER = ${@_.join(d.getVar(PV,1).split(.))}
BOOST_MAJ = ${@_.join(d.getVar(PV,1).split(.)[0:2])}
BOOST_P = boost_${BOOST_VER}
+INC_PR = r0
+
+SRC_URI = ${SOURCEFORGE_MIRROR}/${BPN}/${BOOST_P}.tar.bz2
+
+S = ${WORKDIR}/${BOOST_P}
+
BOOST_LIBS = \
date_time \
filesystem \
@@ -37,8 +44,6 @@ BOOST_LIBS = \
#PYTHON_ROOT = ${STAGING_DIR_HOST}/${prefix}
#PYTHON_VERSION = 2.5
-S = ${WORKDIR}/${BOOST_P}
-
# Make a package for each library, plus -dev
PACKAGES = ${PN}-dbg ${BOOST_PACKAGES}
python __anonymous () {
@@ -148,3 +153,32 @@ do_install() {
--includedir=${D}${includedir} \
install
}
+
+BBCLASSEXTEND = native
+
+do_configure_virtclass-native() {
+ :
+}
+
+do_boostconfig_virtclass-native() {
+ :
+}
+
+do_compile_virtclass-native() {
+ set -ex
+ cd ${S}/tools/build/v2/engine
+ rm -rf bin.*
+ ./build.sh gcc
+}
+
+# This is too
[OE-core] [CONSOLIDATED PULL 10/16] gnu-config: Create 2011111 release
Use a yoctoproject.org based tarball since gnu-config is required very
early on in the native build process, we do not want to rely on git, which
can cause a circular dependency issue.
Signed-off-by: Saul Wold s...@linux.intel.com
---
.../gnu-config/gnu-config_2011.bb | 41
1 files changed, 41 insertions(+), 0 deletions(-)
create mode 100644 meta/recipes-devtools/gnu-config/gnu-config_2011.bb
diff --git a/meta/recipes-devtools/gnu-config/gnu-config_2011.bb
b/meta/recipes-devtools/gnu-config/gnu-config_2011.bb
new file mode 100644
index 000..27400c6
--- /dev/null
+++ b/meta/recipes-devtools/gnu-config/gnu-config_2011.bb
@@ -0,0 +1,41 @@
+SUMMARY = gnu-configize
+DESCRIPTION = Tool that installs the GNU config.guess / config.sub into a
directory tree
+SECTION = devel
+LICENSE = GPLv2
+LIC_FILES_CHKSUM =
file://config.guess;endline=39;md5=a3669d051b3a8408d69751e53b2e1cc1
+
+DEPENDS_virtclass-native = perl-native-runtime
+
+INHIBIT_DEFAULT_DEPS = 1
+
+PR = r0
+
+SRC_URI =
http://downloads.yoctoproject.org/releases/gnu-config/gnu-config-yocto-${PV}.tgz
\
+ file://config-guess-uclibc.patch \
+ file://gnu-configize.in
+
+SRC_URI[md5sum] = 30be385c919a25cd9522205ef49e5328
+SRC_URI[sha256sum] =
0750afa8d8ee988b6ead1c2d02b565597f809e2e3ad14886ed7803d3bbc8b0cd
+
+do_compile() {
+ :
+}
+
+do_install () {
+ install -d ${D}${datadir}/gnu-config \
+ ${D}${bindir}
+ cat ${WORKDIR}/gnu-configize.in | \
+ sed -e 's,@gnu-configdir@,${datadir}/gnu-config,g' \
+ -e 's,@autom4te_perllibdir@,${datadir}/autoconf,g'
${D}${bindir}/gnu-configize
+ # In the native case we want the system perl as perl-native can't have
built yet
+ if [ ${BUILD_ARCH} != ${TARGET_ARCH} ]; then
+ sed -i -e 's,/usr/bin/env,${bindir}/env,g'
${D}${bindir}/gnu-configize
+ fi
+ chmod 755 ${D}${bindir}/gnu-configize
+ install -m 0644 config.guess config.sub ${D}${datadir}/gnu-config/
+}
+
+PACKAGES = ${PN}
+FILES_${PN} = ${bindir} ${datadir}/gnu-config
+
+BBCLASSEXTEND = native
--
1.7.6.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED PULL 16/16] distro_tracking: Refect Recipe Updates Status
* libnl- NO_UPDATE_REASON due to incompatibility * zlib - has wrong version in update list (121) * libtasn1 - Update to 2.10 * pkgconfig - NO_UPDATE_REASON due to removal of glib-conf * file - update to 5.09 * dchp - New version is 4.2.3, not updated yet. * tiff - NO_UPDATE_REASON wait until 4.0.0 * gobject-interopsectio - NO_UPDATE_REASON can not cross-build * gnu-config - Udpate to git HEAD - requires ASSUME_PROVIDED += git-native * boost- remove boost-jam-native since it's part of 1.47.0 Update Signed-off-by: Saul Wold s...@linux.intel.com --- .../conf/distro/include/distro_tracking_fields.inc | 50 ++-- 1 files changed, 25 insertions(+), 25 deletions(-) diff --git a/meta/conf/distro/include/distro_tracking_fields.inc b/meta/conf/distro/include/distro_tracking_fields.inc index 5cd4c37..e15ab20 100644 --- a/meta/conf/distro/include/distro_tracking_fields.inc +++ b/meta/conf/distro/include/distro_tracking_fields.inc @@ -382,6 +382,7 @@ RECIPE_MAINTAINER_pn-libnl = Saul Wold s...@linux.intel.com RECIPE_LATEST_VERSION_pn-libnl = 2.0 RECIPE_INTEL_SECTION_pn-libnl = base libs RECIPE_LATEST_RELEASE_DATE_pn-libnl = Oct 01, 2010 +RECIPE_NO_UPDATE_REASON_pn-libnl = libnl-3.2.2 is incompatible with libnl2, so no Upgrade RECIPE_STATUS_pn-zlib = yellow # local config scripts RECIPE_LAST_UPDATE_pn-zlib = Jun 11, 2010 @@ -394,6 +395,7 @@ RECIPE_INTEL_SECTION_pn-zlib = base libs RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-zlib = 3 months RECIPE_LATEST_RELEASE_DATE_pn-zlib = Mar 01, 2010 RECIPE_COMMENTS_pn-zlib = rconflicts: libxml2 ( 2.7.7) (rbreaks) +RECIPE_NO_UPDATE_REASON_pn-zlib = zlib-1.2.5 is latest, version parser reports 121 in error RECIPE_STATUS_pn-libxml2 = yellow RECIPE_LAST_UPDATE_pn-libxml2 = Jun 18, 2010 @@ -452,15 +454,15 @@ RECIPE_INTEL_SECTION_pn-lzo = base libs RECIPE_LATEST_RELEASE_DATE_pn-lzo = Oct 01, 2010 RECIPE_STATUS_pn-libtasn1 = green -RECIPE_LAST_UPDATE_pn-libtasn1 = Dec 06, 2010 +RECIPE_LATEST_VERSION_pn-libtasn1 = 2.10 +RECIPE_LATEST_RELEASE_DATE_pn-libtasn1 = Oct 25, 2011 +RECIPE_LAST_UPDATE_pn-libtasn1 = Nov 08, 2011 RECIPE_MAINTAINER_pn-libtasn1 = Saul Wold s...@linux.intel.com RECIPE_DEPENDENCY_CHECK_pn-libtasn1 = not done -RECIPE_LATEST_VERSION_pn-libtasn1 = 2.9 RECIPE_INTEL_SECTION_pn-libtasn1 = base libs RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-libtasn1 = 1 month -RECIPE_LATEST_RELEASE_DATE_pn-libtasn1 = Dec 06, 2010 RECIPE_COMMENTS_pn-libtasn1 = -RECIPE_MANUAL_CHECK_DATE_pn-libtasn1 = Sep 27, 2011 +RECIPE_MANUAL_CHECK_DATE_pn-libtasn1 = Nov 08, 2011 RECIPE_STATUS_pn-openssl = green RECIPE_LAST_UPDATE_pn-openssl = Nov 17, 2010 @@ -1318,17 +1320,10 @@ RECIPE_MAINTAINER_pn-psmisc = Yu Ke ke...@intel.com RECIPE_STATUS_pn-boost = yellow RECIPE_LATEST_VERSION_pn-boost = 1.47.0 RECIPE_LATEST_RELEASE_DATE_pn-boost = Jul 12, 2011 -RECIPE_LAST_UPDATE_pn-boost = Aug 19, 2010 +RECIPE_LAST_UPDATE_pn-boost = Nov 11, 2010 RECIPE_MANUAL_CHECK_DATE_pn-boost = Nov 08, 2011 RECIPE_MAINTAINER_pn-boost = Saul Wold s...@linux.intel.com -RECIPE_STATUS_pn-boost-jam-native = green -RECIPE_LATEST_VERSION_pn-boost-jam-native = 3.1.18 -RECIPE_LATEST_RELEASE_DATE_pn-boost-jam-native = Mar 22, 2011 -RECIPE_LAST_UPDATE_pn-boost-jam-native = Aug 19, 2010 -RECIPE_MANUAL_CHECK_DATE_pn-boost-jam-native = Nov 08, 2011 -RECIPE_MAINTAINER_pn-boost-jam-native = Saul Wold s...@linux.intel.com - RECIPE_STATUS_pn-libfribidi = red DISTRO_PN_ALIAS_pn-libfribidi = OpenSuSE=fribidi Ubuntu=fribidi Mandriva=fribidi Debian=fribidi RECIPE_LATEST_VERSION_pn-libfribidi = 0.19.2 @@ -1504,14 +1499,15 @@ RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-elfutils=1 month RECIPE_LATEST_RELEASE_DATE_pn-elfutils=Jun 01, 2010 RECIPE_STATUS_pn-pkgconfig = green +RECIPE_LATEST_VERSION_pn-pkgconfig = 0.26 +RECIPE_LATEST_RELEASE_DATE_pn-pkgconfig = May 15, 2011 RECIPE_LAST_UPDATE_pn-pkgconfig = Jul 13, 2010 RECIPE_MAINTAINER_pn-pkgconfig = Saul Wold s...@linux.intel.com RECIPE_DEPENDENCY_CHECK_pn-pkgconfig = not done -RECIPE_LATEST_VERSION_pn-pkgconfig = 0.25 RECIPE_INTEL_SECTION_pn-pkgconfig = base utils -RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-pkgconfig = n/a -RECIPE_LATEST_RELEASE_DATE_pn-pkgconfig = May 01, 2010 -RECIPE_COMMENTS_pn-pkgconfig = git as candidate, 0.23: Jan 01, 2008, 0.24: 05/2010, 0.25: 05/2010 +RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-pkgconfig = 1 year +RECIPE_COMMENTS_pn-pkgconfig = +RECIPE_NO_UPDATE_REASON_pn-pkgconfig = 0.26 removes glib-conf, adds circular depends RECIPE_STATUS_pn-less = green RECIPE_LAST_UPDATE_pn-less = May 24, 2011 @@ -1548,17 +1544,17 @@ RECIPE_LATEST_RELEASE_DATE_pn-findutils = Jun 01, 2009 RECIPE_COMMENTS_pn-findutils = RECIPE_STATUS_pn-file = green +RECIPE_LATEST_VERSION_pn-file = 5.09 +RECIPE_LATEST_RELEASE_DATE_pn-file = Sep 16, 2011 RECIPE_LAST_UPDATE_pn-file = Jul 12, 2011 RECIPE_MAINTAINER_pn-file = Saul Wold s...@linux.intel.com RECIPE_DEPENDENCY_CHECK_pn-file = done
[OE-core] [CONSOLIDATED PULL 15/16] gobject-introspection: update frome meta-oe
From: Dmitry Eremin-Solenikov dbarysh...@gmail.com
OE-Core uses very old version of gobject-introspection. The recipe says
0.10.8, but in reality it's GOBJECT_INTROSPECTION_0_6_3-41-gefa7266.
That version e.g. doesn't compile with python 2.7 (default in some
versions), etc.
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
.../gnome/gobject-introspection/configure.patch| 27
.../gnome/gobject-introspection/pathfix.patch | 27
.../use-usr-bin-env-for-python.patch | 20
.../gnome/gobject-introspection_git.bb | 32 +++
4 files changed, 38 insertions(+), 68 deletions(-)
delete mode 100644
meta/recipes-gnome/gnome/gobject-introspection/configure.patch
delete mode 100644 meta/recipes-gnome/gnome/gobject-introspection/pathfix.patch
create mode 100644
meta/recipes-gnome/gnome/gobject-introspection/use-usr-bin-env-for-python.patch
diff --git a/meta/recipes-gnome/gnome/gobject-introspection/configure.patch
b/meta/recipes-gnome/gnome/gobject-introspection/configure.patch
deleted file mode 100644
index 5dcd9b0..000
--- a/meta/recipes-gnome/gnome/gobject-introspection/configure.patch
+++ /dev/null
@@ -1,27 +0,0 @@
-Upstream-Status: Inappropriate [configuration]
-
-Index: git/common.mk
-===
git.orig/common.mk 2009-08-19 11:11:26.0 +0100
-+++ git/common.mk 2009-08-19 11:12:05.0 +0100
-@@ -4,7 +4,7 @@
- UNINSTALLED_INTROSPECTION_SRCDIR=$(top_srcdir) \
- UNINSTALLED_INTROSPECTION_BUILDDIR=$(top_builddir)
- SCANNER_ARGS = -v --add-include-path=$(top_builddir)/gir --add-include-path=.
--SCANNER = $(AM_V_GEN) env LPATH=.libs $(CHECK_DEBUG) $(SCANNER_ENV)
$(SCANNER_BIN) $(SCANNER_ARGS)
-+SCANNER = $(AM_V_GEN) env LPATH=.libs $(CHECK_DEBUG) $(SCANNER_ENV)
g-ir-scanner $(SCANNER_ARGS)
- SCANNER_LIBS = \
- $(top_srcdir)/giscanner/*.py \
- $(top_builddir)/giscanner/libgiscanner.la \
-Index: git/configure.ac
-===
git.orig/configure.ac 2009-08-19 11:11:26.0 +0100
-+++ git/configure.ac 2009-08-19 11:11:28.0 +0100
-@@ -201,7 +201,6 @@
- pyexecdir=`echo $pyexecdir | tr '' '/'`
- ;;
- esac
--AM_CHECK_PYTHON_HEADERS(,AC_MSG_ERROR([Python headers not found]))
-
- AC_CONFIG_FILES([
- Makefile
diff --git a/meta/recipes-gnome/gnome/gobject-introspection/pathfix.patch
b/meta/recipes-gnome/gnome/gobject-introspection/pathfix.patch
deleted file mode 100644
index a96e4b1..000
--- a/meta/recipes-gnome/gnome/gobject-introspection/pathfix.patch
+++ /dev/null
@@ -1,27 +0,0 @@
-Upstream-Status: Pending
-
-Index: git/giscanner/dumper.py
-===
git.orig/giscanner/dumper.py 2010-11-29 15:14:35.0 -0800
-+++ git/giscanner/dumper.py2010-11-29 15:14:57.115747154 -0800
-@@ -82,7 +82,7 @@
- self._tmpdir = tempfile.mkdtemp('', 'tmp-introspect', dir=os.getcwd())
-
- self._compiler_cmd = os.environ.get('CC', 'gcc')
--self._linker_cmd = os.environ.get('LD', self._compiler_cmd)
-+self._linker_cmd = os.environ.get('CCLD', self._compiler_cmd)
- self._pkgconfig_cmd = os.environ.get('PKG_CONFIG', 'pkg-config')
-
- self._uninst_srcdir = os.environ.get(
-Index: git/giscanner/scannermain.py
-===
git.orig/giscanner/scannermain.py 2010-11-29 15:14:35.0 -0800
-+++ git/giscanner/scannermain.py 2010-11-29 15:14:57.120747321 -0800
-@@ -283,6 +283,7 @@
- shown_include_warning = False
- for include in options.includes:
- if os.sep in include:
-+continue
- raise ValueError(Invalid include path %r % (include, ))
- include_obj = Include.from_string(include)
- transformer.register_include(include_obj)
diff --git
a/meta/recipes-gnome/gnome/gobject-introspection/use-usr-bin-env-for-python.patch
b/meta/recipes-gnome/gnome/gobject-introspection/use-usr-bin-env-for-python.patch
new file mode 100644
index 000..67b8547
--- /dev/null
+++
b/meta/recipes-gnome/gnome/gobject-introspection/use-usr-bin-env-for-python.patch
@@ -0,0 +1,20 @@
+Index: gobject-introspection-0.9.10/tools/g-ir-annotation-tool.in
+===
+--- gobject-introspection-0.9.10.orig/tools/g-ir-annotation-tool.in
gobject-introspection-0.9.10/tools/g-ir-annotation-tool.in
+@@ -1,4 +1,4 @@
+-#!@PYTHON@
++#!/usr/bin/env python
+ # -*- Mode: Python -*-
+ # GObject-Introspection - a framework for introspecting GObject libraries
+ # Copyright (C) 2008 Johan Dahlin
+Index: gobject-introspection-0.9.10/tools/g-ir-scanner.in
+===
+---
Re: [OE-core] [PATCH 00/12] Recipe upgrades, fixes and additions
On Tue, 2011-11-15 at 11:03 -0800, Saul Wold wrote: On 11/08/2011 06:18 AM, Richard Purdie wrote: On Mon, 2011-11-07 at 16:10 -0800, Joshua Lock wrote: All, Here's a series of patches I developed whilst trying to play around with some Clutter based software. The interesting pieces may be: Clutter 1.8 series recipes - do we want/need to keep clutter 1.6 around? Are we OK with continuing to namespace the clutter recipes by clutter version? Yes, I think this makes sense. Why do we want to continue the clutter the namespace with version numbers? Was this not for a past issue with mis-matched API/ABI? If that problem is solved, then next remove that version info. Clutter produces libraries with a very specific namespace so you can parallel install clutter 1.4, 1.6 and 1.8. Applications compile against a given version of the library. Having the major lib version as part of the package name therefore makes sense. There aren't a lot of projects that do this but this one does and it continues to make sense to namespace it accordingly. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 00/12] Recipe upgrades, fixes and additions
On 15/11/11 13:38, Richard Purdie wrote: On Tue, 2011-11-15 at 11:03 -0800, Saul Wold wrote: On 11/08/2011 06:18 AM, Richard Purdie wrote: On Mon, 2011-11-07 at 16:10 -0800, Joshua Lock wrote: All, Here's a series of patches I developed whilst trying to play around with some Clutter based software. The interesting pieces may be: Clutter 1.8 series recipes - do we want/need to keep clutter 1.6 around? Are we OK with continuing to namespace the clutter recipes by clutter version? Yes, I think this makes sense. Why do we want to continue the clutter the namespace with version numbers? Was this not for a past issue with mis-matched API/ABI? If that problem is solved, then next remove that version info. Clutter produces libraries with a very specific namespace so you can parallel install clutter 1.4, 1.6 and 1.8. Applications compile against a given version of the library. Having the major lib version as part of the package name therefore makes sense. There aren't a lot of projects that do this but this one does and it continues to make sense to namespace it accordingly. With this knowledge in hand I've just re-read the 1.8 release notes[1] and, for better or for worse, this is no longer the case: * This version is API and ABI compatible with the current stable release of Clutter. * Installing the contents of this release will overwrite the files from the installation of the current release of Clutter. For point 1 I'd added a patch to PROVIDES = clutter-1.6 but I'm not sure what makes sense in the context of point 2. Cheers, Joshua 1. http://www.clutter-project.org/blogs/archive/2011-09/clutter-1.8.0-stable-release -- Joshua Lock Yocto Project Johannes factotum Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH][oe-core 14/22] libsdl: enable alsa/opengl based on PACKAGECONFIG and respect DISTRO_FEATURES
On Fri, Nov 11, 2011 at 05:28:50PM +0100, Martin Jansa wrote:
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/recipes-graphics/libsdl/libsdl_1.2.14.bb | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-graphics/libsdl/libsdl_1.2.14.bb
b/meta/recipes-graphics/libsdl/libsdl_1.2.14.bb
index 17a3103..2f49f16 100644
--- a/meta/recipes-graphics/libsdl/libsdl_1.2.14.bb
+++ b/meta/recipes-graphics/libsdl/libsdl_1.2.14.bb
@@ -12,7 +12,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=27818cd7fd83877a8e3ef82b82798ef4
PROVIDES = virtual/libsdl
-DEPENDS = ${@base_contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl',
'', d)} virtual/libx11 libxext libxrandr libxrender alsa-lib tslib
+DEPENDS = virtual/libx11 libxext libxrandr libxrender tslib
DEPENDS_virtclass-nativesdk = libx11-nativesdk libxrandr-nativesdk
libxrender-nativesdk libxext-nativesdk
As Saul reported PACKAGECONFIG adds build time depends not only to
DEPENDS but they also ends in DEPENDS_virtclass-nativesdk and nothing
provides virtual/libgl-nativesdk. So I've resend this patch changing
only alsa handling to PACKAGECONFIG and keeping opengl as it was.
Cheers,
PR = r1
@@ -29,17 +29,21 @@ SRC_URI[sha256sum] =
5d927e287034cb6bb0ebccfa382cb1d185cb113c8ab5115a0759798642
inherit autotools binconfig pkgconfig
EXTRA_OECONF = --disable-static --disable-debug --enable-cdrom
--enable-threads --enable-timers --enable-endian \
---enable-file --disable-oss --enable-alsa --disable-esd
--disable-arts \
+--enable-file --disable-oss --disable-esd --disable-arts \
--disable-diskaudio --disable-nas --disable-esd-shared
--disable-esdtest \
--disable-mintaudio --disable-nasm --enable-video-x11
--disable-video-dga \
--disable-video-fbcon --disable-video-directfb
--disable-video-ps2gs --disable-video-ps3 \
--disable-video-xbios --disable-video-gem
--disable-video-dummy \
--enable-input-events --enable-input-tslib --enable-pthreads
\
- ${@base_contains('DISTRO_FEATURES', 'opengl',
'--enable-video-opengl', '--disable-video-opengl', d)} \
--disable-video-svga \
--disable-video-picogui --disable-video-qtopia
--enable-dlopen \
--disable-rpath
+PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES', 'opengl', 'opengl',
'', d)} \
+ ${@base_contains('DISTRO_FEATURES', 'alsa', 'alsa', '',
d)}
+PACKAGECONFIG[alsa] = --enable-alsa,--disable-alsa,alsa-lib,
+PACKAGECONFIG[opengl] =
--enable-video-opengl,--disable-video-opengl,virtual/libgl,
+
PARALLEL_MAKE =
EXTRA_AUTORECONF += --include=acinclude --exclude=autoheader
--
1.7.8.rc1
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] mesa: fix cross compile failure
the bin/mklib file in mesa source code uses commands ar ranlib on build
machine, this causes build failed on some platform.
Signed-off-by: Kang Kai kai.k...@windriver.com
---
meta/recipes-graphics/mesa/mesa-7.11.inc |1 +
meta/recipes-graphics/mesa/mesa-common.inc |2 +-
.../mesa/mesa/crossfix-mklib.patch | 71
3 files changed, 73 insertions(+), 1 deletions(-)
create mode 100644 meta/recipes-graphics/mesa/mesa/crossfix-mklib.patch
diff --git a/meta/recipes-graphics/mesa/mesa-7.11.inc
b/meta/recipes-graphics/mesa/mesa-7.11.inc
index 746b764..2f14ed4 100644
--- a/meta/recipes-graphics/mesa/mesa-7.11.inc
+++ b/meta/recipes-graphics/mesa/mesa-7.11.inc
@@ -2,6 +2,7 @@ DEPENDS += mesa-dri-glsl-native
SRC_URI += file://uclibc.patch \
file://crossfix.patch \
+file://crossfix-mklib.patch \
SRC_URI[md5sum] = ff03aca82d0560009a076a87c888cf13
SRC_URI[sha256sum] =
f8bf37a00882840a3e3d327576bc26a79ae7f4e18fe1f7d5f17a5b1c80dd7acf
diff --git a/meta/recipes-graphics/mesa/mesa-common.inc
b/meta/recipes-graphics/mesa/mesa-common.inc
index 06ebb75..1d9c894 100644
--- a/meta/recipes-graphics/mesa/mesa-common.inc
+++ b/meta/recipes-graphics/mesa/mesa-common.inc
@@ -12,7 +12,7 @@ SECTION = x11
LICENSE = MIT
LIC_FILES_CHKSUM =
file://docs/license.html;md5=7a3373c039b6b925c427755a4f779c1d
-INC_PR = r12
+INC_PR = r13
PE = 2
SRC_URI = ftp://ftp.freedesktop.org/pub/mesa/${PV}/MesaLib-${PV}.tar.bz2;
diff --git a/meta/recipes-graphics/mesa/mesa/crossfix-mklib.patch
b/meta/recipes-graphics/mesa/mesa/crossfix-mklib.patch
new file mode 100644
index 000..dc08228
--- /dev/null
+++ b/meta/recipes-graphics/mesa/mesa/crossfix-mklib.patch
@@ -0,0 +1,71 @@
+This patch is ported from WindRiver linux and to fix cross compile failure.
+
+And original commits are:
+commit 8d5ccc8113e1b51b0529a00c18a4aba956247e1b
+commit 5c4212084b871a0c0fb7d174280ec9a634637deb
+
+Upstream-Status: Pending
+
+Signed-off-by: Kang Kai kai.k...@windriver.com
+
+--- Mesa-7.10.2/bin/mklib.orig 2011-09-28 16:15:34.17074 +0800
Mesa-7.10.2/bin/mklib 2011-09-28 16:15:42.37073 +0800
+@@ -49,8 +49,8 @@
+ /*) ;;
+ *) FILE=$ORIG_DIR/$FILE ;;
+ esac
+-MEMBERS=`ar t $FILE`
+-ar x $FILE
++MEMBERS=`${AR} t $FILE`
++${AR} x $FILE
+ for MEMBER in $MEMBERS ; do
+ NEWFILES=$NEWFILES $DIR/$MEMBER
+ done
+@@ -77,7 +77,7 @@
+ make_ar_static_lib() {
+ OPTS=$1
+ shift;
+-RANLIB=$1
++USE_RANLIB=$1
+ shift;
+ LIBNAME=$1
+ shift;
+@@ -87,11 +87,11 @@
+ rm -f ${LIBNAME}
+
+ # make static lib
+-ar ${OPTS} ${LIBNAME} ${OBJECTS}
++${AR} ${OPTS} ${LIBNAME} ${OBJECTS}
+
+ # run ranlib
+-if [ ${RANLIB} = 1 ] ; then
+-ranlib ${LIBNAME}
++if [ ${USE_RANLIB} = 1 ] ; then
++${RANLIB} ${LIBNAME}
+ fi
+
+ echo ${LIBNAME}
+@@ -313,9 +313,9 @@
+ if [ x$LINK = x ] ; then
+ # -linker was not specified so set default link command now
+ if [ $CPLUSPLUS = 1 ] ; then
+-LINK=g++
++LINK=$CXX
+ else
+-LINK=gcc
++LINK=$CC
+ fi
+ fi
+
+@@ -531,9 +531,9 @@
+ if [ x$LINK = x ] ; then
+ # -linker was not specified so set default link command now
+ if [ $CPLUSPLUS = 1 ] ; then
+-LINK=g++
++LINK=${CXX}
+ else
+-LINK=gcc
++LINK=${CC}
+ fi
+ fi
+
--
1.7.5.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] mesa: fix cross compile failure
Hi All, the bin/mklib file in mesa source code uses commands ar ranlib on build machine, this causes build failed on some platform. Thanks Khem, Martin and Koen's review for previous version of this serious patch. The following changes since commit d8193f19fe94224089b0e5fc2026a843f7bd0709: opkg: Ensure we use the uname/gname fields when extracting tarballs (2011-11-14 11:15:45 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib kangkai/distro http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=kangkai/distro Kang Kai (1): mesa: fix cross compile failure meta/recipes-graphics/mesa/mesa-7.11.inc |1 + meta/recipes-graphics/mesa/mesa-common.inc |2 +- .../mesa/mesa/crossfix-mklib.patch | 71 3 files changed, 73 insertions(+), 1 deletions(-) create mode 100644 meta/recipes-graphics/mesa/mesa/crossfix-mklib.patch -- 1.7.5.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
