[OE-core] [RFC v1 0/1] Reorder ${PN} and ${PN}-dev
This RFC is the first pass at reordering the above 2 items in
the PACKAGES list. This is in part an out cropping of the bug
#2367 (https://bugzilla.yoctoproject.org/show_bug.cgi?id=2367),
which show the miss packaged pcap-config file.
A number of the changes below are PR bumps since I also changed
the contents of binconfig.bbclass (which would really go away in
favor of .pc files, but we need a step-wise approach.)
This change set is still evolving, I am using the buildhistory
to compare the results and at this time most of the changes are
correct. The major difference is that it requires more specific
enumeration of files, especially when delivered to /usr/lib/${BPN}
And yes, I have thought about how I can break this up, but I am not
sure it can be since once I change the bitbake.conf, numerous erros
and warnings are created.
This will most likley require some changes in meta-oe and other layers.
Comments suggested, improvemts always welcome!
Sau!
The following changes since commit 326563d5a897ae2dba7cfd8d73579d3d979d72c8:
sstate.bbclass: Make sure we don't have an empty fixmepath file (2012-05-18
15:24:45 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib sgw/pkg-reorder
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/pkg-reorder
Saul Wold (1):
Reorder and -dev
meta/classes/binconfig.bbclass |2 ++
meta/conf/bitbake.conf |8 +---
meta/recipes-bsp/pm-utils/pm-utils_1.4.1.bb| 10 ++
meta/recipes-connectivity/libpcap/libpcap.inc |2 +-
meta/recipes-core/eglibc/eglibc-package.inc|2 +-
meta/recipes-core/eglibc/eglibc_2.15.bb|2 +-
meta/recipes-core/gettext/gettext_0.16.1.bb|3 ++-
meta/recipes-core/gettext/gettext_0.18.1.1.bb |4 +++-
meta/recipes-core/libxml/libxml2.inc |2 +-
meta/recipes-core/ncurses/ncurses.inc |2 +-
meta/recipes-extended/cups/cups14.inc |1 +
meta/recipes-extended/cups/cups_1.4.6.bb |2 +-
meta/recipes-extended/groff/groff_1.20.1.bb|4 +++-
meta/recipes-extended/slang/slang_2.2.4.bb |4 ++--
meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb | 14 ++
meta/recipes-gnome/gthumb/gthumb_2.12.4.bb | 12
meta/recipes-graphics/directfb/directfb_1.4.15.bb |2 +-
meta/recipes-graphics/freetype/freetype_2.4.8.bb |5 +
meta/recipes-graphics/libsdl/libsdl_1.2.15.bb |2 +-
meta/recipes-multimedia/alsa/alsa-lib_1.0.25.bb|6 --
meta/recipes-multimedia/libpng/libpng_1.2.49.bb|4 +---
meta/recipes-support/apr/apr-util_1.4.1.bb |2 +-
meta/recipes-support/apr/apr_1.4.6.bb |2 +-
meta/recipes-support/curl/curl_7.24.0.bb |2 +-
meta/recipes-support/db/db_5.1.19.bb |1 +
meta/recipes-support/gnutls/gnutls.inc |5 ++---
meta/recipes-support/gnutls/libtasn1_2.12.bb |2 +-
meta/recipes-support/gpgme/gpgme_1.3.1.bb |5 ++---
meta/recipes-support/icu/icu-3.6.inc |2 ++
meta/recipes-support/icu/icu_3.6.bb|2 +-
meta/recipes-support/libassuan/libassuan_2.0.3.bb |1 +
meta/recipes-support/libgcrypt/libgcrypt.inc |4
.../libgpg-error/libgpg-error_1.10.bb |6 +-
meta/recipes-support/libksba/libksba_1.2.0.bb |1 +
meta/recipes-support/libpcre/libpcre_8.21.bb |5 +
meta/recipes-support/libproxy/libproxy_0.4.7.bb|3 ++-
meta/recipes-support/libusb/libusb-compat_0.1.3.bb |4 +---
meta/recipes-support/libxslt/libxslt_1.1.26.bb |2 +-
meta/recipes-support/neon/neon_0.29.6.bb |2 +-
meta/recipes-support/pth/pth_2.0.7.bb |5 +
meta/recipes-support/taglib/taglib_1.6.3.bb|3 +--
41 files changed, 83 insertions(+), 69 deletions(-)
--
1.7.7.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC v1 1/1] Reorder and -dev
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/classes/binconfig.bbclass |2 ++
meta/conf/bitbake.conf |8 +---
meta/recipes-bsp/pm-utils/pm-utils_1.4.1.bb| 10 ++
meta/recipes-connectivity/libpcap/libpcap.inc |2 +-
meta/recipes-core/eglibc/eglibc-package.inc|2 +-
meta/recipes-core/eglibc/eglibc_2.15.bb|2 +-
meta/recipes-core/gettext/gettext_0.16.1.bb|3 ++-
meta/recipes-core/gettext/gettext_0.18.1.1.bb |4 +++-
meta/recipes-core/libxml/libxml2.inc |2 +-
meta/recipes-core/ncurses/ncurses.inc |2 +-
meta/recipes-extended/cups/cups14.inc |1 +
meta/recipes-extended/cups/cups_1.4.6.bb |2 +-
meta/recipes-extended/groff/groff_1.20.1.bb|4 +++-
meta/recipes-extended/slang/slang_2.2.4.bb |4 ++--
meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb | 14 ++
meta/recipes-gnome/gthumb/gthumb_2.12.4.bb | 12
meta/recipes-graphics/directfb/directfb_1.4.15.bb |2 +-
meta/recipes-graphics/freetype/freetype_2.4.8.bb |5 +
meta/recipes-graphics/libsdl/libsdl_1.2.15.bb |2 +-
meta/recipes-multimedia/alsa/alsa-lib_1.0.25.bb|6 --
meta/recipes-multimedia/libpng/libpng_1.2.49.bb|4 +---
meta/recipes-support/apr/apr-util_1.4.1.bb |2 +-
meta/recipes-support/apr/apr_1.4.6.bb |2 +-
meta/recipes-support/curl/curl_7.24.0.bb |2 +-
meta/recipes-support/db/db_5.1.19.bb |1 +
meta/recipes-support/gnutls/gnutls.inc |5 ++---
meta/recipes-support/gnutls/libtasn1_2.12.bb |2 +-
meta/recipes-support/gpgme/gpgme_1.3.1.bb |5 ++---
meta/recipes-support/icu/icu-3.6.inc |2 ++
meta/recipes-support/icu/icu_3.6.bb|2 +-
meta/recipes-support/libassuan/libassuan_2.0.3.bb |1 +
meta/recipes-support/libgcrypt/libgcrypt.inc |4
.../libgpg-error/libgpg-error_1.10.bb |6 +-
meta/recipes-support/libksba/libksba_1.2.0.bb |1 +
meta/recipes-support/libpcre/libpcre_8.21.bb |5 +
meta/recipes-support/libproxy/libproxy_0.4.7.bb|3 ++-
meta/recipes-support/libusb/libusb-compat_0.1.3.bb |4 +---
meta/recipes-support/libxslt/libxslt_1.1.26.bb |2 +-
meta/recipes-support/neon/neon_0.29.6.bb |2 +-
meta/recipes-support/pth/pth_2.0.7.bb |5 +
meta/recipes-support/taglib/taglib_1.6.3.bb|3 +--
41 files changed, 83 insertions(+), 69 deletions(-)
diff --git a/meta/classes/binconfig.bbclass b/meta/classes/binconfig.bbclass
index 3deb541..60012c8 100644
--- a/meta/classes/binconfig.bbclass
+++ b/meta/classes/binconfig.bbclass
@@ -1,3 +1,5 @@
+FILES_${PN}-dev += ${bindir}/*-config
+
# The namespaces can clash here hence the two step replace
def get_binconfig_mangle(d):
s = -e ''
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 7073018..a8485c3 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -253,7 +253,7 @@ SOLIBSDEV_darwin = .dylib
SOLIBSDEV_darwin8 = .dylib
SOLIBSDEV_darwin9 = .dylib
-PACKAGES = ${PN}-dbg ${PN}-staticdev ${PN} ${PN}-doc ${PN}-dev ${PN}-locale
+PACKAGES = ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN} ${PN}-doc ${PN}-locale
PACKAGES_DYNAMIC = ${PN}-locale-*
FILES =
@@ -261,7 +261,7 @@ FILES_${PN} = ${bindir}/* ${sbindir}/* ${libexecdir}/*
${libdir}/lib*${SOLIBS}
${sysconfdir} ${sharedstatedir} ${localstatedir} \
${base_bindir}/* ${base_sbindir}/* \
${base_libdir}/*${SOLIBS} \
-${datadir}/${BPN} ${libdir}/${BPN}/* \
+${datadir}/${BPN} ${libdir}/${BPN}/*${SOLIBS} \
${datadir}/pixmaps ${datadir}/applications \
${datadir}/idl ${datadir}/omf ${datadir}/sounds \
${libdir}/bonobo/servers
@@ -272,7 +272,9 @@ SECTION_${PN}-doc = doc
FILES_${PN}-dev = ${includedir} ${libdir}/lib*${SOLIBSDEV} ${libdir}/*.la \
${libdir}/*.o ${libdir}/pkgconfig ${datadir}/pkgconfig \
-${datadir}/aclocal ${base_libdir}/*.o
+${datadir}/aclocal ${base_libdir}/*.o \
+${libdir}/${BPN}/*.la \
+${base_libdir}/*${SOLIBSDEV} ${base_libdir}/*.la
SECTION_${PN}-dev = devel
ALLOW_EMPTY_${PN}-dev = 1
RDEPENDS_${PN}-dev = ${PN} (= ${EXTENDPKGV})
diff --git a/meta/recipes-bsp/pm-utils/pm-utils_1.4.1.bb
b/meta/recipes-bsp/pm-utils/pm-utils_1.4.1.bb
index 92d65c1..098b6d4 100644
--- a/meta/recipes-bsp/pm-utils/pm-utils_1.4.1.bb
+++ b/meta/recipes-bsp/pm-utils/pm-utils_1.4.1.bb
@@ -6,8 +6,12 @@ LICENSE=GPLv2
LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
Re: [OE-core] [RFC v1 1/1] Reorder and -dev
On Sun, May 20, 2012 at 11:42:16PM -0700, Saul Wold wrote:
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/classes/binconfig.bbclass |2 ++
meta/conf/bitbake.conf |8 +---
meta/recipes-bsp/pm-utils/pm-utils_1.4.1.bb| 10 ++
meta/recipes-connectivity/libpcap/libpcap.inc |2 +-
meta/recipes-core/eglibc/eglibc-package.inc|2 +-
meta/recipes-core/eglibc/eglibc_2.15.bb|2 +-
meta/recipes-core/gettext/gettext_0.16.1.bb|3 ++-
meta/recipes-core/gettext/gettext_0.18.1.1.bb |4 +++-
meta/recipes-core/libxml/libxml2.inc |2 +-
meta/recipes-core/ncurses/ncurses.inc |2 +-
meta/recipes-extended/cups/cups14.inc |1 +
meta/recipes-extended/cups/cups_1.4.6.bb |2 +-
meta/recipes-extended/groff/groff_1.20.1.bb|4 +++-
meta/recipes-extended/slang/slang_2.2.4.bb |4 ++--
meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb | 14 ++
meta/recipes-gnome/gthumb/gthumb_2.12.4.bb | 12
meta/recipes-graphics/directfb/directfb_1.4.15.bb |2 +-
meta/recipes-graphics/freetype/freetype_2.4.8.bb |5 +
meta/recipes-graphics/libsdl/libsdl_1.2.15.bb |2 +-
meta/recipes-multimedia/alsa/alsa-lib_1.0.25.bb|6 --
meta/recipes-multimedia/libpng/libpng_1.2.49.bb|4 +---
meta/recipes-support/apr/apr-util_1.4.1.bb |2 +-
meta/recipes-support/apr/apr_1.4.6.bb |2 +-
meta/recipes-support/curl/curl_7.24.0.bb |2 +-
meta/recipes-support/db/db_5.1.19.bb |1 +
meta/recipes-support/gnutls/gnutls.inc |5 ++---
meta/recipes-support/gnutls/libtasn1_2.12.bb |2 +-
meta/recipes-support/gpgme/gpgme_1.3.1.bb |5 ++---
meta/recipes-support/icu/icu-3.6.inc |2 ++
meta/recipes-support/icu/icu_3.6.bb|2 +-
meta/recipes-support/libassuan/libassuan_2.0.3.bb |1 +
meta/recipes-support/libgcrypt/libgcrypt.inc |4
.../libgpg-error/libgpg-error_1.10.bb |6 +-
meta/recipes-support/libksba/libksba_1.2.0.bb |1 +
meta/recipes-support/libpcre/libpcre_8.21.bb |5 +
meta/recipes-support/libproxy/libproxy_0.4.7.bb|3 ++-
meta/recipes-support/libusb/libusb-compat_0.1.3.bb |4 +---
meta/recipes-support/libxslt/libxslt_1.1.26.bb |2 +-
meta/recipes-support/neon/neon_0.29.6.bb |2 +-
meta/recipes-support/pth/pth_2.0.7.bb |5 +
meta/recipes-support/taglib/taglib_1.6.3.bb|3 +--
41 files changed, 83 insertions(+), 69 deletions(-)
diff --git a/meta/classes/binconfig.bbclass b/meta/classes/binconfig.bbclass
index 3deb541..60012c8 100644
--- a/meta/classes/binconfig.bbclass
+++ b/meta/classes/binconfig.bbclass
@@ -1,3 +1,5 @@
+FILES_${PN}-dev += ${bindir}/*-config
+
# The namespaces can clash here hence the two step replace
def get_binconfig_mangle(d):
s = -e ''
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 7073018..a8485c3 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -253,7 +253,7 @@ SOLIBSDEV_darwin = .dylib
SOLIBSDEV_darwin8 = .dylib
SOLIBSDEV_darwin9 = .dylib
-PACKAGES = ${PN}-dbg ${PN}-staticdev ${PN} ${PN}-doc ${PN}-dev ${PN}-locale
+PACKAGES = ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN} ${PN}-doc ${PN}-locale
PACKAGES_DYNAMIC = ${PN}-locale-*
FILES =
@@ -261,7 +261,7 @@ FILES_${PN} = ${bindir}/* ${sbindir}/* ${libexecdir}/*
${libdir}/lib*${SOLIBS}
${sysconfdir} ${sharedstatedir} ${localstatedir} \
${base_bindir}/* ${base_sbindir}/* \
${base_libdir}/*${SOLIBS} \
-${datadir}/${BPN} ${libdir}/${BPN}/* \
+${datadir}/${BPN} ${libdir}/${BPN}/*${SOLIBS} \
${datadir}/pixmaps ${datadir}/applications \
${datadir}/idl ${datadir}/omf ${datadir}/sounds \
${libdir}/bonobo/servers
@@ -272,7 +272,9 @@ SECTION_${PN}-doc = doc
FILES_${PN}-dev = ${includedir} ${libdir}/lib*${SOLIBSDEV} ${libdir}/*.la \
${libdir}/*.o ${libdir}/pkgconfig ${datadir}/pkgconfig \
-${datadir}/aclocal ${base_libdir}/*.o
+${datadir}/aclocal ${base_libdir}/*.o \
+${libdir}/${BPN}/*.la \
+${base_libdir}/*${SOLIBSDEV} ${base_libdir}/*.la
SECTION_${PN}-dev = devel
ALLOW_EMPTY_${PN}-dev = 1
RDEPENDS_${PN}-dev = ${PN} (= ${EXTENDPKGV})
diff --git a/meta/recipes-bsp/pm-utils/pm-utils_1.4.1.bb
b/meta/recipes-bsp/pm-utils/pm-utils_1.4.1.bb
index 92d65c1..098b6d4 100644
--- a/meta/recipes-bsp/pm-utils/pm-utils_1.4.1.bb
+++ b/meta/recipes-bsp/pm-utils/pm-utils_1.4.1.bb
@@ -6,8 +6,12 @@ LICENSE=GPLv2
LIC_FILES_CHKSUM =
[OE-core] About RPMs installation
Hi All, can I have an help about rpms installation, once they were built by oc-core? I produced both .tgz and rpms, I'm wondering how to install them (maybe using chroot, but I'm newbe about it). Please, have you suggestions? Thanks, Giuseppe ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] About RPMs installation
I'm not very clear about your questions, but the easiest way should be: 1) boot your image 2) copy your RPMs to the image via scp 3) rpm -Uvh /pat/to/rpm_file.rpm // Robert On 05/21/2012 03:12 PM, Giuseppe Condorelli wrote: Hi All, can I have an help about rpms installation, once they were built by oc-core? I produced both .tgz and rpms, I'm wondering how to install them (maybe using chroot, but I'm newbe about it). Please, have you suggestions? Thanks, Giuseppe ___ 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] [RFC][PATCH 00/14] mips64 support and sh4 support
On Sun, 2012-05-20 at 20:35 -0700, Khem Raj wrote:
This patchset adds required bits into metadata for having
mips64/n64 support. I have tested the core-image-sato and core-image-minimal
builds and boots on qemumips64 and runs gcc regression testsuite.
It needs linux-yocto-dev kernel for now which can be obtained from
poky-extra repo. Additionally systemd-image on angstrom-next builds and boots
fine on qemumips64 as well.
Additionally it also adds bits to have SH4 root file systems to be
able to built and again core-image-sato builds for sh4 however qemu
machine support is not yet done but root file sytem boots fine on
real hardware.
The images are tested on both eglibc and uclibc.
Any help in providing feedback or testing these patches is welcome.
I have tested them enough for over a month now.
The following changes since commit 326563d5a897ae2dba7cfd8d73579d3d979d72c8:
sstate.bbclass: Make sure we don't have an empty fixmepath file (2012-05-18
15:24:45 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib kraj/mips64
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=kraj/mips64
Khem Raj (14):
insane.bbclass: Add mips64{el} to known machines
site: Add mips64 eglibc and uclibc site files
gcc-4.6, gcc-4.7: Add support for building mips64 cross compiler
binutils: Default to n64 when configured for mips64
kernel-arch.bbclass: Map mips64{el} to mips KARCH
eglibc-2.15: Support mips64
libc-package: Add sh4 and mips64 to arch options
runqemu: Add qemush4 and qemumips64 knowledge
netbase: Add interface files for qemumips64 and qemush4
site/sh-common: Add missing caches variables to build glib-2.32
xserver-xorg: Fix build for mips64
tune-mips64.inc: Add new tune file for mips64 big-endian
qemumips64.conf: Add machine configuration for mips64(eb)
qemush4.conf: Add machine configuration for qemush4
We need to figure out what it means to add new qemu machines like this
to OE-Core. I'm not against it however I can't offer the Yocto Project's
resources to test them at this point as we're haven't budgeted for it.
The above patches make sense regardless so I've merged them except the
final two machine files. I'd like to hold off adding those until the
system builds and runs with our default kernel and qemu recipes.
Hopefully this lets you develop without having a huge queue of patches.
In the meantime we need to figure out the resource concern for testing.
Is there a commercial interest in these new machines from anyone who
could perhaps help with the resource issue?
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] About RPMs installation
On Mon, 2012-05-21 at 09:12 +0200, Giuseppe Condorelli wrote: Hi All, can I have an help about rpms installation, once they were built by oc-core? I produced both .tgz and rpms, I'm wondering how to install them (maybe using chroot, but I'm newbe about it). Please, have you suggestions? They can either be pre-installed as a complete image using one of the image targets (like core-image-minimal), or you can install them on your target device manually. 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] bb/fetch2/__init__.py: Don't try to compute checksums for directories
On Sun, 2012-05-20 at 20:16 +0300, Andrei Gherzan wrote: In this way we avoid failing the build while trying to fetch local directories. [YOCTO #2475] Signed-off-by: Andrei Gherzan and...@gherzan.ro --- bitbake/lib/bb/fetch2/__init__.py |5 + 1 file changed, 5 insertions(+) Please send bitbake patches to the bitbake-devel list in future. I've applied this one directly since there is a clear need to fix problems though, thanks! 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] bb/fetch2/__init__.py: Don't try to compute checksums for directories
On Mon, May 21, 2012 at 11:25 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Sun, 2012-05-20 at 20:16 +0300, Andrei Gherzan wrote: In this way we avoid failing the build while trying to fetch local directories. [YOCTO #2475] Signed-off-by: Andrei Gherzan and...@gherzan.ro --- bitbake/lib/bb/fetch2/__init__.py |5 + 1 file changed, 5 insertions(+) Please send bitbake patches to the bitbake-devel list in future. I've applied this one directly since there is a clear need to fix problems though, thanks! I will. Thanks. @g ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] avahi-systemd: drop postrm, use prerm instead
On 18.05.2012 17:06, Enrico Scholz wrote: Andreas Oberritter obi-Le4rqY8tBtjh/77yhsl...@public.gmane.org writes: What's the use case for removing packages offline I am developing very much with NFS root filesystems (-- the temporary image directory which is kept by IMAGE_KEEPROOTFS=1). Packaging operations like install, remove or upgrade are common actions to test recipes and applications. Just to make sure we're talking about the same thing: Do you run opkg-cl on the build machine to remove or upgrade packages inside the target's NFS root? Regards, Andreas ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] ncurses: Avoid occasional builling failure when having parallel processable task
From: Xiaofeng Yan xiaofeng@windriver.com | tic: error while loading shared libraries: /srv/home/pokybuild \ /yocto-autobuilder/yocto-slave/nightly-non-gpl3/build/build/tmp/\ work/x86_64-linux/ncurses-native-5.9-r8.1/ncurses-5.9/narrowc/lib\ /libtinfo.so.5: file too short | ? tic could not build /srv/home/pokybuild/yocto-autobuilder/\ yocto-slave/nightly-non-gpl3/build/build/tmp/work/x86_64-linux/\ ncurses-native-5.9-r8.1/image/srv/home/pokybuild/yocto-autobuilder\ /yocto-slave/nightly-non-gpl3/build/build/tmp/sysroots/x86_64-linux\ /usr/share/terminfo | make[1]: *** [install.data] Error 1 This is a race issue which is caused by install.libs and install.data: 1) install.data needs run tic 2) tic needs libtinfo.so 3) install.libs would regenerate libtinfo.so 4) but install.data doesn't depend on install.libs, and they can run parallelly So there would be errors in a very critical condition: tic is begining to run at the same time when install.libs is generating libtinfo.so, and this libtinfo.so is not integrity, then there would be the above error. Let task install.libs run before install.data for fixing this bug. The following changes since commit b4c8c74a45e386f99344cf9799eb5294ad6c9e3e: Joshua Lock (1): hob: update required pygtk to 2.22.0 and gtk+ to 2.20.0 are available in the git repository at: git://git.pokylinux.org/poky-contrib xiaofeng/2298 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=xiaofeng/2298 Xiaofeng Yan (1): ncurses: Avoid occasional builling failure when having parallel processable task meta/recipes-core/ncurses/ncurses.inc | 23 ++- 1 files changed, 18 insertions(+), 5 deletions(-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] ncurses: Avoid occasional builling failure when having parallel processable task
From: Xiaofeng Yan xiaofeng@windriver.com
ncurses failure non-gplv3 build (race issue) like the following \
error information:
| tic: error while loading shared libraries: /srv/home/pokybuild \
/yocto-autobuilder/yocto-slave/nightly-non-gpl3/build/build/tmp/\
work/x86_64-linux/ncurses-native-5.9-r8.1/ncurses-5.9/narrowc/lib\
/libtinfo.so.5: file too short
| ? tic could not build /srv/home/pokybuild/yocto-autobuilder/\
yocto-slave/nightly-non-gpl3/build/build/tmp/work/x86_64-linux/\
ncurses-native-5.9-r8.1/image/srv/home/pokybuild/yocto-autobuilder\
/yocto-slave/nightly-non-gpl3/build/build/tmp/sysroots/x86_64-linux\
/usr/share/terminfo
| make[1]: *** [install.data] Error 1
This is a race issue which is caused by
install.libs and install.data:
1) install.data needs run tic
2) tic needs libtinfo.so
3) install.libs would regenerate libtinfo.so
4) but install.data doesn't depend on install.libs, and they can run
parallelly
So there would be errors in a very critical condition: tic is begining
to run at the same time when install.libs is generating libtinfo.so, and
this libtinfo.so is not integrity, then there would be the above error.
Let task install.libs run before install.data for fixing this bug.
[YOCTO #2298]
Signed-off-by: Xiaofeng Yan xiaofeng@windriver.com
---
meta/recipes-core/ncurses/ncurses.inc | 23 ++-
1 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/meta/recipes-core/ncurses/ncurses.inc
b/meta/recipes-core/ncurses/ncurses.inc
index ae99e2c..b031119 100644
--- a/meta/recipes-core/ncurses/ncurses.inc
+++ b/meta/recipes-core/ncurses/ncurses.inc
@@ -6,7 +6,7 @@ LIC_FILES_CHKSUM =
file://ncurses/base/version.c;beginline=1;endline=27;md5=cbc
SECTION = libs
DEPENDS = ncurses-native
DEPENDS_virtclass-native =
-INC_PR = r8
+INC_PR = r9
inherit autotools binconfig multilib_header
@@ -107,10 +107,15 @@ do_test() {
diff curses-narrowc.h curses-widec.h
}
+# Split original _install_opts to two parts.
+# One is the options to install contents, the other is the parameters \
+# when running command make install
_install_opts = \
+ install.libs install.includes install.man \
+
+_install_cfgs = \
DESTDIR='${D}' \
PKG_CONFIG_LIBDIR='${libdir}/pkgconfig' \
- install.libs install.includes install.man \
python do_install () {
@@ -122,11 +127,19 @@ shell_do_install() {
# Order of installation is important; widec installs a 'curses.h'
# header with more definitions and must be installed last hence.
# Compatibility of these headers will be checked in 'do_test()'.
-oe_runmake -C narrowc ${_install_opts} \
-install.data install.progs
+oe_runmake -C narrowc ${_install_cfgs} ${_install_opts} \
+install.progs
+
+# The install.data should run after install.libs, otherwise
+# there would be a race issue in a very critical conditon, since
+# tic will be run by install.data, and tic needs libtinfo.so
+# which would be regenerated by install.libs.
+oe_runmake -C narrowc ${_install_cfgs} \
+install.data
+
! ${ENABLE_WIDEC} || \
-oe_runmake -C widec ${_install_opts}
+oe_runmake -C widec ${_install_cfgs} ${_install_opts}
cd narrowc
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] avahi-systemd: drop postrm, use prerm instead
Andreas Oberritter o...@opendreambox.org writes: What's the use case for removing packages offline I am developing very much with NFS root filesystems (-- the temporary image directory which is kept by IMAGE_KEEPROOTFS=1). Packaging operations like install, remove or upgrade are common actions to test recipes and applications. Just to make sure we're talking about the same thing: Do you run opkg-cl on the build machine to remove or upgrade packages inside the target's NFS root? yes; I am working on the build machine. The NFS filesystem is mounted read-only on the target. Enrico ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] avahi-systemd: drop postrm, use prerm instead
On 21.05.2012 11:18, Enrico Scholz wrote: Andreas Oberritter o...@opendreambox.org writes: What's the use case for removing packages offline I am developing very much with NFS root filesystems (-- the temporary image directory which is kept by IMAGE_KEEPROOTFS=1). Packaging operations like install, remove or upgrade are common actions to test recipes and applications. Just to make sure we're talking about the same thing: Do you run opkg-cl on the build machine to remove or upgrade packages inside the target's NFS root? yes; I am working on the build machine. The NFS filesystem is mounted read-only on the target. How do you handle prerm and postrm scripts that fail because $D is set? How do you handle the majority of scripts that don't care about $D at all? I think your use case is unsupported and always will be. In contrast, packages having failing postinst scripts will re-run their scripts on the target on first boot. Regards, Andreas ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC v1 1/1] Reorder and -dev
On Mon, May 21, 2012 at 3:53 AM, Martin Jansa martin.ja...@gmail.com wrote:
the rest looks ok, but I'm pretty scared from such changes, does your
buildhistory diffs show just *-config file moves or something else too?
It would be nice if some images could be build before and after the
patch and check before proposing this for merging.
When you're at it, does it make sense to move also ${PN}-doc
${PN}-locale before ${PN} in PACKAGES? Both have well defined FILES
patterns, so ${PN} last can be used as catch all.
It'd be awesome; but let's do it step by step or the time to fix all
possible mess of it might be to long ;-)
--
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC v1 1/1] Reorder and -dev
Op 21 mei 2012, om 12:48 heeft Otavio Salvador het volgende geschreven: On Mon, May 21, 2012 at 3:53 AM, Martin Jansa martin.ja...@gmail.com wrote: the rest looks ok, but I'm pretty scared from such changes, does your buildhistory diffs show just *-config file moves or something else too? It would be nice if some images could be build before and after the patch and check before proposing this for merging. Indeed, run the buildhistory output through Pauls analysis tool and share the results. 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] avahi-systemd: drop postrm, use prerm instead
Andreas Oberritter o...@opendreambox.org writes: What's the use case for removing packages offline yes; I am working on the build machine. The NFS filesystem is mounted read-only on the target. How do you handle prerm and postrm scripts that fail because $D is set? Fortunately, there are very few packages where this failure is critical (-- package is not working). Important tasks like user creation, alternatives handling or systemctl calls take care about offline package management already. kernel modules are the only package class which might affect me and is not suited for offline installation/upgrades. But I can live with it because I develop the kernel at a separate location and call 'make modules_install INSTALL_MOD_PATH=nfsroot' there. How do you handle the majority of scripts that don't care about $D at all? Examples? pseudo does a good job for 'systemctl enable/disable' or update-alternatives operations, 'systemd.bbclass' wraps the 'systemctl stop/start'. Btw... your patch is correct about removal of $D. As written above, it is not needed for 'systemctl disable'. But I am against removal of offline capabilities because they are not needed in 80% of use cases. Enrico ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] avahi-systemd: drop postrm, use prerm instead
On 21.05.2012 13:04, Enrico Scholz wrote: Andreas Oberritter o...@opendreambox.org writes: What's the use case for removing packages offline yes; I am working on the build machine. The NFS filesystem is mounted read-only on the target. How do you handle prerm and postrm scripts that fail because $D is set? Fortunately, there are very few packages where this failure is critical (-- package is not working). Important tasks like user creation, alternatives handling or systemctl calls take care about offline package management already. kernel modules are the only package class which might affect me and is not suited for offline installation/upgrades. But I can live with it because I develop the kernel at a separate location and call 'make modules_install INSTALL_MOD_PATH=nfsroot' there. How do you handle the majority of scripts that don't care about $D at all? Examples? Every recipe inheriting gconf.bbclass, gtk-icon-cache.bbclass, kernel.bbclass, module.bbclass or libc-package.bbclass, for example. You can use git grep '$D' to find more candidates. pseudo does a good job for 'systemctl enable/disable' or update-alternatives operations, 'systemd.bbclass' wraps the 'systemctl stop/start'. Btw... your patch is correct about removal of $D. As written above, it is not needed for 'systemctl disable'. But I am against removal of offline capabilities because they are not needed in 80% of use cases. Considering that in the meantime my similar patch [1] to systemd.bbclass got merged into meta-oe by Koen, who initially was against it, I guess this patch can finally get merged now, too. Regards, Andreas [1] http://git.openembedded.org/meta-openembedded/commit/?id=637cb7e3d2cfdc74d239a4257e6f3477aa17da4e ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] avahi-systemd: drop postrm, use prerm instead
Op 21 mei 2012, om 13:49 heeft Andreas Oberritter het volgende geschreven: On 21.05.2012 13:04, Enrico Scholz wrote: Andreas Oberritter o...@opendreambox.org writes: What's the use case for removing packages offline yes; I am working on the build machine. The NFS filesystem is mounted read-only on the target. How do you handle prerm and postrm scripts that fail because $D is set? Fortunately, there are very few packages where this failure is critical (-- package is not working). Important tasks like user creation, alternatives handling or systemctl calls take care about offline package management already. kernel modules are the only package class which might affect me and is not suited for offline installation/upgrades. But I can live with it because I develop the kernel at a separate location and call 'make modules_install INSTALL_MOD_PATH=nfsroot' there. How do you handle the majority of scripts that don't care about $D at all? Examples? Every recipe inheriting gconf.bbclass, gtk-icon-cache.bbclass, kernel.bbclass, module.bbclass or libc-package.bbclass, for example. You can use git grep '$D' to find more candidates. pseudo does a good job for 'systemctl enable/disable' or update-alternatives operations, 'systemd.bbclass' wraps the 'systemctl stop/start'. Btw... your patch is correct about removal of $D. As written above, it is not needed for 'systemctl disable'. But I am against removal of offline capabilities because they are not needed in 80% of use cases. Considering that in the meantime my similar patch [1] to systemd.bbclass got merged into meta-oe by Koen, who initially was against it, I guess this patch can finally get merged now, too. Crap, I missed the $D part, that's going to get reverted ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] avahi-systemd: drop postrm, use prerm instead
Koen Kooi k...@dominion.thruhere.net writes: Considering that in the meantime my similar patch [1] to systemd.bbclass got merged into meta-oe by Koen, who initially was against it, I guess this patch can finally get merged now, too. Crap, I missed the $D part, that's going to get reverted I think we can keep it when we enhance the systemctl script (systemd-systemctl-native) to ignore 'stop/start'. This will simplify the install scripts because the | if [ -z $D ]; then |systemctl stop ... | fi block can be replaced by a simple 'systemctl stop ...' Enrico ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] avahi-systemd: drop postrm, use prerm instead
Op 21 mei 2012, om 14:13 heeft Enrico Scholz het volgende geschreven: Koen Kooi k...@dominion.thruhere.net writes: Considering that in the meantime my similar patch [1] to systemd.bbclass got merged into meta-oe by Koen, who initially was against it, I guess this patch can finally get merged now, too. Crap, I missed the $D part, that's going to get reverted I think we can keep it when we enhance the systemctl script (systemd-systemctl-native) to ignore 'stop/start'. That won't work where you don't the have OE tree at hand. Worst case: it will call the native systemctl and break the host distro. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] avahi-systemd: drop postrm, use prerm instead
Koen Kooi k...@dominion.thruhere.net writes: Considering that in the meantime my similar patch [1] to systemd.bbclass got merged into meta-oe by Koen, who initially was against it, I guess this patch can finally get merged now, too. Crap, I missed the $D part, that's going to get reverted I think we can keep it when we enhance the systemctl script (systemd-systemctl-native) to ignore 'stop/start'. That won't work where you don't the have OE tree at hand. Is this case really supported? Lot of scripts depend on encapsulation by 'pseudo' and/or special wrapper programs. E.g. 'update-alternatives' must be the tool of the OE tree; the host utility will be used which does not understand $OPKG_OFFLINE_ROOT. Else, systemd-systemctl-native is sysrooted by every package inheriting 'systemd.bbclass' and available in every OE tree. Worst case: it will call the native systemctl and break the host distro. This would also be the case for the already unwrapped | systemctl enable service But again... this is not a problem because a custom systemctl script is installed. Enrico ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC][PATCH 00/14] mips64 support and sh4 support
On Mon, May 21, 2012 at 12:35 AM, Khem Raj raj.k...@gmail.com wrote:
This patchset adds required bits into metadata for having
mips64/n64 support. I have tested the core-image-sato and core-image-minimal
builds and boots on qemumips64 and runs gcc regression testsuite.
It needs linux-yocto-dev kernel for now which can be obtained from
And as an extra point on this, I have a full _3.4 recipe prep'd, but
vacation reared
it's ugly head. I'll send the changes out when I return (or sooner if
I sneak away
to a decent computer and internet connection :).
The series looks good to me, thanks Khem!
Bruce
poky-extra repo. Additionally systemd-image on angstrom-next builds and boots
fine on qemumips64 as well.
Additionally it also adds bits to have SH4 root file systems to be
able to built and again core-image-sato builds for sh4 however qemu
machine support is not yet done but root file sytem boots fine on
real hardware.
The images are tested on both eglibc and uclibc.
Any help in providing feedback or testing these patches is welcome.
I have tested them enough for over a month now.
The following changes since commit 326563d5a897ae2dba7cfd8d73579d3d979d72c8:
sstate.bbclass: Make sure we don't have an empty fixmepath file (2012-05-18
15:24:45 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib kraj/mips64
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=kraj/mips64
Khem Raj (14):
insane.bbclass: Add mips64{el} to known machines
site: Add mips64 eglibc and uclibc site files
gcc-4.6, gcc-4.7: Add support for building mips64 cross compiler
binutils: Default to n64 when configured for mips64
kernel-arch.bbclass: Map mips64{el} to mips KARCH
eglibc-2.15: Support mips64
libc-package: Add sh4 and mips64 to arch options
runqemu: Add qemush4 and qemumips64 knowledge
netbase: Add interface files for qemumips64 and qemush4
site/sh-common: Add missing caches variables to build glib-2.32
xserver-xorg: Fix build for mips64
tune-mips64.inc: Add new tune file for mips64 big-endian
qemumips64.conf: Add machine configuration for mips64(eb)
qemush4.conf: Add machine configuration for qemush4
meta/classes/insane.bbclass | 4 +
meta/classes/kernel-arch.bbclass | 2 +-
meta/classes/libc-package.bbclass | 3 +
meta/conf/machine/include/tune-mips64.inc | 3 +
meta/conf/machine/qemumips64.conf | 13 +++
meta/conf/machine/qemush4.conf | 13 +++
meta/recipes-core/eglibc/eglibc-locale.inc | 2 +-
meta/recipes-core/eglibc/eglibc_2.15.bb | 2 +-
.../netbase/netbase-4.47/qemumips64/interfaces | 8 ++
.../netbase/netbase-4.47/qemush4/interfaces | 8 ++
meta/recipes-core/netbase/netbase_4.47.bb | 4 +-
.../binutils/mips64-default-ld-emulation.patch | 49 +
meta/recipes-devtools/binutils/binutils_2.22.bb | 3 +-
meta/recipes-devtools/gcc/gcc-4.6.inc | 1 +
.../gcc/gcc-4.6/mips64-default-n64.patch | 32 ++
meta/recipes-devtools/gcc/gcc-4.7.inc | 1 +
.../gcc/gcc-4.7/mips64-default-n64.patch | 19
meta/recipes-devtools/gcc/gcc-configure-common.inc | 4 +
.../xorg-xserver/xserver-xorg-1.11.2.inc | 1 +
.../xserver-xorg-1.11.2/mips64-compiler.patch | 29 +
meta/site/mips64-linux | 82 +++
meta/site/mips64-linux-uclibc | 83 +++
meta/site/mips64el-linux | 82 +++
meta/site/mips64el-linux-uclibc | 108
meta/site/sh-common | 4 +
scripts/runqemu | 10 ++-
scripts/runqemu-internal | 35 ++-
27 files changed, 594 insertions(+), 11 deletions(-)
create mode 100644 meta/conf/machine/include/tune-mips64.inc
create mode 100644 meta/conf/machine/qemumips64.conf
create mode 100644 meta/conf/machine/qemush4.conf
create mode 100644
meta/recipes-core/netbase/netbase-4.47/qemumips64/interfaces
create mode 100644 meta/recipes-core/netbase/netbase-4.47/qemush4/interfaces
create mode 100644
meta/recipes-devtools/binutils/binutils/mips64-default-ld-emulation.patch
create mode 100644 meta/recipes-devtools/gcc/gcc-4.6/mips64-default-n64.patch
create mode 100644 meta/recipes-devtools/gcc/gcc-4.7/mips64-default-n64.patch
create mode 100644
meta/recipes-graphics/xorg-xserver/xserver-xorg-1.11.2/mips64-compiler.patch
create mode 100644 meta/site/mips64-linux
create mode 100644 meta/site/mips64-linux-uclibc
create mode 100644 meta/site/mips64el-linux
create mode 100644 meta/site/mips64el-linux-uclibc
--
1.7.5.4
Re: [OE-core] [oe-core] Add option to oe-buildenv-internal script to change bitbake location.
On 05/09/2012 01:03 PM, Marko Lindqvist wrote: On 9 May 2012 19:44, Philip Balister phi...@balister.org wrote: Having bitbake inside the oe-core is annoying to some people. This commit adds a second option to the oe-init-build-env script. Run like this: . ./oe-init-build-env ../build ../bitbake for example. Without the second option, the old behavior is preserved. Signed-off-by: Philip Balister phi...@balister.org Maybe you should update comment in oe-init-build-env describing typical use to contain this parameter. Richard, do you want me to se-send this with Marko's suggestions added? Philip ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core] Add option to oe-buildenv-internal script to change bitbake location.
On Mon, 2012-05-21 at 09:07 -0400, Philip Balister wrote: On 05/09/2012 01:03 PM, Marko Lindqvist wrote: On 9 May 2012 19:44, Philip Balister phi...@balister.org wrote: Having bitbake inside the oe-core is annoying to some people. This commit adds a second option to the oe-init-build-env script. Run like this: . ./oe-init-build-env ../build ../bitbake for example. Without the second option, the old behavior is preserved. Signed-off-by: Philip Balister phi...@balister.org Maybe you should update comment in oe-init-build-env describing typical use to contain this parameter. Richard, do you want me to se-send this with Marko's suggestions added? I'm happy to have a follow up patch, I did merge the original. It broke various assumptions being made by for example the autobuilder scripts so I had to add some other changes already. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core] Add option to oe-buildenv-internal script to change bitbake location.
On 05/21/2012 09:25 AM, Richard Purdie wrote: On Mon, 2012-05-21 at 09:07 -0400, Philip Balister wrote: On 05/09/2012 01:03 PM, Marko Lindqvist wrote: On 9 May 2012 19:44, Philip Balister phi...@balister.org wrote: Having bitbake inside the oe-core is annoying to some people. This commit adds a second option to the oe-init-build-env script. Run like this: . ./oe-init-build-env ../build ../bitbake for example. Without the second option, the old behavior is preserved. Signed-off-by: Philip Balister phi...@balister.org Maybe you should update comment in oe-init-build-env describing typical use to contain this parameter. Richard, do you want me to se-send this with Marko's suggestions added? I'm happy to have a follow up patch, I did merge the original. It broke various assumptions being made by for example the autobuilder scripts so I had to add some other changes already. Thanks. I'm curious how it could break things since it should not have had any effect unless a second argument was present. Philip ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC v1 1/1] Reorder and -dev
On 05/21/2012 03:57 AM, Koen Kooi wrote:
Op 21 mei 2012, om 12:48 heeft Otavio Salvador het volgende geschreven:
On Mon, May 21, 2012 at 3:53 AM, Martin Jansamartin.ja...@gmail.com wrote:
the rest looks ok, but I'm pretty scared from such changes, does your
buildhistory diffs show just *-config file moves or something else too?
It would be nice if some images could be build before and after the
patch and check before proposing this for merging.
Indeed, run the buildhistory output through Pauls analysis tool and share the
results.
Yes, I plan too once I get closer to done, I know it will move more than
the -config files, biggest issue I have seen so far are extensions and
modules that might live in ${libdir}/${BPN}/...*.so vs *.so.* I believe
that most of these .so libraries live in the standard base package, not
the -dev package.
Sau!
regards,
Koen
___
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] [oe-core] Add option to oe-buildenv-internal script to change bitbake location.
On Mon, 2012-05-21 at 09:41 -0400, Philip Balister wrote: On 05/21/2012 09:25 AM, Richard Purdie wrote: On Mon, 2012-05-21 at 09:07 -0400, Philip Balister wrote: On 05/09/2012 01:03 PM, Marko Lindqvist wrote: On 9 May 2012 19:44, Philip Balister phi...@balister.org wrote: Having bitbake inside the oe-core is annoying to some people. This commit adds a second option to the oe-init-build-env script. Run like this: . ./oe-init-build-env ../build ../bitbake for example. Without the second option, the old behavior is preserved. Signed-off-by: Philip Balister phi...@balister.org Maybe you should update comment in oe-init-build-env describing typical use to contain this parameter. Richard, do you want me to se-send this with Marko's suggestions added? I'm happy to have a follow up patch, I did merge the original. It broke various assumptions being made by for example the autobuilder scripts so I had to add some other changes already. Thanks. I'm curious how it could break things since it should not have had any effect unless a second argument was present. Think about another script sourcing the internal build environment script. You'd then see that script's second option... Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC][PATCH 00/14] mips64 support and sh4 support
On Monday, May 21, 2012, Richard Purdie wrote:
On Sun, 2012-05-20 at 20:35 -0700, Khem Raj wrote:
This patchset adds required bits into metadata for having
mips64/n64 support. I have tested the core-image-sato and
core-image-minimal
builds and boots on qemumips64 and runs gcc regression testsuite.
It needs linux-yocto-dev kernel for now which can be obtained from
poky-extra repo. Additionally systemd-image on angstrom-next builds and
boots
fine on qemumips64 as well.
Additionally it also adds bits to have SH4 root file systems to be
able to built and again core-image-sato builds for sh4 however qemu
machine support is not yet done but root file sytem boots fine on
real hardware.
The images are tested on both eglibc and uclibc.
Any help in providing feedback or testing these patches is welcome.
I have tested them enough for over a month now.
The following changes since commit
326563d5a897ae2dba7cfd8d73579d3d979d72c8:
sstate.bbclass: Make sure we don't have an empty fixmepath file
(2012-05-18 15:24:45 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib kraj/mips64
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=kraj/mips64
Khem Raj (14):
insane.bbclass: Add mips64{el} to known machines
site: Add mips64 eglibc and uclibc site files
gcc-4.6, gcc-4.7: Add support for building mips64 cross compiler
binutils: Default to n64 when configured for mips64
kernel-arch.bbclass: Map mips64{el} to mips KARCH
eglibc-2.15: Support mips64
libc-package: Add sh4 and mips64 to arch options
runqemu: Add qemush4 and qemumips64 knowledge
netbase: Add interface files for qemumips64 and qemush4
site/sh-common: Add missing caches variables to build glib-2.32
xserver-xorg: Fix build for mips64
tune-mips64.inc: Add new tune file for mips64 big-endian
qemumips64.conf: Add machine configuration for mips64(eb)
qemush4.conf: Add machine configuration for qemush4
We need to figure out what it means to add new qemu machines like this
to OE-Core. I'm not against it however I can't offer the Yocto Project's
resources to test them at this point as we're haven't budgeted for it.
Yes absolutely, in another version Actually I have these machines in a
separate later
Called meta-qemuextra may be such a layer would make sense ?
The above patches make sense regardless so I've merged them except the
final two machine files. I'd like to hold off adding those until the
system builds and runs with our default kernel and qemu recipes.
Hopefully this lets you develop without having a huge queue of patches.
In the meantime we need to figure out the resource concern for testing.
Is there a commercial interest in these new machines from anyone who
could perhaps help with the resource issue?
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org javascript:;
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
[OE-core] [PATCH] libnss-mdns: fix postinst scripts
* On upgrade, postinst ocassionally returned 1, so use a
conditional instead of .
* Use sed patterns in order to make it work more generally.
Signed-off-by: Andreas Oberritter o...@opendreambox.org
---
.../libnss-mdns/libnss-mdns_0.10.bb| 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/meta/recipes-connectivity/libnss-mdns/libnss-mdns_0.10.bb
b/meta/recipes-connectivity/libnss-mdns/libnss-mdns_0.10.bb
index 8770714..a1f2f9a 100644
--- a/meta/recipes-connectivity/libnss-mdns/libnss-mdns_0.10.bb
+++ b/meta/recipes-connectivity/libnss-mdns/libnss-mdns_0.10.bb
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM =
file://LICENSE;md5=2d5025d4aa3495befef8f17206a5b0a1
DEPENDS = avahi
RDEPENDS_${PN} = avahi-daemon
-PR = r4
+PR = r5
SRC_URI = http://0pointer.de/lennart/projects/nss-mdns/nss-mdns-${PV}.tar.gz;
@@ -23,15 +23,14 @@ DEBIANNAME_${PN} = libnss-mdns
EXTRA_OECONF = --libdir=${base_libdir} --disable-lynx --enable-avahi
-# TODO: pattern based configuration update
pkg_postinst_${PN} () {
- cat $D/etc/nsswitch.conf | grep hosts:\s*files dns$ /dev/null {
- sed -i 's/hosts:\s*files dns/ mdns4/' $D/etc/nsswitch.conf
- }
+if ! grep -q '^hosts:.*\mdns4\' $D/etc/nsswitch.conf; then
+ sed -e 's/^hosts:.*/ mdns4/' -i $D/etc/nsswitch.conf
+fi
}
pkg_prerm_${PN} () {
- cat /etc/nsswitch.conf | grep hosts:\s*files dns mdns4$ /dev/null
{
- sed -i 's/\(hosts:\s*files dns\) mdns4*/\1/' /etc/nsswitch.conf
- }
+if grep -q '^hosts:.*\mdns4\' /etc/nsswitch.conf; then
+ sed -e '/^hosts:/s/\s\mdns4\//' -i /etc/nsswitch.conf
+fi
}
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC v1 0/1] Reorder ${PN} and ${PN}-dev
On 5/21/12 1:42 AM, Saul Wold wrote:
This RFC is the first pass at reordering the above 2 items in
the PACKAGES list. This is in part an out cropping of the bug
#2367 (https://bugzilla.yoctoproject.org/show_bug.cgi?id=2367),
which show the miss packaged pcap-config file.
I've often wondered why the order is the way it is. If I were to do this from
scratch, I'd move the ${PN} item to last in the default order. Have you
considered this more radical approach, that would then allow all of the default
splits to occur before the ${PN} processing. (It might also allow the ${PN} to
simply be a /* instead of more complex rules.)
--Mark
A number of the changes below are PR bumps since I also changed
the contents of binconfig.bbclass (which would really go away in
favor of .pc files, but we need a step-wise approach.)
This change set is still evolving, I am using the buildhistory
to compare the results and at this time most of the changes are
correct. The major difference is that it requires more specific
enumeration of files, especially when delivered to /usr/lib/${BPN}
And yes, I have thought about how I can break this up, but I am not
sure it can be since once I change the bitbake.conf, numerous erros
and warnings are created.
This will most likley require some changes in meta-oe and other layers.
Comments suggested, improvemts always welcome!
Sau!
The following changes since commit 326563d5a897ae2dba7cfd8d73579d3d979d72c8:
sstate.bbclass: Make sure we don't have an empty fixmepath file (2012-05-18
15:24:45 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib sgw/pkg-reorder
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/pkg-reorder
Saul Wold (1):
Reorder and -dev
meta/classes/binconfig.bbclass |2 ++
meta/conf/bitbake.conf |8 +---
meta/recipes-bsp/pm-utils/pm-utils_1.4.1.bb| 10 ++
meta/recipes-connectivity/libpcap/libpcap.inc |2 +-
meta/recipes-core/eglibc/eglibc-package.inc|2 +-
meta/recipes-core/eglibc/eglibc_2.15.bb|2 +-
meta/recipes-core/gettext/gettext_0.16.1.bb|3 ++-
meta/recipes-core/gettext/gettext_0.18.1.1.bb |4 +++-
meta/recipes-core/libxml/libxml2.inc |2 +-
meta/recipes-core/ncurses/ncurses.inc |2 +-
meta/recipes-extended/cups/cups14.inc |1 +
meta/recipes-extended/cups/cups_1.4.6.bb |2 +-
meta/recipes-extended/groff/groff_1.20.1.bb|4 +++-
meta/recipes-extended/slang/slang_2.2.4.bb |4 ++--
meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb | 14 ++
meta/recipes-gnome/gthumb/gthumb_2.12.4.bb | 12
meta/recipes-graphics/directfb/directfb_1.4.15.bb |2 +-
meta/recipes-graphics/freetype/freetype_2.4.8.bb |5 +
meta/recipes-graphics/libsdl/libsdl_1.2.15.bb |2 +-
meta/recipes-multimedia/alsa/alsa-lib_1.0.25.bb|6 --
meta/recipes-multimedia/libpng/libpng_1.2.49.bb|4 +---
meta/recipes-support/apr/apr-util_1.4.1.bb |2 +-
meta/recipes-support/apr/apr_1.4.6.bb |2 +-
meta/recipes-support/curl/curl_7.24.0.bb |2 +-
meta/recipes-support/db/db_5.1.19.bb |1 +
meta/recipes-support/gnutls/gnutls.inc |5 ++---
meta/recipes-support/gnutls/libtasn1_2.12.bb |2 +-
meta/recipes-support/gpgme/gpgme_1.3.1.bb |5 ++---
meta/recipes-support/icu/icu-3.6.inc |2 ++
meta/recipes-support/icu/icu_3.6.bb|2 +-
meta/recipes-support/libassuan/libassuan_2.0.3.bb |1 +
meta/recipes-support/libgcrypt/libgcrypt.inc |4
.../libgpg-error/libgpg-error_1.10.bb |6 +-
meta/recipes-support/libksba/libksba_1.2.0.bb |1 +
meta/recipes-support/libpcre/libpcre_8.21.bb |5 +
meta/recipes-support/libproxy/libproxy_0.4.7.bb|3 ++-
meta/recipes-support/libusb/libusb-compat_0.1.3.bb |4 +---
meta/recipes-support/libxslt/libxslt_1.1.26.bb |2 +-
meta/recipes-support/neon/neon_0.29.6.bb |2 +-
meta/recipes-support/pth/pth_2.0.7.bb |5 +
meta/recipes-support/taglib/taglib_1.6.3.bb|3 +--
41 files changed, 83 insertions(+), 69 deletions(-)
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC][PATCH 00/14] mips64 support and sh4 support
On 5/21/12 3:21 AM, Richard Purdie wrote: On Sun, 2012-05-20 at 20:35 -0700, Khem Raj wrote: This patchset adds required bits into metadata for having mips64/n64 support. I have tested the core-image-sato and core-image-minimal builds and boots on qemumips64 and runs gcc regression testsuite. It needs linux-yocto-dev kernel for now which can be obtained from poky-extra repo. Additionally systemd-image on angstrom-next builds and boots fine on qemumips64 as well. We need to figure out what it means to add new qemu machines like this to OE-Core. I'm not against it however I can't offer the Yocto Project's resources to test them at this point as we're haven't budgeted for it. The above patches make sense regardless so I've merged them except the final two machine files. I'd like to hold off adding those until the system builds and runs with our default kernel and qemu recipes. Hopefully this lets you develop without having a huge queue of patches. In the meantime we need to figure out the resource concern for testing. Is there a commercial interest in these new machines from anyone who could perhaps help with the resource issue? From a commercial interest standpoint, I don't know if there is any with SH4. For the company I work for, SH has been so minor that we likely wouldn't consider it significant enough to spend effort on. However, MIPS64 is completely different. There are numerous MIPS64 processors and such, and I strongly advocate OE (and Yocto Project) support for MIPS64. One thing to note, it should be possible to use the MIPS64 QEMU to replace the qemumips configuration already in OE-core. Then the qemumips64 can be used to validation, mips (o32), mips64 (n64) and eventually mips64 (n32) binaries once they are available. This would also be a good target to validation complex multilib sets on. --Mark 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] [RFC v1 0/1] Reorder ${PN} and ${PN}-dev
On Mon, May 21, 2012 at 8:47 AM, Mark Hatle mark.ha...@windriver.com wrote:
On 5/21/12 1:42 AM, Saul Wold wrote:
This RFC is the first pass at reordering the above 2 items in
the PACKAGES list. This is in part an out cropping of the bug
#2367 (https://bugzilla.yoctoproject.org/show_bug.cgi?id=2367),
which show the miss packaged pcap-config file.
I've often wondered why the order is the way it is. If I were to do this
from scratch, I'd move the ${PN} item to last in the default order. Have
you considered this more radical approach, that would then allow all of the
default splits to occur before the ${PN} processing. (It might also allow
the ${PN} to simply be a /* instead of more complex rules.)
This would be quite nice, if we could pull it off without breaking
anything horribly.
--
Christopher Larson
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC v1 0/1] Reorder ${PN} and ${PN}-dev
On 05/21/2012 08:54 AM, Chris Larson wrote:
On Mon, May 21, 2012 at 8:47 AM, Mark Hatlemark.ha...@windriver.com wrote:
On 5/21/12 1:42 AM, Saul Wold wrote:
This RFC is the first pass at reordering the above 2 items in
the PACKAGES list. This is in part an out cropping of the bug
#2367 (https://bugzilla.yoctoproject.org/show_bug.cgi?id=2367),
which show the miss packaged pcap-config file.
I've often wondered why the order is the way it is. If I were to do this
from scratch, I'd move the ${PN} item to last in the default order. Have
you considered this more radical approach, that would then allow all of the
default splits to occur before the ${PN} processing. (It might also allow
the ${PN} to simply be a /* instead of more complex rules.)
This would be quite nice, if we could pull it off without breaking
anything horribly.
I will give it a try and post a buildhistory repo in a couple of days,
it will be alot to compare!
Sau!
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC v1 0/1] Reorder ${PN} and ${PN}-dev
On Mon, 2012-05-21 at 08:54 -0700, Chris Larson wrote:
On Mon, May 21, 2012 at 8:47 AM, Mark Hatle mark.ha...@windriver.com wrote:
On 5/21/12 1:42 AM, Saul Wold wrote:
This RFC is the first pass at reordering the above 2 items in
the PACKAGES list. This is in part an out cropping of the bug
#2367 (https://bugzilla.yoctoproject.org/show_bug.cgi?id=2367),
which show the miss packaged pcap-config file.
I've often wondered why the order is the way it is. If I were to do this
from scratch, I'd move the ${PN} item to last in the default order. Have
you considered this more radical approach, that would then allow all of the
default splits to occur before the ${PN} processing. (It might also allow
the ${PN} to simply be a /* instead of more complex rules.)
This would be quite nice, if we could pull it off without breaking
anything horribly.
-dev is likely the nastiest to move, the other two defaults aafter PN
are -locale and -doc, neither of which should present as much of a
challenge so we can probably move those. Its not likely to gain much
either though as we don't split the files in those directories like we
do with -dev files.
I'm not sure a '*' matching for PN is the most desirable default though,
in some ways I like the fact we have to specifically think about the
exceptions to the default rules...
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] netbase: merge init script updates from upstream
* Read /proc/mounts only once.
* Support many more network filesystem types.
* Remaining differences to netbase 4.47:
- Uses the mountvirtfs keyword instead of mountkernfs
- Doesn't use lsb functions
- Doesn't print a warning if /etc/network/options exists
- Doesn't use --exclude parameter for ifup, because
busybox doesn't support it.
Signed-off-by: Andreas Oberritter o...@opendreambox.org
---
meta/recipes-core/netbase/netbase-4.47/init | 101 ++-
meta/recipes-core/netbase/netbase_4.47.bb |2 +-
2 files changed, 70 insertions(+), 33 deletions(-)
diff --git a/meta/recipes-core/netbase/netbase-4.47/init
b/meta/recipes-core/netbase/netbase-4.47/init
index 8a67e1c..bace9df 100644
--- a/meta/recipes-core/netbase/netbase-4.47/init
+++ b/meta/recipes-core/netbase/netbase-4.47/init
@@ -1,52 +1,89 @@
-#!/bin/sh
-#
+#!/bin/sh -e
### BEGIN INIT INFO
# Provides: networking
-# Required-Start:$local_fs mountvirtfs
+# Required-Start:mountvirtfs $local_fs
# Required-Stop: $local_fs
+# Should-Start: ifupdown
+# Should-Stop: ifupdown
# Default-Start: S
# Default-Stop: 0 6
-# Short-Description: Raise network interfaces and configure them
+# Short-Description: Raise network interfaces.
### END INIT INFO
-PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
+PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
-if ! [ -x /sbin/ifup ]; then
-exit 0
-fi
+[ -x /sbin/ifup ] || exit 0
+
+check_network_file_systems() {
+[ -e /proc/mounts ] || return 0
+
+if [ -e /etc/iscsi/iscsi.initramfs ]; then
+ echo not deconfiguring network interfaces: iSCSI root is mounted.
+ exit 0
+fi
+
+exec 90 /proc/mounts
+while read DEV MTPT FSTYPE REST; do
+ case $DEV in
+ /dev/nbd*|/dev/nd[a-z]*|/dev/etherd/e*)
+ echo not deconfiguring network interfaces: network devices still
mounted.
+ exit 0
+ ;;
+ esac
+ case $FSTYPE in
+
nfs|nfs4|smbfs|ncp|ncpfs|cifs|coda|ocfs2|gfs|pvfs|pvfs2|fuse.httpfs|fuse.curlftpfs)
+ echo not deconfiguring network interfaces: network file systems
still mounted.
+ exit 0
+ ;;
+ esac
+done
+exec 09 9-
+}
+
+check_network_swap() {
+[ -e /proc/swaps ] || return 0
+
+exec 90 /proc/swaps
+while read DEV MTPT FSTYPE REST; do
+ case $DEV in
+ /dev/nbd*|/dev/nd[a-z]*|/dev/etherd/e*)
+ echo not deconfiguring network interfaces: network swap still
mounted.
+ exit 0
+ ;;
+ esac
+done
+exec 09 9-
+}
case $1 in
-start)
-echo -n Configuring network interfaces...
-ifup -a
+start)
+ echo -n Configuring network interfaces...
+ ifup -a
echo done.
;;
-stop)
-if sed -n 's/^[^ ]* \([^ ]*\) \([^ ]*\) .*$/\1 \2/p' /proc/mounts |
- grep -q ^/ nfs$; then
-echo NOT deconfiguring network interfaces: / is an NFS mount
-elif sed -n 's/^[^ ]* \([^ ]*\) \([^ ]*\) .*$/\1 \2/p' /proc/mounts |
- grep -q ^/ smbfs$; then
-echo NOT deconfiguring network interfaces: / is an SMB mount
- elif sed -n 's/^[^ ]* \([^ ]*\) \([^ ]*\) .*$/\2/p' /proc/mounts |
- grep -qE '^(nfs|smbfs|ncp|coda)$'; then
-echo NOT deconfiguring network interfaces: network shares still
mounted.
-else
-echo -n Deconfiguring network interfaces...
-ifdown -a
- echo done.
-fi
+
+stop)
+ check_network_file_systems
+ check_network_swap
+
+ echo -n Deconfiguring network interfaces...
+ ifdown -a
+ echo done.
;;
-force-reload|restart)
-echo -n Reconfiguring network interfaces...
-ifdown -a
-ifup -a
+
+force-reload|restart)
+ echo Running $0 $1 is deprecated because it may not enable again some
interfaces
+ echo Reconfiguring network interfaces...
+ ifdown -a || true
+ ifup -a
echo done.
;;
-*)
- echo Usage: /etc/init.d/networking {start|stop|restart|force-reload}
+
+*)
+ echo Usage: /etc/init.d/networking {start|stop}
exit 1
;;
esac
exit 0
+
diff --git a/meta/recipes-core/netbase/netbase_4.47.bb
b/meta/recipes-core/netbase/netbase_4.47.bb
index a1462f8..f84e9a4 100644
--- a/meta/recipes-core/netbase/netbase_4.47.bb
+++ b/meta/recipes-core/netbase/netbase_4.47.bb
@@ -4,7 +4,7 @@ HOMEPAGE = http://packages.debian.org/netbase;
SECTION = base
LICENSE = GPLv2
LIC_FILES_CHKSUM =
file://debian/copyright;md5=3dd6192d306f582dee7687da3d8748ab
-PR = r1
+PR = r2
inherit update-rc.d
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] gcc-4.7: Add knowledge about arm hf dynamic loader
Signed-off-by: Khem Raj raj.k...@gmail.com
---
meta/recipes-devtools/gcc/gcc-4.7.inc |1 +
.../gcc/gcc-4.7/arm-hard-float-loader.patch| 48
2 files changed, 49 insertions(+), 0 deletions(-)
create mode 100644
meta/recipes-devtools/gcc/gcc-4.7/arm-hard-float-loader.patch
diff --git a/meta/recipes-devtools/gcc/gcc-4.7.inc
b/meta/recipes-devtools/gcc/gcc-4.7.inc
index efd166c..0321776 100644
--- a/meta/recipes-devtools/gcc/gcc-4.7.inc
+++ b/meta/recipes-devtools/gcc/gcc-4.7.inc
@@ -65,6 +65,7 @@ SRC_URI =
svn://gcc.gnu.org/svn/gcc/branches;module=${BRANCH};proto=http \
file://libgcc-sjlj-check.patch \
file://cpp-honor-sysroot.patch \
file://mips64-default-n64.patch \
+ file://arm-hard-float-loader.patch \
S = ${TMPDIR}/work-shared/gcc-${PV}-${PR}/${BRANCH}
diff --git a/meta/recipes-devtools/gcc/gcc-4.7/arm-hard-float-loader.patch
b/meta/recipes-devtools/gcc/gcc-4.7/arm-hard-float-loader.patch
new file mode 100644
index 000..dfa0d19
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc-4.7/arm-hard-float-loader.patch
@@ -0,0 +1,48 @@
+This patch is still being discussed by probably is almost
+final version. We add the OE notion of multilib on top
+
+Upstream-Status: Backport [ adapted ]
+
+Signed-off-by: Khem Raj raj.k...@gmail.com
+
+Index: gcc-4_7-branch/gcc/config/arm/linux-eabi.h
+===
+--- gcc-4_7-branch.orig/gcc/config/arm/linux-eabi.h2012-04-30
15:28:31.891863845 -0700
gcc-4_7-branch/gcc/config/arm/linux-eabi.h 2012-04-30 15:37:11.531888994
-0700
+@@ -32,7 +32,8 @@
+ while (false)
+
+ /* We default to a soft-float ABI so that binaries can run on all
+- target hardware. */
++ target hardware. If you override this to use the hard-float ABI then
++ change the setting of GLIBC_DYNAMIC_LINKER_DEFAULT as well. */
+ #undef TARGET_DEFAULT_FLOAT_ABI
+ #define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_SOFT
+
+@@ -59,10 +60,23 @@
+ #undef SUBTARGET_EXTRA_LINK_SPEC
+ #define SUBTARGET_EXTRA_LINK_SPEC -m TARGET_LINKER_EMULATION
+
+-/* Use ld-linux.so.3 so that it will be possible to run classic
+- GNU/Linux binaries on an EABI system. */
++/* GNU/Linux on ARM currently supports three dynamic linkers:
++ - ld-linux.so.2 - for the legacy ABI
++ - ld-linux.so.3 - for the EABI-derived soft-float ABI
++ - ld-linux-armhf.so.3 - for the EABI-derived hard-float ABI.
++ All the dynamic linkers live in /lib.
++ We default to soft-float, but this can be overridden by changing both
++ GLIBC_DYNAMIC_LINKER_DEFAULT and TARGET_DEFAULT_FLOAT_ABI. */
++
+ #undef GLIBC_DYNAMIC_LINKER
+-#define GLIBC_DYNAMIC_LINKER SYSTEMLIBS_DIR ld-linux.so.3
++#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT SYSTEMLIBS_DIR ld-linux.so.3
++#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT SYSTEMLIBS_DIR ld-linux-armhf.so.3
++#define GLIBC_DYNAMIC_LINKER_DEFAULT GLIBC_DYNAMIC_LINKER_SOFT_FLOAT
++
++ #define GLIBC_DYNAMIC_LINKER \
++%{mfloat-abi=hard: GLIBC_DYNAMIC_LINKER_HARD_FLOAT } \
++ %{mfloat-abi=soft*: GLIBC_DYNAMIC_LINKER_SOFT_FLOAT } \
++ %{!mfloat-abi=*: GLIBC_DYNAMIC_LINKER_DEFAULT }
+
+ /* At this point, bpabi.h will have clobbered LINK_SPEC. We want to
+use the GNU/Linux version, not the generic BPABI version. */
--
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/3] ARM hf support
This patchset adds the newly added hard float convention for naming the dynamic linker. We have a tune feature to denote hf calling convention already therefore this patch uses that feature to decide on configuring the toolchain to be soft float or hard-float call conventions by default. The following changes since commit e6333825c3482a559a0c0499e17f8f48d3042ddf: tune-mips64.inc: Add new tune file for mips64 big-endian (2012-05-20 20:24:37 -0700) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib kraj/armhf http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=kraj/armhf Khem Raj (3): gcc-4.7: Add knowledge about arm hf dynamic loader eglibc: Add ARM hf dynamic linker support gcc: Grok for callconvention-hard to enable hard float .../eglibc/eglibc-2.15/add_HAVE_ARM_PCS_VFP.patch | 28 ++ .../eglibc/eglibc-2.15/ldso_arm_hf_support.patch | 338 meta/recipes-core/eglibc/eglibc_2.15.bb|4 +- meta/recipes-devtools/gcc/gcc-4.7.inc |1 + .../gcc/gcc-4.7/arm-hard-float-loader.patch| 48 +++ meta/recipes-devtools/gcc/gcc-common.inc |2 + 6 files changed, 420 insertions(+), 1 deletions(-) create mode 100644 meta/recipes-core/eglibc/eglibc-2.15/add_HAVE_ARM_PCS_VFP.patch create mode 100644 meta/recipes-core/eglibc/eglibc-2.15/ldso_arm_hf_support.patch create mode 100644 meta/recipes-devtools/gcc/gcc-4.7/arm-hard-float-loader.patch -- 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 2/3] eglibc: Add ARM hf dynamic linker support
The work is done in glibc upstream we backport the relevant patches Signed-off-by: Khem Raj raj.k...@gmail.com --- .../eglibc/eglibc-2.15/add_HAVE_ARM_PCS_VFP.patch | 28 ++ .../eglibc/eglibc-2.15/ldso_arm_hf_support.patch | 338 meta/recipes-core/eglibc/eglibc_2.15.bb|4 +- 3 files changed, 369 insertions(+), 1 deletions(-) create mode 100644 meta/recipes-core/eglibc/eglibc-2.15/add_HAVE_ARM_PCS_VFP.patch create mode 100644 meta/recipes-core/eglibc/eglibc-2.15/ldso_arm_hf_support.patch diff --git a/meta/recipes-core/eglibc/eglibc-2.15/add_HAVE_ARM_PCS_VFP.patch b/meta/recipes-core/eglibc/eglibc-2.15/add_HAVE_ARM_PCS_VFP.patch new file mode 100644 index 000..0f95c2f --- /dev/null +++ b/meta/recipes-core/eglibc/eglibc-2.15/add_HAVE_ARM_PCS_VFP.patch @@ -0,0 +1,28 @@ +From: Carlos O'Donell carlos_odon...@mentor.com +Date: Mon, 7 May 2012 20:04:41 + (-0400) +Subject: ARM: Define HAVE_ARM_PCS_VFP in config.h. +X-Git-Url: http://sourceware.org/git/?p=glibc.git;a=commitdiff_plain;h=6a43ec980c5a0500149ef37d4854eac0e270da6f;hp=05c2c9618f583ea4acd69b3fe5ae2a2922dd2ddc + +ARM: Define HAVE_ARM_PCS_VFP in config.h. + +If the compiler and flags would select the hard-float ABI +then the ARM configure fragment will set HAVE_ARM_PCS_VFP. +This is later used by the ARM shlib-versions to select +the appropriately named dynamic linker. +--- + +Upstream-Status: Backport +-Khem + +Index: libc/config.h.in +=== +--- libc.orig/config.h.in 2012-01-04 22:06:28.0 -0800 libc/config.h.in 2012-05-08 11:25:56.581079069 -0700 +@@ -233,4 +233,7 @@ + + #define HAVE_REGEX 1 + ++/* The ARM hard-float ABI is being used. */ ++#undef HAVE_ARM_PCS_VFP ++ + #endif diff --git a/meta/recipes-core/eglibc/eglibc-2.15/ldso_arm_hf_support.patch b/meta/recipes-core/eglibc/eglibc-2.15/ldso_arm_hf_support.patch new file mode 100644 index 000..7a53da6 --- /dev/null +++ b/meta/recipes-core/eglibc/eglibc-2.15/ldso_arm_hf_support.patch @@ -0,0 +1,338 @@ +From d3b36017d43af570ca7f79e711749dd4ade76979 Mon Sep 17 00:00:00 2001 +From: Carlos O'Donell carlos_odon...@mentor.com +Date: Mon, 7 May 2012 22:14:44 -0400 +Subject: [PATCH] ARM: Use /lib/ld-linux-armhf.so.3 for the hard-float ABI. + +The hard-float ABI will now use /lib/ld-linux-armhf.so.3. +We detect the use of the hard-float ABI and select the +appropriate dynamic linker name. You must have a new or +patched compiler which also uses the new dynamic loader +name when the hard-float ABI is selected. +--- + ChangeLog.arm |8 ++ + sysdeps/arm/configure | 184 + sysdeps/arm/configure.in | 17 + sysdeps/arm/shlib-versions |8 ++- + 4 files changed, 216 insertions(+), 1 deletions(-) + mode change 100644 = 100755 sysdeps/arm/configure + +Upstream-Status: Backport +-Khem + +Index: libc/ports/sysdeps/arm/configure.in +=== +--- libc.orig/ports/sysdeps/arm/configure.in 2012-05-08 11:42:59.161128560 -0700 libc/ports/sysdeps/arm/configure.in2012-05-08 11:43:29.373130066 -0700 +@@ -18,3 +18,20 @@ + if test $libc_cv_asm_cfi_directive_sections != yes; then + AC_MSG_ERROR([need .cfi_sections in this configuration]) + fi ++ ++# We check to see if the compiler and flags are ++# selecting the hard-float ABI and if they are then ++# we set libc_cv_arm_pcs_vfp to yes which causes ++# HAVE_ARM_PCS_VFP to be defined in config.h and ++# in include/libc-symbols.h and thus available to ++# shlib-versions to select the appropriate name for ++# the dynamic linker via %ifdef. ++AC_CACHE_CHECK([whether the compiler is using the ARM hard-float ABI], ++ [libc_cv_arm_pcs_vfp], ++ [AC_EGREP_CPP(yes,[#ifdef __ARM_PCS_VFP ++ yes ++ #endif ++ ], libc_cv_arm_pcs_vfp=yes, libc_cv_arm_pcs_vfp=no)]) ++if test $libc_cv_arm_pcs_vfp = yes; then ++ AC_DEFINE(HAVE_ARM_PCS_VFP) ++fi +Index: libc/ports/sysdeps/arm/shlib-versions +=== +--- libc.orig/ports/sysdeps/arm/shlib-versions 2012-05-08 11:42:59.145128546 -0700 libc/ports/sysdeps/arm/shlib-versions 2012-05-08 11:43:29.409130022 -0700 +@@ -1,4 +1,10 @@ + arm.*-.*-linux-gnueabi.* DEFAULT GLIBC_2.4 + +-arm.*-.*-linux-gnueabi.* ld=ld-linux.so.3 ++%ifdef HAVE_ARM_PCS_VFP ++# The EABI-derived hard-float ABI uses a new dynamic linker. ++arm.*-.*-linux-gnueabi.* ld=ld-linux-armhf.so.3 ++%else ++# The EABI-derived soft-float ABI continues to use ld-linux.so.3. ++arm.*-.*-linux-gnueabi.* ld=ld-linux.so.3 ++%endif + arm.*-.*-linux.* ld=ld-linux.so.2 +Index: libc/ports/sysdeps/arm/configure +=== +--- libc.orig/ports/sysdeps/arm/configure 2012-05-08 11:43:46.437130836 -0700
[OE-core] [PATCH 3/3] gcc: Grok for callconvention-hard to enable hard float
If callconvention-hard is set then we build gcc defaulting
to hard-float ABI
Signed-off-by: Khem Raj raj.k...@gmail.com
---
meta/recipes-devtools/gcc/gcc-common.inc |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-devtools/gcc/gcc-common.inc
b/meta/recipes-devtools/gcc/gcc-common.inc
index f550aab..c479403 100644
--- a/meta/recipes-devtools/gcc/gcc-common.inc
+++ b/meta/recipes-devtools/gcc/gcc-common.inc
@@ -10,6 +10,8 @@ inherit autotools gettext
FILESDIR = ${@os.path.dirname(d.getVar('FILE',1))}/gcc-${PV}
def get_gcc_fpu_setting(bb, d):
+if d.getVar('ARMPKGSFX_EABI', True) is hf:
+return --with-float=hard
if d.getVar('TARGET_FPU', True) in [ 'soft' ]:
return --with-float=soft
if d.getVar('TARGET_FPU', True) in [ 'ppc-efd' ]:
--
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 1/2] distutils.bbclass: don't delete .pyo files
* Deleting .pyo files causes them to get compiled on the target.
* First boot gets *really* slow for python based projects.
* No space gets saved on the target.
* The package manager doesn't know about the files and
therefore fails to uninstall them, occupying space and causing
uninstalled python scripts to remain executable.
* It's inconsistent, because python itself and autotools based
projects already ship .pyo files.
* Probably .pyo files were deleted because .pyc files were
available earlier, but this has changed and OE-Core's python
now only generates optimized .pyo files. Deletion of .pyo was
introduced in 2008, python/04-default-is-optimized.patch
was introduced in 2009.
Signed-off-by: Andreas Oberritter o...@opendreambox.org
---
meta/classes/distutils.bbclass |4
1 file changed, 4 deletions(-)
diff --git a/meta/classes/distutils.bbclass b/meta/classes/distutils.bbclass
index 18ae805..bcddf8d 100644
--- a/meta/classes/distutils.bbclass
+++ b/meta/classes/distutils.bbclass
@@ -65,10 +65,6 @@ distutils_do_install() {
if test -e ${D}${datadir}/share; then
mv -f ${D}${datadir}/share/* ${D}${datadir}/
fi
-
-# These are generated files, on really slow systems the storage/speed
trade off
-# might be worth it, but in general it isn't
-find ${D}${libdir}/${PYTHON_DIR}/site-packages -iname '*.pyo' -exec rm
{} \;
}
EXPORT_FUNCTIONS do_compile do_install
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] python: bump PR of packages after update of distutils.bbclass
* Bump every recipe inheriting distutils or setuptools and
not overriding do_install without calling distutils_do_install.
Signed-off-by: Andreas Oberritter o...@opendreambox.org
---
.../python/python-argparse_1.2.1.bb|2 +-
.../python/python-imaging_1.1.7.bb |2 +-
.../python/python-pycurl_7.19.0.bb |2 +-
meta/recipes-devtools/python/python-pyrex_0.9.9.bb |2 +-
meta/recipes-devtools/python/python-scons_2.1.0.bb |2 +-
.../python/python-setuptools_0.6c11.bb |2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/meta/recipes-devtools/python/python-argparse_1.2.1.bb
b/meta/recipes-devtools/python/python-argparse_1.2.1.bb
index 789cee1..7c15575 100644
--- a/meta/recipes-devtools/python/python-argparse_1.2.1.bb
+++ b/meta/recipes-devtools/python/python-argparse_1.2.1.bb
@@ -3,7 +3,7 @@ SECTION = devel/python
LICENSE = PSF
LIC_FILES_CHKSUM = file://LICENSE.txt;md5=09d08bb5b7047e2688ea3faad6408aa8
SRCNAME = argparse
-PR = r1
+PR = r2
SRC_URI = http://argparse.googlecode.com/files/${SRCNAME}-${PV}.tar.gz;
SRC_URI[md5sum] = 2fbef8cb61e506c706957ab6e135840c
diff --git a/meta/recipes-devtools/python/python-imaging_1.1.7.bb
b/meta/recipes-devtools/python/python-imaging_1.1.7.bb
index 6d9743e..a36c344 100644
--- a/meta/recipes-devtools/python/python-imaging_1.1.7.bb
+++ b/meta/recipes-devtools/python/python-imaging_1.1.7.bb
@@ -4,7 +4,7 @@ LICENSE = MIT
LIC_FILES_CHKSUM =
file://README;beginline=92;endline=120;md5=c4371af4579f1e489cf881c1443dd4ec
DEPENDS = freetype jpeg tiff
SRCNAME = Imaging
-PR = r3
+PR = r4
SRC_URI = http://effbot.org/downloads/Imaging-${PV}.tar.gz \
file://0001-python-imaging-setup.py-force-paths-for-zlib-freetyp.patch
diff --git a/meta/recipes-devtools/python/python-pycurl_7.19.0.bb
b/meta/recipes-devtools/python/python-pycurl_7.19.0.bb
index 8b849d7..122e1bd 100644
--- a/meta/recipes-devtools/python/python-pycurl_7.19.0.bb
+++ b/meta/recipes-devtools/python/python-pycurl_7.19.0.bb
@@ -9,7 +9,7 @@ LIC_FILES_CHKSUM =
file://README;endline=13;md5=fbfe545b1869617123a08c0983ef17b
DEPENDS = curl python
RDEPENDS_${PN} = python-core curl
SRCNAME = pycurl
-PR = r2
+PR = r3
SRC_URI = \
http://${SRCNAME}.sourceforge.net/download/${SRCNAME}-${PV}.tar.gz;name=archive
\
diff --git a/meta/recipes-devtools/python/python-pyrex_0.9.9.bb
b/meta/recipes-devtools/python/python-pyrex_0.9.9.bb
index 568fb0d..0ae35b0 100644
--- a/meta/recipes-devtools/python/python-pyrex_0.9.9.bb
+++ b/meta/recipes-devtools/python/python-pyrex_0.9.9.bb
@@ -5,7 +5,7 @@ SECTION = devel/python
LICENSE = Apache-2.0
LIC_FILES_CHKSUM = file://LICENSE.txt;md5=771d472f53f933033f577808e5bd
SRCNAME = Pyrex
-PR = r3
+PR = r4
SRC_URI = \
http://www.cosc.canterbury.ac.nz/greg.ewing/python/${SRCNAME}/${SRCNAME}-${PV}.tar.gz
\
diff --git a/meta/recipes-devtools/python/python-scons_2.1.0.bb
b/meta/recipes-devtools/python/python-scons_2.1.0.bb
index f0b5b1f..8c5aa07 100644
--- a/meta/recipes-devtools/python/python-scons_2.1.0.bb
+++ b/meta/recipes-devtools/python/python-scons_2.1.0.bb
@@ -4,7 +4,7 @@ LICENSE = MIT
LIC_FILES_CHKSUM = file://LICENSE.txt;md5=ab8b65435c2e520ed18e67459f1f9bb9
SRCNAME = scons
-PR = r1
+PR = r2
SRC_URI = ${SOURCEFORGE_MIRROR}/scons/scons-${PV}.tar.gz
diff --git a/meta/recipes-devtools/python/python-setuptools_0.6c11.bb
b/meta/recipes-devtools/python/python-setuptools_0.6c11.bb
index 5dd5f31..a769714 100644
--- a/meta/recipes-devtools/python/python-setuptools_0.6c11.bb
+++ b/meta/recipes-devtools/python/python-setuptools_0.6c11.bb
@@ -5,7 +5,7 @@ LICENSE = PSF
LIC_FILES_CHKSUM =
file://setup.py;beginline=23;endline=23;md5=8a314270dd7a8dbca741775415f1716e
SRCNAME = setuptools
-PR = ml3
+PR = ml4
DEPENDS += python
DEPENDS_virtclass-native += python-native
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] tcmode-external-csl: preferred external-csl-toolchain's gdbserver
Signed-off-by: Christopher Larson kerg...@gmail.com --- meta/conf/distro/include/tcmode-external-csl.inc |1 + 1 file changed, 1 insertion(+) diff --git a/meta/conf/distro/include/tcmode-external-csl.inc b/meta/conf/distro/include/tcmode-external-csl.inc index 731780b..0fa2ee1 100644 --- a/meta/conf/distro/include/tcmode-external-csl.inc +++ b/meta/conf/distro/include/tcmode-external-csl.inc @@ -34,6 +34,7 @@ PREFERRED_PROVIDER_virtual/libintl = external-csl-toolchain PREFERRED_PROVIDER_virtual/libiconv = external-csl-toolchain PREFERRED_PROVIDER_glibc-thread-db = external-csl-toolchain PREFERRED_PROVIDER_virtual/linux-libc-headers = external-csl-toolchain +PREFERRED_PROVIDER_gdbserver ??= external-csl-toolchain # No need to re-compile the locale files GLIBC_INTERNAL_USE_BINARY_LOCALE = precompiled -- 1.7.10.2 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] Rename 'external-csl' to 'external-sourcery'
This is a rename per the purchase of CodeSourcery by Mentor Graphics
Corporation, and associated naming change.
Signed-off-by: Christopher Larson kerg...@gmail.com
---
meta/conf/distro/include/tcmode-external-csl.inc | 120 +---
...ternal-csl.inc = tcmode-external-sourcery.inc} | 34 +++---
...toolchain.bb = external-sourcery-toolchain.bb} |0
.../SUPPORTED |0
4 files changed, 19 insertions(+), 135 deletions(-)
copy meta/conf/distro/include/{tcmode-external-csl.inc =
tcmode-external-sourcery.inc} (77%)
rename meta/recipes-core/meta/{external-csl-toolchain.bb =
external-sourcery-toolchain.bb} (100%)
rename meta/recipes-core/meta/{external-csl-toolchain =
external-sourcery-toolchain}/SUPPORTED (100%)
diff --git a/meta/conf/distro/include/tcmode-external-csl.inc
b/meta/conf/distro/include/tcmode-external-csl.inc
index 0fa2ee1..9e530ab 100644
--- a/meta/conf/distro/include/tcmode-external-csl.inc
+++ b/meta/conf/distro/include/tcmode-external-csl.inc
@@ -1,118 +1,2 @@
-#
-# Configuration to use external CSL toolchain
-#
-
-EXTERNAL_TOOLCHAIN ?= /usr/local/csl/${TARGET_ARCH}
-
-TOOLCHAIN_PATH_ADD = ${EXTERNAL_TOOLCHAIN}/bin:
-PATH =. ${TOOLCHAIN_PATH_ADD}
-
-CSL_TARGET_SYS_powerpc ?= powerpc-linux-gnu
-CSL_TARGET_SYS_powerpc64 ?= powerpc-linux-gnu
-CSL_TARGET_SYS_arm ?= arm-none-linux-gnueabi
-CSL_TARGET_SYS_mips ?= mips-linux-gnu
-CSL_TARGET_SYS_mipsel ?= mips-linux-gnu
-CSL_TARGET_SYS_mips64 ?= mips-linux-gnu
-CSL_TARGET_SYS_i686 ?= i686-pc-linux-gnu
-CSL_TARGET_SYS_i586 ?= i686-pc-linux-gnu
-CSL_TARGET_SYS = ${TARGET_SYS}
-
-TARGET_PREFIX = ${CSL_TARGET_SYS}-
-
-PREFERRED_PROVIDER_linux-libc-headers = external-csl-toolchain
-PREFERRED_PROVIDER_linux-libc-headers-dev = external-csl-toolchain
-PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}gcc = external-csl-toolchain
-PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}gcc-initial =
external-csl-toolchain
-PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}gcc-intermediate =
external-csl-toolchain
-PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}g++ = external-csl-toolchain
-PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}binutils = external-csl-toolchain
-PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}libc-for-gcc =
external-csl-toolchain
-PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}compilerlibs =
external-csl-toolchain
-PREFERRED_PROVIDER_libgcc = external-csl-toolchain
-PREFERRED_PROVIDER_virtual/libc = external-csl-toolchain
-PREFERRED_PROVIDER_virtual/libintl = external-csl-toolchain
-PREFERRED_PROVIDER_virtual/libiconv = external-csl-toolchain
-PREFERRED_PROVIDER_glibc-thread-db = external-csl-toolchain
-PREFERRED_PROVIDER_virtual/linux-libc-headers = external-csl-toolchain
-PREFERRED_PROVIDER_gdbserver ??= external-csl-toolchain
-
-# No need to re-compile the locale files
-GLIBC_INTERNAL_USE_BINARY_LOCALE = precompiled
-ENABLE_BINARY_LOCALE_GENERATION =
-
-TOOLCHAIN_OPTIONS = --sysroot=${STAGING_DIR_HOST}
-
-# Translate to CodeSourcery's names for their optimized files in the toolchain
-def csl_target_core(d):
-coredata = {
-'armv7a-vfp-neon': 'armv7-a-neon',
-'i586': 'sgxx-glibc',
-'i686': 'sgxx-glibc',
-'core2': 'sgxx-glibc',
-'mips': 'mips32',
-'mipsel': 'el',
-'powerpc-nf': 'nof',
-'ppce500': 'te500v1',
-'ppce500mc': 'te500mc',
-'ppce500v2': 'te500v2',
-'ppce600': 'te600'
-}
-return coredata.get(d.getVar('TUNE_PKGARCH', True), '')
-
-CSL_TARGET_CORE ?= ${@csl_target_core(d)}
-
-# Unfortunately, the CSL ia32 toolchain has non-prefixed binaries in its
-# bindir (e.g. gcc, ld). To avoid this messing up our build, we avoid adding
-# this bindir to our PATH, and instead add symlinks to the prefixed binaries
-# to our staging toolchain bindir.
-
-python toolchain_metadata_setup () {
-if not isinstance(e, bb.event.ConfigParsed):
-return
-
-d = e.data
-
-l = d.createCopy()
-l.finalize()
-if os.path.exists(bb.data.expand('${EXTERNAL_TOOLCHAIN}/bin/gcc', l)):
-d.setVar('TOOLCHAIN_PATH_ADD', '')
-}
-addhandler toolchain_metadata_setup
-
-python toolchain_setup () {
-if not isinstance(e, bb.event.BuildStarted):
-return
-
-d = e.data
-
-if not d.getVar('TOOLCHAIN_PATH_ADD', True):
-populate_toolchain_links(d)
-}
-addhandler toolchain_setup
-
-def populate_toolchain_links(d):
-import errno
-import os
-from glob import glob
-
-d = d.createCopy()
-d.finalize()
-
-pattern = d.expand('${EXTERNAL_TOOLCHAIN}/bin/${TARGET_PREFIX}*')
-files = glob(pattern)
-if not files:
-bb.fatal(Unable to populate toolchain binary symlinks in %s %
pattern)
-
-bindir = d.getVar('STAGING_BINDIR_TOOLCHAIN', True)
-bb.mkdirhier(bindir)
-for f in files:
-base = os.path.basename(f)
-newpath = os.path.join(bindir, base)
-try:
-os.symlink(f, newpath)
-except OSError as exc:
-if
[OE-core] [PATCH 3/3] external-sourcery-toolchain: ignore GNU_HASH issues with its packages
Signed-off-by: Christopher Larson kerg...@gmail.com
---
meta/recipes-core/meta/external-sourcery-toolchain.bb |6 ++
1 file changed, 6 insertions(+)
diff --git a/meta/recipes-core/meta/external-sourcery-toolchain.bb
b/meta/recipes-core/meta/external-sourcery-toolchain.bb
index a14e958..b8cb6d9 100644
--- a/meta/recipes-core/meta/external-sourcery-toolchain.bb
+++ b/meta/recipes-core/meta/external-sourcery-toolchain.bb
@@ -92,6 +92,12 @@ PACKAGES =+ libgcc libgcc-dev libstdc++ libstdc++-dev
libstdc++-staticdev linux
# This test should be fixed to ignore .a files in .debug dirs
INSANE_SKIP_${PN}-dbg = staticdev
+# We don't care about GNU_HASH in prebuilt binaries
+INSANE_SKIP_${PN}-utils += ldflags
+INSANE_SKIP_libstdc++ += ldflags
+INSANE_SKIP_libgcc += ldflags
+INSANE_SKIP_gdbserver += ldflags
+
PKG_${PN} = eglibc
PKG_${PN}-dev = eglibc-dev
PKG_${PN}-staticdev = eglibc-staticdev
--
1.7.10.2
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] qemu: Add option to disable GL acceleration, Edwin, May14, 2012
Ping... On Mon, May 14, 2012 at 10:00:58PM +0800, edwin.z...@intel.com wrote: From: Zhai Edwin edwin.z...@intel.com All, This patch add an PACKAGECONFIG in qemu to disable GL acceleration: * By default configure try best to enable GL acceleration and fail when missing host dependency(libSDL and libGL). * End user can also choose to turn off GL capability, thus remove the host dependence(libSDLlibGL) in building. [YOCTO #2407] got fixed. Pls. help to review and pull The following changes since commit 54f38111868775c85bfe921592d8443a61952c62: pango: Fix modules load failure in multilib environment (2012-05-14 21:50:55 +0800) are available in the git repository at: git://git.pokylinux.org/poky-contrib gzhai/fix2 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=gzhai/fix2 Zhai Edwin (1): qemu: Add an option to remove host sdl/gl checking .../qemu/qemu-0.15.1/opengl-disable-option.patch | 172 meta/recipes-devtools/qemu/qemu.inc| 23 +--- meta/recipes-devtools/qemu/qemu_0.15.1.bb |1 + 3 files changed, 176 insertions(+), 20 deletions(-) create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.1/opengl-disable-option.patch ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- best rgds, edwin ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
