[OE-core] [PATCH 2/2] qemu: Poke more paths for presence of libgl
On ubuntu 11.10 libGL is not in
/usr/lib/`uname -i`-linux-gnu/ directory
so we search this dir too.
Signed-off-by: Khem Raj raj.k...@gmail.com
---
meta/recipes-devtools/qemu/qemu.inc |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-devtools/qemu/qemu.inc
b/meta/recipes-devtools/qemu/qemu.inc
index ac8a3eb..85476d6 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -26,6 +26,7 @@ do_configure_prepend_virtclass-native() {
test -e /usr/lib/libGL.so -a -e /usr/lib/libGLU.so libgl='yes'
test -e /usr/lib64/libGL.so -a -e /usr/lib64/libGLU.so libgl='yes'
+test -e /usr/lib/`uname -i`-linux-gnu/libGL.so -a -e /usr/lib/`uname
-i`-linux-gnu/libGLU.so libgl='yes'
test -e /usr/lib/pkgconfig/sdl.pc -o -e /usr/lib64/pkgconfig/sdl.pc -o -e
/usr/include/SDL/SDL.h libsdl='yes'
--
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] shared-mime-info, avahi, polkit: inherit perlnative
Otherwise we end up with configure errors like below
| checking for perl... /usr/bin/perl
| checking for perl = 5.8.1... 5.12.4
| checking for XML::Parser... configure: error: XML::Parser perl module is
required for intltool
| + bbfatal 'oe_runconf failed'
| + echo 'ERROR: oe_runconf failed'
| ERROR: oe_runconf failed
Signed-off-by: Khem Raj raj.k...@gmail.com
---
meta/recipes-connectivity/avahi/avahi.inc |2 +-
meta/recipes-connectivity/avahi/avahi_0.6.30.bb|2 +-
meta/recipes-extended/polkit/polkit_0.101.bb |4 ++--
.../shared-mime-info/shared-mime-info.inc |2 +-
.../shared-mime-info/shared-mime-info_0.90.bb |2 +-
5 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/meta/recipes-connectivity/avahi/avahi.inc
b/meta/recipes-connectivity/avahi/avahi.inc
index dc7a5ae..5695403 100644
--- a/meta/recipes-connectivity/avahi/avahi.inc
+++ b/meta/recipes-connectivity/avahi/avahi.inc
@@ -21,7 +21,7 @@ SRC_URI = http://avahi.org/download/avahi-${PV}.tar.gz \
file://99avahi-autoipd \
file://initscript.patch
-inherit autotools pkgconfig update-rc.d gettext
+inherit autotools pkgconfig update-rc.d gettext perlnative
EXTRA_OECONF = --with-distro=debian \
--with-avahi-priv-access-group=adm \
diff --git a/meta/recipes-connectivity/avahi/avahi_0.6.30.bb
b/meta/recipes-connectivity/avahi/avahi_0.6.30.bb
index 05716d0..da40426 100644
--- a/meta/recipes-connectivity/avahi/avahi_0.6.30.bb
+++ b/meta/recipes-connectivity/avahi/avahi_0.6.30.bb
@@ -6,7 +6,7 @@ LIC_FILES_CHKSUM =
file://LICENSE;md5=2d5025d4aa3495befef8f17206a5b0a1 \
file://avahi-daemon/main.c;endline=21;md5=9ee77368c5407af77caaef1b07285969 \
file://avahi-client/client.h;endline=23;md5=f4ac741a25c4f434039ba3e18c8674cf
-PR = r4
+PR = r5
SRC_URI[md5sum] = e4db89a2a403ff4c47d66ac66fad1f43
SRC_URI[sha256sum] =
f9e4316c2339d0020726edd846d01bee0c39980906db0c247479e5807457ff1f
diff --git a/meta/recipes-extended/polkit/polkit_0.101.bb
b/meta/recipes-extended/polkit/polkit_0.101.bb
index 06ca595..1dde885 100644
--- a/meta/recipes-extended/polkit/polkit_0.101.bb
+++ b/meta/recipes-extended/polkit/polkit_0.101.bb
@@ -11,12 +11,12 @@ SRC_URI =
http://hal.freedesktop.org/releases/polkit-${PV}.tar.gz \
${@base_contains('DISTRO_FEATURES', 'pam', '${PAM_SRC_URI}', '',
d)}
PAM_SRC_URI = file://polkit-1_pam.patch
-PR = r1
+PR = r2
DEPENDS = libpam expat dbus-glib eggdbus intltool-native
RDEPENDS_${PN} = libpam
EXTRA_OECONF = --with-authfw=pam --with-os-type=moblin --disable-man-pages
--disable-gtk-doc --disable-introspection
-inherit autotools pkgconfig
+inherit autotools pkgconfig perlnative
FILES_${PN} += ${libdir}/${PN}-1/extensions/*.so \
${datadir}/${PN}-1/actions/* \
diff --git a/meta/recipes-support/shared-mime-info/shared-mime-info.inc
b/meta/recipes-support/shared-mime-info/shared-mime-info.inc
index 64eef9d..8b10535 100644
--- a/meta/recipes-support/shared-mime-info/shared-mime-info.inc
+++ b/meta/recipes-support/shared-mime-info/shared-mime-info.inc
@@ -10,7 +10,7 @@ DEPENDS_virtclass-native = libxml2-native intltool-native
glib-2.0-native
SRC_URI = http://freedesktop.org/~hadess/shared-mime-info-${PV}.tar.bz2;
-inherit autotools pkgconfig gettext
+inherit autotools pkgconfig gettext perlnative
EXTRA_OECONF = --disable-update-mimedb
diff --git a/meta/recipes-support/shared-mime-info/shared-mime-info_0.90.bb
b/meta/recipes-support/shared-mime-info/shared-mime-info_0.90.bb
index cbbd0fe..4c852fa 100644
--- a/meta/recipes-support/shared-mime-info/shared-mime-info_0.90.bb
+++ b/meta/recipes-support/shared-mime-info/shared-mime-info_0.90.bb
@@ -1,5 +1,5 @@
require shared-mime-info.inc
-PR = r0
+PR = r1
SRC_URI += file://fix-parallel-build.patch \
file://fix-parallel-build-backport.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] scripts/runqemu: Make it run on ubuntu 11.10
location of libGL has moved in ubuntu 11.10 so we look for it in the new locations Signed-off-by: Khem Raj raj.k...@gmail.com --- scripts/runqemu |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/scripts/runqemu b/scripts/runqemu index 9611c64..2b8e88a 100755 --- a/scripts/runqemu +++ b/scripts/runqemu @@ -388,6 +388,7 @@ libgl='no' test -e /usr/lib/libGL.so -a -e /usr/lib/libGLU.so libgl='yes' test -e /usr/lib64/libGL.so -a -e /usr/lib64/libGLU.so libgl='yes' +test -e /usr/lib/`uname -i`-linux-gnu/libGL.so -a -e /usr/lib/`uname -i`-linux-gnu/libGLU.so libgl='yes' if [ $libgl != 'yes' ]; then echo You need libGL.so and libGLU.so to exist in your library path to run the QEMU emulator. -- 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/2][PULL] Multilib: Fix bug 1340
Hi Richard, The following two commits fix the issue that, some normal packages are built out when building pure multilib image lib32-core-image-sato. Please help to review and pull. [YOCTO #1340] The following changes since commit 7a278238d9b08e0315e92d386282cb488cc0c7b4: bitbake.conf/powerpc64: Set baselib to 'lib64' for ppc64 (2011-08-05 17:48:23 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib dxu4/ml2 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dxu4/ml2 Dongxiao Xu (2): gnome-doc-utils: Avoid RDEPENDS on bash in native case. module-init-tools-cross: Clean the RDEPENDS value meta/recipes-gnome/gnome/gnome-doc-utils.inc |1 + .../module-init-tools-cross_3.16.bb|1 + 2 files changed, 2 insertions(+), 0 deletions(-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] module-init-tools-cross: Clean the RDEPENDS value
cross recipes should not RDEPENDS on any package. Cross recipe has no
PACKAGES define, thus clean RDEPENDS_${PN} value to ensure correctness
in multilib.
Signed-off-by: Dongxiao Xu dongxiao...@intel.com
---
.../module-init-tools-cross_3.16.bb|1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git
a/meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.16.bb
b/meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.16.bb
index a6c5d21..dee163d 100644
--- a/meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.16.bb
+++ b/meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.16.bb
@@ -2,6 +2,7 @@ require module-init-tools.inc
PR = r0
inherit cross
PROVIDES += virtual/${TARGET_PREFIX}depmod
+RDEPENDS_${PN} =
SRC_URI[md5sum] = bc44832c6e41707b8447e2847d2019f5
SRC_URI[sha256sum] =
e1f2cdcae64a8effc25e545a5e0bdaf312f816ebbcd0916e4e87450755fab64b
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] gnome-doc-utils: Avoid RDEPENDS on bash in native case.
gnome-doc-utils-native should not RDEPENDS on bash, thus add RDEPENDS
override to fix the issue.
Signed-off-by: Dongxiao Xu dongxiao...@intel.com
---
meta/recipes-gnome/gnome/gnome-doc-utils.inc |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-gnome/gnome/gnome-doc-utils.inc
b/meta/recipes-gnome/gnome/gnome-doc-utils.inc
index bd7c615..7c28eab 100644
--- a/meta/recipes-gnome/gnome/gnome-doc-utils.inc
+++ b/meta/recipes-gnome/gnome/gnome-doc-utils.inc
@@ -16,5 +16,6 @@ do_install_append() {
FILES_${PN} += ${datadir}/xml* ${PYTHON_SITEPACKAGES_DIR}/*
RDEPENDS_${PN} = bash
+RDEPENDS_${PN}_virtclass-native =
BBCLASSEXTEND = native
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 10/10] eglibc: remove PACKAGES from eglibc.inc
* PACKAGES were defined in eglibc.inc as well as eglibc-package.inc, definition
from eglibc.inc was overriden from recipes including eglibc.inc only
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/recipes-core/eglibc/eglibc.inc |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/eglibc/eglibc.inc
b/meta/recipes-core/eglibc/eglibc.inc
index 1b2e630..0f97f82 100644
--- a/meta/recipes-core/eglibc/eglibc.inc
+++ b/meta/recipes-core/eglibc/eglibc.inc
@@ -41,8 +41,6 @@ EGLIBCPARALLELISM := PARALLELMFLAGS=${PARALLEL_MAKE}
EXTRA_OEMAKE += ${EGLIBCPARALLELISM}
PARALLEL_MAKE =
-PACKAGES = glibc catchsegv sln nscd ldd glibc-utils glibc-dev glibc-doc
libsegfault glibc-extra-nss glibc-thread-db glibc-pcprofile
-
OE_FEATURES = ${@features_to_eglibc_settings(d)}
do_configure_prepend() {
sed -e s#@BASH@#/bin/sh# -i ${S}/elf/ldd.bash.in
--
1.7.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] base.bbclass: Ensure PREFERRED_PROVIDER and PREFERRED_VERSION values are set for multilibs
Richard Purdie wrote on 2011-08-05:
When running multilib builds its not intuitive for the specificed
versions/providers to be build in one case and the higher version in the
other.
This patch mirrors the options unless they're already set.
There shouldn't be any effect if the MULTILIBS variable isn't set.
[YOCTO #1339]
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org ---
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass index
ff960cd..4aee847 100644 --- a/meta/classes/base.bbclass +++
b/meta/classes/base.bbclass @@ -139,6 +139,46 @@ def pkgarch_mapping(d):
if d.getVar(TUNE_PKGARCH, True) == armv7a-vfp-neon:
d.setVar(TUNE_PKGARCH, armv7a)
+def preferred_ml_updates(d):
+# If any PREFERRED_PROVIDER or PREFERRED_VERSIONS are set,
+# we need to mirror these variables in the multilib case
+multilibs = d.getVar('MULTILIBS', True) or
+if not multilibs:
+return
+
+prefixes = []
+for ext in multilibs.split():
+eext = ext.split(':')
+if len(eext) 1 and eext[0] == 'multilib':
+prefixes.append(eext[1])
+
+versions = []
+providers = []
+for v in d.keys():
+if v.startswith(PREFERRED_VERSION_):
+versions.append(v)
+if v.startswith(PREFERRED_PROVIDER_):
+providers.append(v)
+
+for v in versions:
+val = d.getVar(v, False)
+pkg = v.replace(PREFERRED_VERSION_, )
+for p in prefixes:
+newname = PREFERRED_VERSION_ + p + - + pkg
+if not d.getVar(newname, False):
+d.setVar(newname, val)
+
+for prov in providers:
+val = d.getVar(prov, False)
+pkg = prov.replace(PREFERRED_PROVIDER_, )
+virt =
+if pkg.startswith(virtual/):
+ pkg = pkg.replace(virtual/, )
+ virt = virtual/
+for p in prefixes:
+newname = PREFERRED_PROVIDER_ + virt + p + - + pkg
+if not d.getVar(newname, False):
+d.setVar(newname, p + - + val)
How about the native and nativesdk packages? I think they should not be
prefixed.
addhandler base_eventhandler
python base_eventhandler() {
@@ -211,6 +251,7 @@ python base_eventhandler() {
if name == ConfigParsed:
generate_git_config(e)
pkgarch_mapping(e.data)
+preferred_ml_updates(e.data)
if not data in e.__dict__:
return
Best Regards,
Lianhao
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Error running QEMU with oe-core / angstrom console-image, hwclock: can't open '/dev/misc/rtc' : No such file or directory
2011/8/5 Khem Raj raj.k...@gmail.com: It means QEMUOPTIONS is empty in your case because you are sing ext2 image. It supports ext3 and btrfs but it should be easy to add ext2 to mix. Can you try something like below diff --git a/scripts/runqemu-internal b/scripts/runqemu-internal index c15632d..64635df 100755 - --- a/scripts/runqemu-internal +++ b/scripts/runqemu-internal @@ -277,7 +277,7 @@ if [ $MACHINE = qemuarm -o $MACHINE = qemuarmv6 -o $MACHINE = qemuarm MACHINE_SUBTYPE=versatilepb QEMU_UI_OPTIONS=$QEMU_UI_OPTIONS # QEMU_UI_OPTIONS=$QEMU_UI_OPTIONS -force-pointer - - if [ $FSTYPE = ext3 -o $FSTYPE = btrfs ]; then + if [ $FSTYPE = ext3 -o $FSTYPE = btrfs -o $FSTYPE = ext2 ]; then KERNCMDLINE=root=/dev/sda rw console=ttyAMA0,115200 console=tty $KERNEL_NETWORK_CMD mem=$QEMU_MEMORY hi QEMUOPTIONS=$QEMU_NETWORK_CMD -M versatilepb -hda $ROOTFS - -no-reboot $QEMU_UI_OPTIONS fi This patch didn't work for me, git and patch asserted that it's malformed: - samuel@S-Stirtzel-Linux:/var/oe-core/setup-scripts/sources/openembedded-core$ git apply /home/samuel/Downloads/runqemu-initial.diff fatal: patch with only garbage at line 3 samuel@S-Stirtzel-Linux:/var/oe-core/setup-scripts/sources/openembedded-core$ patch -p0 /home/samuel/Downloads/runqemu-initial.diff patching file scripts/runqemu-internal patch: malformed patch at line 6: qemuarmv6 -o $MACHINE = qemuarm - After I got this done, executing runqemu shows this error: - samuel@S-Stirtzel-Linux:/var/oe-core/setup-scripts/sources/openembedded-core$ runqemu /var/oe-core/tmp-eglibc/deploy/images/qemuarm/zImage-qemuarm.bin /var/oe-core/tmp-eglibc/deploy/images/qemuarm/console-image-qemuarm.ext2 Set MACHINE to [qemuarm] based on kernel [/var/oe-core/tmp-eglibc/deploy/images/qemuarm/zImage-qemuarm.bin] Continuing with the following parameters: KERNEL: [/var/oe-core/tmp-eglibc/deploy/images/qemuarm/zImage-qemuarm.bin] ROOTFS: [/var/oe-core/tmp-eglibc/deploy/images/qemuarm/console-image-qemuarm.ext2] FSTYPE: [ext2] Setting up tap interface under sudo [sudo] password for samuel: Acquiring lockfile for tap0... /var/oe-core/setup-scripts/sources/openembedded-core/scripts/runqemu-internal: Line 280: [: Too many arguments. Error: Unable to support this combination of options Set 'tap0' nonpersistent Releasing lockfile of preconfigured tap device 'tap0' - Ext3 works with the script (reverted the patch), but it seems that i can't connect my machine (host) to the internet as long as QEMU runs. Can't try if the guest can access the internet or communicate with the host since it looks like systemd patches broke some init related stuff. Regards Samuel ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Unrecognized option while building pseudo (target)
Hi, After updating my work-in-progress to upgrade our internal distro from oe-dev to oe-core, I got a new problem... (At least new to me, as far as I remember I didn't have that problem before the vacation. Otoh, my old build-box is temporarily out of service HW-problems, so this is a new build environment). The problem is that my cross-compiler, arm-oe-linux-gnueabi-gcc, do not recognize the -m32 option, that the pseudo makefile tries to supply. Short excerpt of the build log, just to show the call to gcc and its error message: | arm-oe-linux-gnueabi-gcc -march=armv5te -mno-thumb -mthumb-interwork -mtune=arm926ej-s --sysroot=/home/anders/oe-build-core/build-ccu/tmp-eglibc/sysroots/ccu -O2 -pipe -g -feliminate-unused-debug-types -pipe -std=gnu99 -Wall -W -Wextra -fPIC -D_LARGEFILE64_SOURCE -D_ATFILE_SOURCE -m32 -DPSEUDO_PREFIX='/usr' -DPSEUDO_SUFFIX='' -DPSEUDO_BINDIR='bin' -DPSEUDO_LIBDIR='lib/pseudo/lib' -DPSEUDO_LOCALSTATEDIR='var/pseudo' -DPSEUDO_VERSION='1.1.1' -O2 -g -L/home/anders/oe-build-core/build-ccu/tmp-eglibc/sysroots/ccu/usr/lib -I/home/anders/oe-build-core/build-ccu/tmp-eglibc/sysroots/ccu/usr/include -Wl,-R/home/anders/oe-build-core/build-ccu/tmp-eglibc/sysroots/ccu/usr/lib -c -o pseudo_tables.o pseudo_tables.c | cc1: error: unrecognized command line option '-m32'cc1: error: unrecognized command line option '-m32'cc1: error: unrecognized command line option '-m32'cc1: error: unrecognized command line option '-m32' By commenting out the setting of 'CFLAGS_CODE += -m$(BITS)' in Makefile.in, I can get the build to continue past pseudo. Any ideas of how I should correctly fix this? Or if I have some other problem in my environment that could cause such a failure Cheers, Anders -- Anders Darander ChargeStorm AB / EStorm AB ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [Updated CONSOLIDATED PULL 00/15] Fixes for M3 and getting master to build
On Sat, 2011-08-06 at 22:01 -0700, Saul Wold wrote:
Richard,
This has Bruce's updated Kernel, which has taken a spin on the fuzzy builder,
along with a fix for M3 BSP failures and a couple of other bug and build
fixes.
I also remembered to include the SRC_URI checksums this time for the recipe
updates.
Thanks
Sau!
The following changes since commit 7a278238d9b08e0315e92d386282cb488cc0c7b4:
bitbake.conf/powerpc64: Set baselib to 'lib64' for ppc64 (2011-08-05
17:48:23 +0100)
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
Bruce Ashfield (4):
linux-yocto: pass KMACHINE to updateme, not MACHINE
linux-yocto: allow configuration of arbitrary branches
linux-yocto: update atom-pc preempt-rt definition
linux-yocto: merge v3.0.1
Koen Kooi (3):
gst-plugins: partially sync packaging with OE .dev
gtk-icon-cache bbclass: don't assing to global RDEPENDS
gtk-icon-cache: fix RDEPENDS append bug
I squashed these two into one
Kumar Gala (1):
gcc: use ${base_lib} to match gcc default configuration
Mei Lei (2):
python-native: Fix a compiler finding issue
apr-util: disable pqsql support to avoid configure error
Saul Wold (5):
gdb: Update to 7.3
liburcu: Update to 0.6.4
lttng-ust: Update to 0.15
lttng-control: Update to 0.89
, fixed the piece in lttng-control that belonged in lttng-ust
kernel-yocto: add CCACHE_DIR dependency to do_kernel_configme
and merged them all 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 1/1] multilib.conf: Supported multilib extend in more recipes.
On Mon, 2011-08-08 at 11:39 +0800, Lianhao Lu wrote: Added more recipes supporting multilib extend. Signed-off-by: Lianhao Lu lianhao...@intel.com --- meta/conf/multilib.conf | 449 +-- 1 files changed, 436 insertions(+), 13 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 5/6] ghostscript: Fixed the incorrect DEPENDS.
On Mon, 2011-08-08 at 17:11 +0800, Yu Ke wrote:
on 2011-8-5 18:37, Lianhao Lu wrote:
[YOCTO #1337]
Using ghostscript-native instead of ${PN}-native in DEPENDS to correct
the invalid DEPENDS in multilib cases.
Signed-off-by: Lianhao Lulianhao...@intel.com
---
.../ghostscript/ghostscript_9.02.bb|2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-extended/ghostscript/ghostscript_9.02.bb
b/meta/recipes-extended/ghostscript/ghostscript_9.02.bb
index 28c6c9e..2e46734 100644
--- a/meta/recipes-extended/ghostscript/ghostscript_9.02.bb
+++ b/meta/recipes-extended/ghostscript/ghostscript_9.02.bb
@@ -17,7 +17,7 @@ LIC_FILES_CHKSUM =
file://LICENSE;md5=d151214b3131251dfc9d858593acbd24
PR = r4
-DEPENDS = ${PN}-native tiff jpeg fontconfig cups
+DEPENDS = ghostscript-native tiff jpeg fontconfig cups
DEPENDS_virtclass-native =
SRC_URI_BASE =
http://downloads.ghostscript.com/public/ghostscript-${PV}.tar.bz2;
This looks a generic issue to me. i.e. when the dependency ends with
-native, we should make sure it won't has multilib prefix. so the
following patch will be more generic. or at least, we should document
somewhere that ${PN}-native dependency is not right.
diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
index 6e1669f..c73e5f9 100644
--- a/meta/classes/multilib.bbclass
+++ b/meta/classes/multilib.bbclass
@@ -43,7 +43,11 @@ python __anonymous () {
newdeps = []
for dep in deps:
if dep.endswith((-native, -native-runtime)):
-newdeps.append(dep)
+if dep.startswith(variant):
+# remove the leading MLPREFIX
+newdeps.append(dep[len(variant)+1:])
+else:
+newdeps.append(dep)
else:
newdeps.append(extend_name(dep))
d.setVar(varname, .join(newdeps))
comment? if it is Ok, I will submit a patch.
I'm not sure I like this. I think fixing the individual recipes to use
BPN instead of PN might be a better way to handle this.
We could also error upon detecting this situation instead of magically
fixing it up as above...
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] multilib theory practice
On Sat, 2011-08-06 at 15:56 -0500, Kumar Gala wrote: I'm looking at trying to get multilib working for powerpc. However I'm a bit lost in how this is suppose to work from a few different perspectives: 1. from user perspective (I'm starting with a 64-bit build in /lib64 and adding 32-bit that would be in /lib): (i've added in local/conf): require conf/multilib.conf MULTILIBS = multilib:lib DEFAULTTUNE_virtclass-multilib-lib = powerpc Rather than use the identifier lib, I'd use an identifier like lib32 which is unlikely to be found in a recipe name. Therefore something like: require conf/multilib.conf MULTILIBS = multilib:lib32 DEFAULTTUNE_virtclass-multilib-lib32 = powerpc What should this end up producing? Do I get a 32-bit set of libs built automatically? What else do I need to do? This will enable a number of other built targets such as lib32-bash. You can also construct images that are mixtures of the various multilibs (e.g. install both openssl and lib32-openssl). 2. From a infrastructure point of view: * Do have a single compiler that is multi-arch or 2 compilers? (not sure how the x86_64 toolchain works today) At this point we've gone for 2 compilers. This was a conscious choice to avoid additional complexity and allow us to get the core functionality working. We can support merged toolchains at a future date with appropriate toolchain configuration and ASSUME_PROVIDED declarations. * what areas should I investigate that might need tweaking that are arch specific? There should be very little beyond the places you've already changed that should need tweaking. The only issues may be due to this being very new code. * should I see different task names for the new multilib builds? (or the 32-bit specific builds?) multilib.conf lists the recipes that will become multilib enabled. I've just merged a patch to extend this list to include the various ones that have been tested. The ultimate plan is not to require that list and its just a transition point. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] multilib theory practice
On Sun, 2011-08-07 at 11:50 -0500, Kumar Gala wrote: On Aug 6, 2011, at 3:56 PM, Kumar Gala wrote: I'm looking at trying to get multilib working for powerpc. However I'm a bit lost in how this is suppose to work from a few different perspectives: 1. from user perspective (I'm starting with a 64-bit build in /lib64 and adding 32-bit that would be in /lib): (i've added in local/conf): require conf/multilib.conf MULTILIBS = multilib:lib DEFAULTTUNE_virtclass-multilib-lib = powerpc What should this end up producing? Do I get a 32-bit set of libs built automatically? What else do I need to do? 2. From a infrastructure point of view: * Do have a single compiler that is multi-arch or 2 compilers? (not sure how the x86_64 toolchain works today) * what areas should I investigate that might need tweaking that are arch specific? * should I see different task names for the new multilib builds? (or the 32-bit specific builds?) To add to this I'm wondering how we get proper eglibc for 32-bit, how we get proper gcc libs (libgcc, etc). As per my reply, we currently treat this as two separate toolchains so this makes this part of the problem very easy. 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] gtk-icon-cache: fix RDEPENDS append bug
On Sat, 2011-08-06 at 09:25 +0200, Koen Kooi wrote: python += doesn't add a leading space, which we do need: | Collected errors: | * satisfy_dependencies_for: Cannot satisfy the following dependencies for task-gnome-themes: | *gnome-icon-themehicolor-icon-theme * | * opkg_install_cmd: Cannot install package task-gnome-themes. | * satisfy_dependencies_for: Cannot satisfy the following dependencies for task-gnome-apps: | *iso-codeshicolor-icon-theme * | * opkg_install_cmd: Cannot install package task-gnome-apps. | * satisfy_dependencies_for: Cannot satisfy the following dependencies for task-gnome: | *grephicolor-icon-theme * | * opkg_install_cmd: Cannot install package task-gnome. Signed-off-by: Koen Kooi k...@dominion.thruhere.net --- meta/classes/gtk-icon-cache.bbclass |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Squashed into the original commit since that hadn't merged yet and both merged into 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] multilib theory practice
On Aug 8, 2011, at 7:58 AM, Richard Purdie wrote: On Sat, 2011-08-06 at 15:56 -0500, Kumar Gala wrote: I'm looking at trying to get multilib working for powerpc. However I'm a bit lost in how this is suppose to work from a few different perspectives: 1. from user perspective (I'm starting with a 64-bit build in /lib64 and adding 32-bit that would be in /lib): (i've added in local/conf): require conf/multilib.conf MULTILIBS = multilib:lib DEFAULTTUNE_virtclass-multilib-lib = powerpc Rather than use the identifier lib, I'd use an identifier like lib32 which is unlikely to be found in a recipe name. Therefore something like: require conf/multilib.conf MULTILIBS = multilib:lib32 DEFAULTTUNE_virtclass-multilib-lib32 = powerpc is 'lib32' utilized anywhere else or just to match these things together? Just want to be clear that I'd expect 32-bit libraries to be in /lib/ What should this end up producing? Do I get a 32-bit set of libs built automatically? What else do I need to do? This will enable a number of other built targets such as lib32-bash. You can also construct images that are mixtures of the various multilibs (e.g. install both openssl and lib32-openssl). What would I expect w/regards to RPM or ipk's that are created? How does one tell the 32-bit vs 64-bit? 2. From a infrastructure point of view: * Do have a single compiler that is multi-arch or 2 compilers? (not sure how the x86_64 toolchain works today) At this point we've gone for 2 compilers. This was a conscious choice to avoid additional complexity and allow us to get the core functionality working. We can support merged toolchains at a future date with appropriate toolchain configuration and ASSUME_PROVIDED declarations. What would they be called or how are they distinguished? * what areas should I investigate that might need tweaking that are arch specific? There should be very little beyond the places you've already changed that should need tweaking. The only issues may be due to this being very new code. * should I see different task names for the new multilib builds? (or the 32-bit specific builds?) multilib.conf lists the recipes that will become multilib enabled. I've just merged a patch to extend this list to include the various ones that have been tested. The ultimate plan is not to require that list and its just a transition point. I feel like I tried 'enabling' multilib on ppc and didn't see anything new built for the 32-bit libs. - k ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] tune-ppce5500: Add a tune file for PowerPC e5500 core
On Aug 5, 2011, at 3:11 PM, Kumar Gala wrote:
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
meta/conf/machine/include/tune-ppce5500.inc | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
create mode 100644 meta/conf/machine/include/tune-ppce5500.inc
diff --git a/meta/conf/machine/include/tune-ppce5500.inc
b/meta/conf/machine/include/tune-ppce5500.inc
new file mode 100644
index 000..8e6403d
--- /dev/null
+++ b/meta/conf/machine/include/tune-ppce5500.inc
@@ -0,0 +1,14 @@
+DEFAULTTUNE ?= ppce5500
+
+require conf/machine/include/powerpc/arch-powerpc64.inc
+
+TUNEVALID[ppce5500] = Enable ppce5500 specific processor optimizations
+TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, ppce5500,
-mcpu=e5500, , d)}
+TUNE_PKGARCH = ${@bb.utils.contains(TUNE_FEATURES, ppce5500,
ppce5500, ${PPCPKGARCH}, d)}
+
+AVAILTUNES += ppce5500
+TUNE_FEATURES_tune-ppce5500 = m64 ppce5500
+PACKAGE_EXTRA_ARCHS_tune-ppce5500 = powerpc64 ppce5500
+
+# glibc configure options to get e5500 specific library (for sqrt)
+GLIBC_EXTRA_OECONF += --with-cpu=e5500
--
1.7.3.4
If I want to have a version of this for 32-bit only (or default) and one for
64-bit, how would it be best to handle that?
- k
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] tune-ppce5500: Add a tune file for PowerPC e5500 core
On Mon, 2011-08-08 at 09:39 -0500, Kumar Gala wrote:
On Aug 5, 2011, at 3:11 PM, Kumar Gala wrote:
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
meta/conf/machine/include/tune-ppce5500.inc | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
create mode 100644 meta/conf/machine/include/tune-ppce5500.inc
diff --git a/meta/conf/machine/include/tune-ppce5500.inc
b/meta/conf/machine/include/tune-ppce5500.inc
new file mode 100644
index 000..8e6403d
--- /dev/null
+++ b/meta/conf/machine/include/tune-ppce5500.inc
@@ -0,0 +1,14 @@
+DEFAULTTUNE ?= ppce5500
+
+require conf/machine/include/powerpc/arch-powerpc64.inc
+
+TUNEVALID[ppce5500] = Enable ppce5500 specific processor optimizations
+TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, ppce5500,
-mcpu=e5500, , d)}
+TUNE_PKGARCH = ${@bb.utils.contains(TUNE_FEATURES, ppce5500,
ppce5500, ${PPCPKGARCH}, d)}
+
+AVAILTUNES += ppce5500
+TUNE_FEATURES_tune-ppce5500 = m64 ppce5500
+PACKAGE_EXTRA_ARCHS_tune-ppce5500 = powerpc64 ppce5500
+
+# glibc configure options to get e5500 specific library (for sqrt)
+GLIBC_EXTRA_OECONF += --with-cpu=e5500
--
1.7.3.4
If I want to have a version of this for 32-bit only (or default) and one for
64-bit, how would it be best to handle that?
I was wondering about this. You really need to make it conditional on
something, e.g.
GLIBC_EXTRA_OECONF += ${@bb.utils.contains(TUNE_FEATURES, m32,
--with-cpu=e5500, , d)}
however, if you do this you need to ensure that TUNE_PKGARCH is not
powerpc but something e5500 specific at this point since you are
enabling e5500 specific optimisations.
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] multilib theory practice
On Mon, 2011-08-08 at 09:32 -0500, Kumar Gala wrote: On Aug 8, 2011, at 7:58 AM, Richard Purdie wrote: On Sat, 2011-08-06 at 15:56 -0500, Kumar Gala wrote: I'm looking at trying to get multilib working for powerpc. However I'm a bit lost in how this is suppose to work from a few different perspectives: 1. from user perspective (I'm starting with a 64-bit build in /lib64 and adding 32-bit that would be in /lib): (i've added in local/conf): require conf/multilib.conf MULTILIBS = multilib:lib DEFAULTTUNE_virtclass-multilib-lib = powerpc Rather than use the identifier lib, I'd use an identifier like lib32 which is unlikely to be found in a recipe name. Therefore something like: require conf/multilib.conf MULTILIBS = multilib:lib32 DEFAULTTUNE_virtclass-multilib-lib32 = powerpc is 'lib32' utilized anywhere else or just to match these things together? Just want to be clear that I'd expect 32-bit libraries to be in /lib/ The actual baselib comes from: BASE_LIB_tune-powerpc = lib i.e. from the tune you selected so it would be lib unless you overrode this value. The lib32 is just used as an identifier in this scenario. What should this end up producing? Do I get a 32-bit set of libs built automatically? What else do I need to do? This will enable a number of other built targets such as lib32-bash. You can also construct images that are mixtures of the various multilibs (e.g. install both openssl and lib32-openssl). What would I expect w/regards to RPM or ipk's that are created? How does one tell the 32-bit vs 64-bit? It depends on the package backend and what its capabilities are. Offhand I think we settled on rpms having the same name but being placed in a different directory and have the package architecture changed. The names of ipks are changed to include the lib32- prefix. 2. From a infrastructure point of view: * Do have a single compiler that is multi-arch or 2 compilers? (not sure how the x86_64 toolchain works today) At this point we've gone for 2 compilers. This was a conscious choice to avoid additional complexity and allow us to get the core functionality working. We can support merged toolchains at a future date with appropriate toolchain configuration and ASSUME_PROVIDED declarations. What would they be called or how are they distinguished? They're installed into different paths and the lib32- prefix is also used for the different targets. * what areas should I investigate that might need tweaking that are arch specific? There should be very little beyond the places you've already changed that should need tweaking. The only issues may be due to this being very new code. * should I see different task names for the new multilib builds? (or the 32-bit specific builds?) multilib.conf lists the recipes that will become multilib enabled. I've just merged a patch to extend this list to include the various ones that have been tested. The ultimate plan is not to require that list and its just a transition point. I feel like I tried 'enabling' multilib on ppc and didn't see anything new built for the 32-bit libs. Did you try something like bitbake lib32-bash though? Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] how to pass or set specific gcc flags?
On Aug 8, 2011, at 9:55 AM, Richard Purdie wrote: On Sun, 2011-08-07 at 12:08 -0500, Kumar Gala wrote: We'd like to pass: --enable-targets=all on ppc when we target a 64-bit platform but happen to build a 32-bit toolchain rootfs, its useful to still have 64-bit support in the compiler to build a 64-bit kernel if desired in this scenario. Also, this seems useful for the multilib situation. Wondering what the best way of doing this. Adding something into the tune-ppcFOOBAR file but not sure how to do that so it gets picked up by the right toolchain pass. And what do we even override? I suggested adding a GCC_EXTRA_OECONF. I'd caution against this since we don't currently handle packaging of toolchains directly using multilibs and I suspect the compiler wouldn't bootstrap properly either. Its not the compiler itself I worry about but pieces like libc and libgcc. I dont think they have any issue with --enable-targets on ppc. The issue is I'm trying to look at this based on our customer view point. The majority of our customers that would utilize 64-bit are going to want to start with a 32-bit rootfs and than add some 64-bit bits to it. Rather than the other way. This is one reason I'm asking about how to deal with tune-ppce5500.inc and 32-bit vs 64-bit. Now it might be ok short term since we have 2 toolchains, etc for multilib. However at some point (shortly) we have to address this. I think the 2 toolchains is UGLY and confusing to customers/users. While I understand it from the point of view on how to take steps to get multilib going it doesn't mean we shouldnt start thinking about how to address these issues. - k ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] tune-ppce5500: Add a tune file for PowerPC e5500 core
On Aug 8, 2011, at 9:48 AM, Richard Purdie wrote:
On Mon, 2011-08-08 at 09:39 -0500, Kumar Gala wrote:
On Aug 5, 2011, at 3:11 PM, Kumar Gala wrote:
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
meta/conf/machine/include/tune-ppce5500.inc | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
create mode 100644 meta/conf/machine/include/tune-ppce5500.inc
diff --git a/meta/conf/machine/include/tune-ppce5500.inc
b/meta/conf/machine/include/tune-ppce5500.inc
new file mode 100644
index 000..8e6403d
--- /dev/null
+++ b/meta/conf/machine/include/tune-ppce5500.inc
@@ -0,0 +1,14 @@
+DEFAULTTUNE ?= ppce5500
+
+require conf/machine/include/powerpc/arch-powerpc64.inc
+
+TUNEVALID[ppce5500] = Enable ppce5500 specific processor optimizations
+TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, ppce5500,
-mcpu=e5500, , d)}
+TUNE_PKGARCH = ${@bb.utils.contains(TUNE_FEATURES, ppce5500,
ppce5500, ${PPCPKGARCH}, d)}
+
+AVAILTUNES += ppce5500
+TUNE_FEATURES_tune-ppce5500 = m64 ppce5500
+PACKAGE_EXTRA_ARCHS_tune-ppce5500 = powerpc64 ppce5500
+
+# glibc configure options to get e5500 specific library (for sqrt)
+GLIBC_EXTRA_OECONF += --with-cpu=e5500
--
1.7.3.4
If I want to have a version of this for 32-bit only (or default) and one for
64-bit, how would it be best to handle that?
I was wondering about this. You really need to make it conditional on
something, e.g.
GLIBC_EXTRA_OECONF += ${@bb.utils.contains(TUNE_FEATURES, m32,
--with-cpu=e5500, , d)}
Sorry, I meant for the whole file, not just the GLIBC_EXTRA_OECONF (That has to
be done regardless of 32-bit or 64-bit).
however, if you do this you need to ensure that TUNE_PKGARCH is not
powerpc but something e5500 specific at this point since you are
enabling e5500 specific optimisations.
Which it is, or do you mean being more explicit about it via:
TUNE_PKGARCH = ppce5500
rather than:
TUNE_PKGARCH = ${@bb.utils.contains(TUNE_FEATURES, ppce5500, ppce5500,
${PPCPKGARCH}, d)}
- k
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Unrecognized option while building pseudo (target)
pseudo currently only works on IA32 hosts. It was never really intended to work on the target system, but should. If you think you want pseudo on the target.. you'll have to verify that all of the calls are being trapped properly on ARM, as well as modify the build instructions to not worry about IA32 specific items. (Right now, if you change the compilation to not specify the -m32 on arm, I'd give pseudo about a 75% chance of working properly on ARM.. but it's never been tested there.) --Mark On 8/8/11 6:36 AM, Anders Darander wrote: Hi, After updating my work-in-progress to upgrade our internal distro from oe-dev to oe-core, I got a new problem... (At least new to me, as far as I remember I didn't have that problem before the vacation. Otoh, my old build-box is temporarily out of service HW-problems, so this is a new build environment). The problem is that my cross-compiler, arm-oe-linux-gnueabi-gcc, do not recognize the -m32 option, that the pseudo makefile tries to supply. Short excerpt of the build log, just to show the call to gcc and its error message: | arm-oe-linux-gnueabi-gcc -march=armv5te -mno-thumb -mthumb-interwork -mtune=arm926ej-s --sysroot=/home/anders/oe-build-core/build-ccu/tmp-eglibc/sysroots/ccu -O2 -pipe -g -feliminate-unused-debug-types -pipe -std=gnu99 -Wall -W -Wextra -fPIC -D_LARGEFILE64_SOURCE -D_ATFILE_SOURCE -m32 -DPSEUDO_PREFIX='/usr' -DPSEUDO_SUFFIX='' -DPSEUDO_BINDIR='bin' -DPSEUDO_LIBDIR='lib/pseudo/lib' -DPSEUDO_LOCALSTATEDIR='var/pseudo' -DPSEUDO_VERSION='1.1.1' -O2 -g -L/home/anders/oe-build-core/build-ccu/tmp-eglibc/sysroots/ccu/usr/lib -I/home/anders/oe-build-core/build-ccu/tmp-eglibc/sysroots/ccu/usr/include -Wl,-R/home/anders/oe-build-core/build-ccu/tmp-eglibc/sysroots/ccu/usr/lib -c -o pseudo_tables.o pseudo_tables.c | cc1: error: unrecognized command line option '-m32'cc1: error: unrecognized command line option '-m32'cc1: error: unrecognized command line option '-m32'cc1: error: unrecognized command line option '-m32' By commenting out the setting of 'CFLAGS_CODE += -m$(BITS)' in Makefile.in, I can get the build to continue past pseudo. Any ideas of how I should correctly fix this? Or if I have some other problem in my environment that could cause such a failure Cheers, Anders ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] how to pass or set specific gcc flags?
That's passing flags to gcc, I mean passing flags to how gcc is configured - k On Aug 8, 2011, at 10:53 AM, Kamble, Nitin A wrote: Kumar, Look at the meta/conf/machine/include/ia32/arch-ia32.inc where we have done special flags passing to gcc other tools. Nitin -Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Kumar Gala Sent: Sunday, August 07, 2011 10:09 AM To: Patches and discussions about the oe-core layer Subject: [OE-core] how to pass or set specific gcc flags? We'd like to pass: --enable-targets=all on ppc when we target a 64-bit platform but happen to build a 32-bit toolchain rootfs, its useful to still have 64-bit support in the compiler to build a 64-bit kernel if desired in this scenario. Also, this seems useful for the multilib situation. Wondering what the best way of doing this. Adding something into the tune-ppcFOOBAR file but not sure how to do that so it gets picked up by the right toolchain pass. And what do we even override? I suggested adding a GCC_EXTRA_OECONF. - k ___ 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 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gcc: Add ability for tune files to pass in configure options to gcc
On Aug 2, 2011, at 8:42 AM, Richard Purdie wrote:
On Tue, 2011-08-02 at 08:11 -0500, Kumar Gala wrote:
On Aug 1, 2011, at 11:57 AM, Richard Purdie wrote:
On Mon, 2011-08-01 at 09:44 -0700, Tom Rini wrote:
On 08/01/2011 09:07 AM, Phil Blundell wrote:
On Mon, 2011-08-01 at 09:37 -0500, Kumar Gala wrote:
Not sure I understand the statement about disambiguate the resulting
compilers, on PPC where I intend to utilize this we'd have the
toolchains already named something like:
The thing about disambiguating was that, if you're going to modify the
configure opts for gcc-cross based (indirectly) on ${MACHINE} you need
to consider what happens if you have a single build directory that's
being used for multiple MACHINEs.
What, I think, Kumar is driving at is why are you saying MACHINE when
it's a per core tune he's doing. eg, every e5500 would do --with-cpu=e5500
The question is whether we'd like to get to the point of having more
toolchains or less toolchains. I'd personally like to get to the point
of less toolchains (e.g. one per arch) rather than more of them. We
already pass all the appropriate flags around in the ADT/sdk code and in
our own cross builds, we could easily add those to the default target
environment too. This would actually make it clearer what is going on to
the end user too rather than hiding the details into the gcc
compilation.
So all things considered, I don't think this is the best way to go...
How is this done or exported to the user of an ADT/sdk toolchain?
There is a script included in the toolchain tarball which contains the
appropriate information. I don't have one handy to check but I suspect
Jessica will have. Jessica?
Ping on this script?
- k
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gcc: Add ability for tune files to pass in configure options to gcc
On Aug 2, 2011, at 8:11 AM, Kumar Gala wrote:
On Aug 1, 2011, at 11:57 AM, Richard Purdie wrote:
On Mon, 2011-08-01 at 09:44 -0700, Tom Rini wrote:
On 08/01/2011 09:07 AM, Phil Blundell wrote:
On Mon, 2011-08-01 at 09:37 -0500, Kumar Gala wrote:
Not sure I understand the statement about disambiguate the resulting
compilers, on PPC where I intend to utilize this we'd have the toolchains
already named something like:
The thing about disambiguating was that, if you're going to modify the
configure opts for gcc-cross based (indirectly) on ${MACHINE} you need
to consider what happens if you have a single build directory that's
being used for multiple MACHINEs.
What, I think, Kumar is driving at is why are you saying MACHINE when
it's a per core tune he's doing. eg, every e5500 would do --with-cpu=e5500
The question is whether we'd like to get to the point of having more
toolchains or less toolchains. I'd personally like to get to the point
of less toolchains (e.g. one per arch) rather than more of them. We
already pass all the appropriate flags around in the ADT/sdk code and in
our own cross builds, we could easily add those to the default target
environment too. This would actually make it clearer what is going on to
the end user too rather than hiding the details into the gcc
compilation.
So all things considered, I don't think this is the best way to go...
How is this done or exported to the user of an ADT/sdk toolchain?
I still dont understand the concern here. GCC is already picking a default for
-mcpu, so why is having a tune file pick a better default any issue?
If there is an explicit -mcpu or other options like -mtune, the setting of
--with-cpu will get ignored.
- k
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/3] new x86 ABI x32 V2 patch series
On Fri, 2011-08-05 at 10:42 -0700, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com These are the commits for the new x86_64 ABI named x32. These are changed as per the feedback received on the mailing list. The kernel related commits are dropped from this series as Bruce is pushing them directly. The following changes since commit da321ee54b26b11e2bd36c889c5568ae62b17ffd: linux-yocto: pass KMACHINE to updateme, not MACHINE (2011-08-05 10:00:33 -0700) are available in the git repository at: git://git.pokylinux.org/poky-contrib nitin/x32.rebased http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=nitin/x32.rebased Nitin A Kamble (3): siteinfo.bbclass: add entries for new x86_64 ABI x32 target insane.bbclass: add entries for linux-gnux32 x86 tune inc files: add x32 abi tune parameters 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] Error running QEMU with oe-core / angstrom console-image, hwclock: can't open '/dev/misc/rtc' : No such file or directory
On Mon, Aug 8, 2011 at 2:27 AM, Samuel Stirtzel s.stirt...@googlemail.com wrote: 2011/8/5 Khem Raj raj.k...@gmail.com: It means QEMUOPTIONS is empty in your case because you are sing ext2 image. It supports ext3 and btrfs but it should be easy to add ext2 to mix. Can you try something like below diff --git a/scripts/runqemu-internal b/scripts/runqemu-internal index c15632d..64635df 100755 - --- a/scripts/runqemu-internal +++ b/scripts/runqemu-internal @@ -277,7 +277,7 @@ if [ $MACHINE = qemuarm -o $MACHINE = qemuarmv6 -o $MACHINE = qemuarm MACHINE_SUBTYPE=versatilepb QEMU_UI_OPTIONS=$QEMU_UI_OPTIONS # QEMU_UI_OPTIONS=$QEMU_UI_OPTIONS -force-pointer - - if [ $FSTYPE = ext3 -o $FSTYPE = btrfs ]; then + if [ $FSTYPE = ext3 -o $FSTYPE = btrfs -o $FSTYPE = ext2 ]; then KERNCMDLINE=root=/dev/sda rw console=ttyAMA0,115200 console=tty $KERNEL_NETWORK_CMD mem=$QEMU_MEMORY hi QEMUOPTIONS=$QEMU_NETWORK_CMD -M versatilepb -hda $ROOTFS - -no-reboot $QEMU_UI_OPTIONS fi This patch didn't work for me, git and patch asserted that it's malformed: ofcouse it was meant to be a hint not cooked patch - samuel@S-Stirtzel-Linux:/var/oe-core/setup-scripts/sources/openembedded-core$ git apply /home/samuel/Downloads/runqemu-initial.diff fatal: patch with only garbage at line 3 samuel@S-Stirtzel-Linux:/var/oe-core/setup-scripts/sources/openembedded-core$ patch -p0 /home/samuel/Downloads/runqemu-initial.diff patching file scripts/runqemu-internal patch: malformed patch at line 6: qemuarmv6 -o $MACHINE = qemuarm - After I got this done, executing runqemu shows this error: - samuel@S-Stirtzel-Linux:/var/oe-core/setup-scripts/sources/openembedded-core$ runqemu /var/oe-core/tmp-eglibc/deploy/images/qemuarm/zImage-qemuarm.bin /var/oe-core/tmp-eglibc/deploy/images/qemuarm/console-image-qemuarm.ext2 Set MACHINE to [qemuarm] based on kernel [/var/oe-core/tmp-eglibc/deploy/images/qemuarm/zImage-qemuarm.bin] Continuing with the following parameters: KERNEL: [/var/oe-core/tmp-eglibc/deploy/images/qemuarm/zImage-qemuarm.bin] ROOTFS: [/var/oe-core/tmp-eglibc/deploy/images/qemuarm/console-image-qemuarm.ext2] FSTYPE: [ext2] Setting up tap interface under sudo [sudo] password for samuel: Acquiring lockfile for tap0... /var/oe-core/setup-scripts/sources/openembedded-core/scripts/runqemu-internal: Line 280: [: Too many arguments. Error: Unable to support this combination of options Set 'tap0' nonpersistent Releasing lockfile of preconfigured tap device 'tap0' - Ext3 works with the script (reverted the patch), but it seems that i can't connect my machine (host) to the internet as long as QEMU runs. Doesn't happen here where latest snapshot. I can access internet from both guest and host equally well. Can't try if the guest can access the internet or communicate with the host since it looks like systemd patches broke some init related stuff. Regards Samuel ___ 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
[OE-core] [PATCH] linux 3.0: Add patch from OE to set dto to max value to fix MMC timeouts
Signed-off-by: Joel A Fernandes agnel.j...@gmail.com
---
...mc-Adjust-dto-to-eliminate-timeout-errors.patch | 33
recipes-kernel/linux/linux_3.0.bb |3 +-
2 files changed, 35 insertions(+), 1 deletions(-)
create mode 100644
recipes-kernel/linux/linux-3.0/beagle/0006-omap-mmc-Adjust-dto-to-eliminate-timeout-errors.patch
diff --git
a/recipes-kernel/linux/linux-3.0/beagle/0006-omap-mmc-Adjust-dto-to-eliminate-timeout-errors.patch
b/recipes-kernel/linux/linux-3.0/beagle/0006-omap-mmc-Adjust-dto-to-eliminate-timeout-errors.patch
new file mode 100644
index 000..8cd314c
--- /dev/null
+++
b/recipes-kernel/linux/linux-3.0/beagle/0006-omap-mmc-Adjust-dto-to-eliminate-timeout-errors.patch
@@ -0,0 +1,33 @@
+From bd0b2f97c48aa6aac0c6a494f1c6ba5af5de486b Mon Sep 17 00:00:00 2001
+From: Steve Sakoman st...@sakoman.com
+Date: Mon, 18 Jul 2011 23:13:41 -0500
+Subject: [PATCH] omap_hsmmc: Set dto to max value of 14 to avoid SD Card
timeouts
+
+This fixes MMC errors due to timeouts on certain SD Cards following suggestions
+to set dto to 14 by Jason Kridner and Steven Kipisz
+
+Details of the issue:
+http://talk.maemo.org/showthread.php?p=1000707#post1000707
+
+This fix was originally proposed by Sukumar Ghoral of TI.
+---
+ drivers/mmc/host/omap_hsmmc.c |3 +++
+ 1 files changed, 3 insertions(+), 0 deletions(-)
+
+diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
+index 9646a75..7443647 100644
+--- a/drivers/mmc/host/omap_hsmmc.c
b/drivers/mmc/host/omap_hsmmc.c
+@@ -1049,6 +1049,9 @@ static void set_data_timeout(struct omap_hsmmc_host
*host,
+ dto = 14;
+ }
+
++ /* Set dto to max value of 14 to avoid SD Card timeouts */
++ dto = 14;
++
+ reg = ~DTO_MASK;
+ reg |= dto DTO_SHIFT;
+ OMAP_HSMMC_WRITE(host-base, SYSCTL, reg);
+--
+1.7.0.4
+
diff --git a/recipes-kernel/linux/linux_3.0.bb
b/recipes-kernel/linux/linux_3.0.bb
index f17ebcf..edb8df7 100644
--- a/recipes-kernel/linux/linux_3.0.bb
+++ b/recipes-kernel/linux/linux_3.0.bb
@@ -9,7 +9,7 @@ COMPATIBLE_MACHINE = (beagleboard)
SRCREV_pn-${PN} = 94ed5b4788a7cdbe68bc7cb8516972cbebdc8274
# The main PR is now using MACHINE_KERNEL_PR, for omap3 see
conf/machine/include/omap3.inc
-MACHINE_KERNEL_PR_append = j
+MACHINE_KERNEL_PR_append = k
FILESPATHPKG_prepend = linux-3.0:
@@ -195,6 +195,7 @@ SRC_URI +=
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-3.0.y.git
file://beagle/0003-HACK-OMAP3-beagle-switch-to-GPTIMER1.patch \
file://beagle/0004-OMAP3-beagle-HACK-add-in-1GHz-OPP.patch \
file://beagle/0005-omap3-Add-basic-support-for-720MHz-part.patch \
+
file://beagle/0006-omap-mmc-Adjust-dto-to-eliminate-timeout-errors.patch \
file://madc/0001-Enabling-Hwmon-driver-for-twl4030-madc.patch \
file://madc/0002-mfd-twl-core-enable-madc-clock.patch \
\
--
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] how to pass or set specific gcc flags?
On Mon, 2011-08-08 at 10:46 -0500, Kumar Gala wrote: On Aug 8, 2011, at 9:55 AM, Richard Purdie wrote: On Sun, 2011-08-07 at 12:08 -0500, Kumar Gala wrote: We'd like to pass: --enable-targets=all on ppc when we target a 64-bit platform but happen to build a 32-bit toolchain rootfs, its useful to still have 64-bit support in the compiler to build a 64-bit kernel if desired in this scenario. Also, this seems useful for the multilib situation. Wondering what the best way of doing this. Adding something into the tune-ppcFOOBAR file but not sure how to do that so it gets picked up by the right toolchain pass. And what do we even override? I suggested adding a GCC_EXTRA_OECONF. I'd caution against this since we don't currently handle packaging of toolchains directly using multilibs and I suspect the compiler wouldn't bootstrap properly either. Its not the compiler itself I worry about but pieces like libc and libgcc. I dont think they have any issue with --enable-targets on ppc. No, I'm suggesting the build system can't cope with that, e.g. if there are multiple libgcc's produced we have no way to correctly individually package them. The issue is I'm trying to look at this based on our customer view point. The majority of our customers that would utilize 64-bit are going to want to start with a 32-bit rootfs and than add some 64-bit bits to it. Rather than the other way. Ok, so why not define your multilib the other way around? Start with a 64 bit system and add 64 bit as the multilib? This is one reason I'm asking about how to deal with tune-ppce5500.inc and 32-bit vs 64-bit. In these cases you need to define 32 and 64 bit tunes and then you can select the appropriate tune as needed. Now it might be ok short term since we have 2 toolchains, etc for multilib. However at some point (shortly) we have to address this. I think the 2 toolchains is UGLY and confusing to customers/users. While I understand it from the point of view on how to take steps to get multilib going it doesn't mean we shouldnt start thinking about how to address these issues. We've been working on multilb for a while and so far its taken some significant work by several people to get things working as they are now. We really need to spend some some and stabilise and consolidate that work so far at this point. I'm more than happy to think about consolidating the toolchain pieces, its on the future ideas list but I don't believe its appropriate right now. I'd like the work done so far to work properly before we try enhancing it further. I'd hope that the toolchains are actually pretty hidden from customers/users to, I don't think its as ugly as you're making out and actually has some benefits. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] how to pass or set specific gcc flags?
On Mon, Aug 8, 2011 at 12:25 PM, Richard Purdie richard.pur...@linuxfoundation.org wrote: I think the 2 toolchains is UGLY and confusing to customers/users. While I understand it from the point of view on how to take steps to get multilib going it doesn't mean we shouldnt start thinking about how to address these issues. We've been working on multilb for a while and so far its taken some significant work by several people to get things working as they are now. We really need to spend some some and stabilise and consolidate that work so far at this point. I'm more than happy to think about consolidating the toolchain pieces, its on the future ideas list but I don't believe its appropriate right now. I'd like the work done so far to work properly before we try enhancing it further. I'd hope that the toolchains are actually pretty hidden from customers/users to, I don't think its as ugly as you're making out and actually has some benefits. I think 32bit will be called powerpc-*-*-gcc and 64bit will be powerpc64-*-*-gcc which is IMO readable. GCC based toolchains have their own idea of multilib which isnt quite same as OE. So I think current solution is better. As long as both compilers are shipped in SDKs it should be fine. But I see the point where if you have been shipping single multilibbed toolchains then there will be a change the way compilers are invoked. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gcc: Add ability for tune files to pass in configure options to gcc
On Mon, 2011-08-08 at 11:35 -0500, Kumar Gala wrote:
On Aug 2, 2011, at 8:11 AM, Kumar Gala wrote:
On Aug 1, 2011, at 11:57 AM, Richard Purdie wrote:
On Mon, 2011-08-01 at 09:44 -0700, Tom Rini wrote:
On 08/01/2011 09:07 AM, Phil Blundell wrote:
On Mon, 2011-08-01 at 09:37 -0500, Kumar Gala wrote:
Not sure I understand the statement about disambiguate the resulting
compilers, on PPC where I intend to utilize this we'd have the
toolchains already named something like:
The thing about disambiguating was that, if you're going to modify the
configure opts for gcc-cross based (indirectly) on ${MACHINE} you need
to consider what happens if you have a single build directory that's
being used for multiple MACHINEs.
What, I think, Kumar is driving at is why are you saying MACHINE when
it's a per core tune he's doing. eg, every e5500 would do
--with-cpu=e5500
The question is whether we'd like to get to the point of having more
toolchains or less toolchains. I'd personally like to get to the point
of less toolchains (e.g. one per arch) rather than more of them. We
already pass all the appropriate flags around in the ADT/sdk code and in
our own cross builds, we could easily add those to the default target
environment too. This would actually make it clearer what is going on to
the end user too rather than hiding the details into the gcc
compilation.
So all things considered, I don't think this is the best way to go...
How is this done or exported to the user of an ADT/sdk toolchain?
I still dont understand the concern here. GCC is already picking a
default for -mcpu, so why is having a tune file pick a better default
any issue?
If there is an explicit -mcpu or other options like -mtune, the
setting of --with-cpu will get ignored.
There are two sides to this:
a) In the ppc case there isn't that much of an issue since the different
tunes tend to have their own very specific package architectures. It
likely therefore doesn't matter much if gcc is hardcoded to a given
default. It would matter more on certain arm combinations I can think of
depending on what got hardcoded as default.
b) There are very few circumstances you'd ever be in an environment
where the correct cpu flags weren't getting supplied (and we have sanity
checks to ensure they do). We want to be heading to wards less
toolchains, not more toolchains and the more we code into the toolchain,
the more different toolchain builds we'll need.
Whilst I can see the reason for wanting a), I worry it will mask issues
where the flags are missing and also cause more toolchain fragmentation
with people very likely to get the values wrong in the arm case. I'm
therefore reluctant.
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] uclibc_0.9.32: Sync mount.h from eglibc
mount.h has few more defines that are being used by newer
applications such as systemd
Signed-off-by: Khem Raj raj.k...@gmail.com
---
.../uclibc/uclibc-0.9.32/mount.h-update.patch | 85
meta/recipes-core/uclibc/uclibc_0.9.32.bb |3 +-
2 files changed, 87 insertions(+), 1 deletions(-)
create mode 100644 meta/recipes-core/uclibc/uclibc-0.9.32/mount.h-update.patch
diff --git a/meta/recipes-core/uclibc/uclibc-0.9.32/mount.h-update.patch
b/meta/recipes-core/uclibc/uclibc-0.9.32/mount.h-update.patch
new file mode 100644
index 000..3508e0e
--- /dev/null
+++ b/meta/recipes-core/uclibc/uclibc-0.9.32/mount.h-update.patch
@@ -0,0 +1,85 @@
+Sync mount.h from glibc this is needed to get missing defines
+that some apps e.g. systemd are depending on
+
+Signed-off-by: Khem Raj raj.k...@gmail.com
+
+Upstream-Status: Pending
+
+Index: git/include/sys/mount.h
+===
+--- git.orig/include/sys/mount.h 2011-07-21 14:37:27.134255747 -0700
git/include/sys/mount.h2011-07-21 14:39:53.844470932 -0700
+@@ -1,5 +1,5 @@
+ /* Header file for mounting/unmount Linux filesystems.
+- Copyright (C) 1996,1997,1998,1999,2000,2004 Free Software Foundation, Inc.
++ Copyright (C) 1996-2000, 2004, 2010 Free Software Foundation, Inc.
+This file is part of the GNU C Library.
+
+The GNU C Library is free software; you can redistribute it and/or
+@@ -47,23 +47,46 @@
+ #define MS_REMOUNTMS_REMOUNT
+ MS_MANDLOCK = 64, /* Allow mandatory locks on an FS. */
+ #define MS_MANDLOCK MS_MANDLOCK
+- S_WRITE = 128, /* Write on file/directory/symlink. */
+-#define S_WRITE S_WRITE
+- S_APPEND = 256, /* Append-only file. */
+-#define S_APPEND S_APPEND
+- S_IMMUTABLE = 512, /* Immutable file. */
+-#define S_IMMUTABLE S_IMMUTABLE
++ MS_DIRSYNC = 128, /* Directory modifications are synchronous. */
++#define MS_DIRSYNCMS_DIRSYNC
+ MS_NOATIME = 1024, /* Do not update access times. */
+ #define MS_NOATIMEMS_NOATIME
+ MS_NODIRATIME = 2048, /* Do not update directory access
times. */
+ #define MS_NODIRATIME MS_NODIRATIME
+ MS_BIND = 4096, /* Bind directory at different place. */
+ #define MS_BIND MS_BIND
++ MS_MOVE = 8192,
++#define MS_MOVE MS_MOVE
++ MS_REC = 16384,
++#define MS_RECMS_REC
++ MS_SILENT = 32768,
++#define MS_SILENT MS_SILENT
++ MS_POSIXACL = 1 16, /* VFS does not apply the umask. */
++#define MS_POSIXACL MS_POSIXACL
++ MS_UNBINDABLE = 1 17,/* Change to unbindable. */
++#define MS_UNBINDABLE MS_UNBINDABLE
++ MS_PRIVATE = 1 18, /* Change to private. */
++#define MS_PRIVATEMS_PRIVATE
++ MS_SLAVE = 1 19, /* Change to slave. */
++#define MS_SLAVE MS_SLAVE
++ MS_SHARED = 1 20,/* Change to shared. */
++#define MS_SHARED MS_SHARED
++ MS_RELATIME = 1 21, /* Update atime relative to mtime/ctime. */
++#define MS_RELATIME MS_RELATIME
++ MS_KERNMOUNT = 1 22, /* This is a kern_mount call. */
++#define MS_KERNMOUNT MS_KERNMOUNT
++ MS_I_VERSION = 1 23,/* Update inode I_version field. */
++#define MS_I_VERSION MS_I_VERSION
++ MS_STRICTATIME = 1 24, /* Always perform atime updates. */
++#define MS_STRICTATIMEMS_STRICTATIME
++ MS_ACTIVE = 1 30,
++#define MS_ACTIVE MS_ACTIVE
++ MS_NOUSER = 1 31
++#define MS_NOUSER MS_NOUSER
+ };
+
+ /* Flags that can be altered by MS_REMOUNT */
+-#define MS_RMT_MASK (MS_RDONLY|MS_SYNCHRONOUS|MS_MANDLOCK|MS_NOATIME \
+- |MS_NODIRATIME)
++#define MS_RMT_MASK (MS_RDONLY|MS_SYNCHRONOUS|MS_MANDLOCK|MS_I_VERSION)
+
+
+ /* Magic mount flag number. Has to be or-ed to the flag values. */
+@@ -100,8 +123,10 @@
+ #define MNT_FORCE MNT_FORCE
+ MNT_DETACH = 2, /* Just detach from the tree. */
+ #define MNT_DETACH MNT_DETACH
+- MNT_EXPIRE = 4 /* Mark for expiry. */
++ MNT_EXPIRE = 4, /* Mark for expiry. */
+ #define MNT_EXPIRE MNT_EXPIRE
++ UMOUNT_NOFOLLOW = 8 /* Don't follow symlink on umount. */
++#define UMOUNT_NOFOLLOW UMOUNT_NOFOLLOW
+ };
+
+
diff --git a/meta/recipes-core/uclibc/uclibc_0.9.32.bb
b/meta/recipes-core/uclibc/uclibc_0.9.32.bb
index 8dcb260..235b436 100644
--- a/meta/recipes-core/uclibc/uclibc_0.9.32.bb
+++ b/meta/recipes-core/uclibc/uclibc_0.9.32.bb
@@ -1,7 +1,7 @@
SRCREV=9152c4d67c763fde5712e2d181d92c0d7e1e2ab9
require uclibc.inc
-PR = ${INC_PR}.2
+PR = ${INC_PR}.3
PROVIDES += virtual/${TARGET_PREFIX}libc-for-gcc
SRC_URI = git://uclibc.org/uClibc.git;branch=${PV};protocol=git \
@@ -29,5 +29,6 @@ SRC_URI =
git://uclibc.org/uClibc.git;branch=${PV};protocol=git \
file://uclibc-execvpe.patch \
file://uclibc_scheduler_update.patch \
file://sync_file_range2.patch \
+
[OE-core] Minutes: OpenEmbedded eV Board meeting, 05-Aug-2011
Minutes: OpenEmbedded eV Board meeting, 05-Aug-2011 A short financial status update meeting Attendees: Michael Lauer (mickey) Philip Balister (Crofton) Florian Boor (florian) Denys Dmytriyenko (denix) 01) agenda: * Network switch money transfer * Financial obligations to OSUOSL * Other spendings 02) Network switch money transfer * florian reports that wire transfer to purchase the network switch has worked ** the paper receipt was sent back from recipients to florian ** money were sent in dollars, processing fees were split, around $15 03) Financial obligations to OSUOSL * still trying to figure out the amount to be donated to OSUOSL for hosting the OE infrastructure * Crofton managed to arrange a business trip to California to attend Yocto AB meeting (with a stop at Vancouver for LinuxCon!) ** to meet in person with OSUOSL team (Jeff Sheltren and others) ** get the overlall feel for how the team works and interacts with other parties ** discuss the expectation of OSUOSL for monetary compensation ** possibly get the specific details on the equipment and networking used @ OSUOSL for OE infrastructure 04) Other spendings * florian is in the process of assembling the event box * no additional expenses at this moment ** most of the items are already available ** eventually may need to purchase a nice box itself to hold the event gear ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] MINUTES: OE TSC meeting 21-Jul-2011
OE TSC meeting 21-Jul-2011 Attendees: Koen, Khem, Richard, Tom Apologies: Mark, Jefro Minutes: 01) choose a meeting chair khem 02) new topics - melo updates melo VM has some issues where it was dying almost every day per Tom its not hardware issue over next week git will move to the final VM and other services too will then follow 03) action items from last week -- mention on list about features and stabilisation (RP) done -- patches appearing on oe-dev, khem to send email regarding put stuff in meta-oe done, can take further -- write up which scripts to use (khem) 05) Status updates - elections delay between elections? need info from board - duration between votes -- TSC recommends 2 months to the board - oe-core tom is beating up siteinfo and cursing perl fray's multilib work against poky, but he also created a version against oe-core+bitbake -- RP to issue an RFC on fray's multilib stuff - bsp guidelines Phil posted querries on linux-yocto which was discussed in detail khem recommends a document on using tooling to extend linux-yocto to a different machine and another doc to use linux-yocto tooling for a different kernel sourcebase consider having a 'normal' linux recipe in OE core that people can bbappend Bruce volunteered -- add status for next week Paul Eggleton might be working on some OE wiki doc about OE-Core - metadata layer splitting recipes are moving from meta-oe into oe-core somewhat smoothly general idea is to find a way to split off sato, then rearrange the gnome stuff on into e.g. gmae and gnome-proper and clean up spurious deps - infrastructure Raw Transcript (21:11:23) khem: Lets start (21:11:37) RP__: fray is on vacation again (21:11:40) Tartarus: no new agenda items here (21:11:41) khem: we dont have scribe today so someone needs to send transcripts [to Jefro] (21:11:51) ***RP__ can do that (21:11:53) koen: I'm about to fall asleep, so I'd appreciate if someone else can chair (21:12:05) khem: I can (21:12:37) Tartarus: ok, khem chairs (21:12:47) khem: any new items ? (21:12:50) khem: for agenda (21:12:57) koen: not from me (21:13:12) khem: melo updates (21:13:19) khem: I would like to add (21:13:54) ***RP__ doesn't have additions (21:14:39) khem: http://pastebin.com/xa37DyL5 here (21:14:42) khem: agenda (21:14:54) khem: I think melo will fall to infra (21:15:09) khem: AIs from past (21:15:11) RP__: including Richard in case he wants to stop by? :) (21:16:32) ***RP__ guesses this is off an old agenda :) (21:16:59) RP__: Last week I took an AR to mention on list about features and stabilisation. I did that (21:17:06) khem: yes it was I am on a console and weird things can happen with links (21:17:21) khem: OK we can close that AR (21:17:50) khem: I sent email as well to request devs to post patches to new layering structure (21:17:56) khem: there were questions on that (21:18:32) RP__: Did those questions get good answers? (21:18:36) khem: no (21:19:03) RP__: Is the problem someone just needs to write them down or is there some unknown things which are the problem? (21:19:07) Tartarus: There's still a need for oe-core for dummies on the oe wiki (21:19:17) khem: yeah as Tartarus said (21:19:26) khem: people want step by step ramp up guide (21:19:28) Tartarus: no offense, meant, for the log readers, nbtw (21:19:34) Tartarus: I needed that post a while back myself :) (21:20:09) koen: the oe-core and angstrom setupscripts might be to automated for some people (21:20:21) koen: (and even the 3 steps for the angstrom scripts are too much for some) (21:20:36) khem: I guess we need to reply to that thread (21:21:09) khem: Moving on to Status (21:21:32) Tartarus: Well, hang on (21:21:36) RP__: I agree some further documentation would be good. Unfortunately I'm maxed out atm and am not sure I can help there :( (21:21:42) Tartarus: We need to write up Use this script or that script or (21:21:44) Tartarus: and someone needs to do that (21:22:05) khem: yes. I can take it further (21:22:11) Tartarus: ok, thanks (21:22:13) khem: and continue the thread (21:22:34) khem: we will follow up on this next week. (21:22:53) khem: Shall we move on to Status (21:23:00) Tartarus: ok w/ me (21:23:11) koen: the boards seemed to be confused about the elections (21:23:13) koen: -s (21:23:30) koen: so we can pick up the slack or wait (21:23:34) RP__: thanks khem! (21:23:41) khem: ok now RP is elected back does the second seat election got announced (21:24:02) RP__: Well, I guess the question is whether there is a delay between the elections or not? (21:24:24) khem: I guess we need to get this information from board (21:25:08) RP__: Going back in time, I think we said a 6 month stable period for the TSC was desireable so the interval was one month between (21:25:18) khem: ok (21:25:25) khem: which means August (21:25:28) RP__: although at the last meeting we did talk about 2 (21:25:43) koen: but with proposal, discuss and vote it is nearly a month if we do back to
Re: [OE-core] gcc version mismatch in sdk generation
On Mon, 2011-08-08 at 05:02 +, James Limbouris wrote: Hi, In oe-core, with Angstrom 2010.x, generating an sdk with: bitbake meta-toolchain-qte is giving me a toolchain with gcc-4.6.1 binaries in the i686 sysroot, but gcc-4.5.4 runtime libraries in the arm (target) sysroot. The sdk can't link until a symlink is installed to trick it into using the 4.5.4 libraries. I've checked the preferred versions, but they seem to be set consistently in the disto's conf file, at least as far as I can see. 'bitbake -s | grep gcc' gives: gcc :4.5-r39.1+svnr176640 gcc-cross :4.5-r39.2+svnr176640 gcc-cross-canadian-arm :4.5-r39.0+svnr176640 gcc-cross-initial :4.5-r39.0+svnr176640 gcc-cross-intermediate :4.5-r39.0+svnr176640 gcc-crosssdk:4.5-r39.0+svnr176640 gcc-crosssdk-initial:4.5-r39.0+svnr176640 gcc-crosssdk-intermediate :4.5-r39.0+svnr176640 gcc-runtime :4.5-r39.1+svnr176640 gcc-runtime-nativesdk:4.6.1+svnr175454-r5 :4.5-r39.1+svnr176640 gccmakedep 1:1.0.2-r3 libgcc :4.5-r39.1+svnr176640 libgcc-nativesdk :4.6.1+svnr175454-r3 :4.5-r39.1+svnr176640 The nativesdk and crosssdk versions need to match at the very least. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] gcc version mismatch in sdk generation
On Mon, Aug 8, 2011 at 6:33 PM, James Limbouris
ja...@digitalmatter.com.au wrote:
On Tue Aug 9 01:25:55 CEST 2011, Richard Purdie wrote:
On Mon, 2011-08-08 at 05:02 +, James Limbouris wrote:
Hi,
In oe-core, with Angstrom 2010.x, generating an sdk with:
bitbake meta-toolchain-qte
is giving me a toolchain with gcc-4.6.1 binaries in the i686 sysroot, but
gcc-4.5.4 runtime libraries in the arm (target) sysroot. The sdk can't
link until a symlink is installed to trick it into using the 4.5.4
libraries.
I've checked the preferred versions, but they seem to be set consistently
in the disto's conf file, at least as far as I can see.
'bitbake -s | grep gcc' gives:
gcc :4.5-r39.1+svnr176640
gcc-cross :4.5-r39.2+svnr176640
gcc-cross-canadian-arm :4.5-r39.0+svnr176640
gcc-cross-initial :4.5-r39.0+svnr176640
gcc-cross-intermediate :4.5-r39.0+svnr176640
gcc-crosssdk :4.5-r39.0+svnr176640
gcc-crosssdk-initial :4.5-r39.0+svnr176640
gcc-crosssdk-intermediate :4.5-r39.0+svnr176640
gcc-runtime :4.5-r39.1+svnr176640
gcc-runtime-nativesdk :4.6.1+svnr175454-r5
:4.5-r39.1+svnr176640
gccmakedep 1:1.0.2-r3
libgcc :4.5-r39.1+svnr176640
libgcc-nativesdk :4.6.1+svnr175454-r3
:4.5-r39.1+svnr176640
The nativesdk and crosssdk versions need to match at the very least.
Cheers,
Richard
Yes - that's what is so confusing. They seem to match in the Angstrom conf:
what does SDKGCCVERSION contain ?
#Everybody else can just use this:
ANGSTROM_GCC_VERSION ?= 4.5
ANGSTROM_BINUTILS_VERSION ?= 2.20.1
PREFERRED_VERSION_binutils ?=
${ANGSTROM_BINUTILS_VERSION}
PREFERRED_VERSION_binutils-cross ?=
${ANGSTROM_BINUTILS_VERSION}
PREFERRED_VERSION_binutils-crosssdk ?=
${ANGSTROM_BINUTILS_VERSION}
PREFERRED_VERSION_binutils-cross-canadian ?=
${ANGSTROM_BINUTILS_VERSION}
PREFERRED_VERSION_gcc ?= ${ANGSTROM_GCC_VERSION}
PREFERRED_VERSION_gcc-cross ?= ${ANGSTROM_GCC_VERSION}
PREFERRED_VERSION_gcc-cross-initial ?= ${ANGSTROM_GCC_VERSION}
PREFERRED_VERSION_gcc-cross-intermediate ?= ${ANGSTROM_GCC_VERSION}
PREFERRED_VERSION_gcc-cross-canadian ?= ${ANGSTROM_GCC_VERSION}
PREFERRED_VERSION_gcc-crosssdk ?= ${ANGSTROM_GCC_VERSION}
PREFERRED_VERSION_gcc-crosssdk-initial ?= ${ANGSTROM_GCC_VERSION}
PREFERRED_VERSION_gcc-crosssdk-intermediate ?= ${ANGSTROM_GCC_VERSION}
PREFERRED_VERSION_gcc-runtime ?= ${ANGSTROM_GCC_VERSION}
PREFERRED_VERSION_gcc-runtime-nativesdk ?= ${ANGSTROM_GCC_VERSION}
PREFERRED_VERSION_libgcc ?= ${ANGSTROM_GCC_VERSION}
PREFERRED_VERSION_libgcc-nativesdk ?= ${ANGSTROM_GCC_VERSION}
Regards
James Limbouris
___
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] gcc version mismatch in sdk generation
On Tuesday, 9 August 2011 9:40 AM, Khem Raj wrote:
On Mon, Aug 8, 2011 at 6:33 PM, James Limbouris
ja...@digitalmatter.com.au wrote:
On Tue Aug 9 01:25:55 CEST 2011, Richard Purdie wrote:
On Mon, 2011-08-08 at 05:02 +, James Limbouris wrote:
Hi,
In oe-core, with Angstrom 2010.x, generating an sdk with:
bitbake meta-toolchain-qte
is giving me a toolchain with gcc-4.6.1 binaries in the i686
sysroot, but
gcc-4.5.4 runtime libraries in the arm (target) sysroot. The sdk
can't link until a symlink is installed to trick it into using the 4.5.4
libraries.
I've checked the preferred versions, but they seem to be set
consistently in the disto's conf file, at least as far as I can see.
'bitbake -s | grep gcc' gives:
gcc :4.5-r39.1+svnr176640
gcc-cross :4.5-r39.2+svnr176640
gcc-cross-canadian-arm :4.5-r39.0+svnr176640
gcc-cross-initial :4.5-r39.0+svnr176640
gcc-cross-intermediate :4.5-r39.0+svnr176640
gcc-crosssdk :4.5-r39.0+svnr176640
gcc-crosssdk-initial :4.5-r39.0+svnr176640
gcc-crosssdk-intermediate :4.5-r39.0+svnr176640
gcc-runtime :4.5-r39.1+svnr176640
gcc-runtime-nativesdk :4.6.1+svnr175454-r5
:4.5-r39.1+svnr176640 gccmakedep
1:1.0.2-r3 libgcc
:4.5-r39.1+svnr176640 libgcc-nativesdk
:4.6.1+svnr175454-r3 :4.5-r39.1+svnr176640
The nativesdk and crosssdk versions need to match at the very least.
Cheers,
Richard
Yes - that's what is so confusing. They seem to match in the Angstrom conf:
what does SDKGCCVERSION contain ?
Hi,
Here are edited highlights from bitbake -e | grep -i GCC:
# PREFERRED_VERSION_gcc-cross-intermediate=${ANGSTROM_GCC_VERSION}
PREFERRED_VERSION_gcc-cross-intermediate=4.5
# PREFERRED_VERSION_gcc-cross-initial=${ANGSTROM_GCC_VERSION}
PREFERRED_VERSION_gcc-cross-initial=4.5
# SDKGCCVERSION=4.6%
SDKGCCVERSION=4.6%
# GCCVERSION=4.6%
GCCVERSION=4.6%
# PREFERRED_VERSION_gcc-cross=${ANGSTROM_GCC_VERSION}
PREFERRED_VERSION_gcc-cross=4.5
# PREFERRED_VERSION_gcc-runtime-nativesdk=${ANGSTROM_GCC_VERSION}
PREFERRED_VERSION_gcc-runtime-nativesdk=4.5
# PREFERRED_VERSION_gcc-crosssdk=${ANGSTROM_GCC_VERSION}
PREFERRED_VERSION_gcc-crosssdk=4.5
# PREFERRED_VERSION_libgcc=${ANGSTROM_GCC_VERSION}
PREFERRED_VERSION_libgcc=4.5
# PREFERRED_VERSION_libgcc-nativesdk=${ANGSTROM_GCC_VERSION}
PREFERRED_VERSION_libgcc-nativesdk=4.5
# PREFERRED_VERSION_gcc-cross-canadian=${ANGSTROM_GCC_VERSION}
PREFERRED_VERSION_gcc-cross-canadian=4.5
# PREFERRED_VERSION_gcc-cross-canadian-${TRANSLATED_TARGET_ARCH}=${GCCVERSION}
PREFERRED_VERSION_gcc-cross-canadian-arm=4.6%
# PREFERRED_VERSION_gcc-crosssdk-intermediate=${ANGSTROM_GCC_VERSION}
PREFERRED_VERSION_gcc-crosssdk-intermediate=4.5
# PREFERRED_VERSION_gcc=${ANGSTROM_GCC_VERSION}
PREFERRED_VERSION_gcc=4.5
# PREFERRED_VERSION_gcc-crosssdk-initial=${ANGSTROM_GCC_VERSION}
PREFERRED_VERSION_gcc-crosssdk-initial=4.5
# ANGSTROM_GCC_VERSION=4.5
ANGSTROM_GCC_VERSION=4.5
# PREFERRED_VERSION_gcc-runtime=${ANGSTROM_GCC_VERSION}
PREFERRED_VERSION_gcc-runtime=4.5
James
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] oe-init-build-env, scripts/oe-buildenv-internal: add error detecting for $BDIR
Cui, Dexuan wrote on 2011-08-04: Darren Hart wrote on 2011-08-04: On 08/04/2011 12:37 AM, Cui, Dexuan wrote: Please remember to include a description of the problem and the approach taken to fix it. This eliminates wasted time trying to decipher it later or by people unfamiliar with the history. This is important even for simple changes. In this case something like: The previous fix for a bug in Ubuntu 10.04 readlink, $COMMIT_ID, notified the user when a trailing slash was used. As there is no semantic difference, simply remove any trailing slashes and proceed without nagging the user. Thanks! I'll use the description. diff --git a/scripts/oe-buildenv-internal This shouldn't be a question. If the documented behavior of readlink is to return empty when the path doesn't exist, then assume this to be the case. The latest manual of readlink says readlink should ignore trailing slash. Also, it is a good idea to avoid contractions in printed error messages. echo 2 Error: the directory $PARENTDIR does not exist. Ok, I'll change doesn't to does not. Otherwise, this looks good to me. Please review the new patch (I paste it at the end of the mail, too) http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bug-671id=593e3506f4d4d9f6030100eac8c8e0af7f8ce3eb Hi Darren, Could you please comment on this new version of patch? I sent it out for several days ago. Maybe it was drowned in the mailing list. Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] bitbake.conf: Changed PSEUDO_LOCALSTATEDIR assignment to unconditional.
The pseudo executable sets the PSEUDO_LOCALSTATEDIR environment variable
to point to a sysroot location. During an initial cache build, in which
pseudo is not used as it is being built, the PSEUDO_LOCALSTATEDIR is set
to a per-package location by bitbake.conf, and baked into the cache.
If the cache is subsequently invalidated, bitbake may run under pseudo,
and rebuild it with the sysroot location baked into the cache. This
results in all packages using the same, persistent db, even on package
rebuild, which leads to permissions errors. Making the assignment
unconditional corrects this problem.
Signed-off-by: James Limbouris ja...@digitalmatter.com.au
---
meta/conf/bitbake.conf |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 6f0b42c..9a9ab53 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -557,7 +557,7 @@ SRCPV = ${@bb.fetch2.get_srcrev(d)}
SRC_URI = file://${FILE}
# Use pseudo as the fakeroot implementation
-PSEUDO_LOCALSTATEDIR ?= ${WORKDIR}/pseudo/
+PSEUDO_LOCALSTATEDIR = ${WORKDIR}/pseudo/
FAKEROOTENV = PSEUDO_PREFIX=${STAGING_DIR_NATIVE}${prefix_native}
PSEUDO_LOCALSTATEDIR=${PSEUDO_LOCALSTATEDIR}
PSEUDO_PASSWD=${STAGING_DIR_TARGET} PSEUDO_NOSYMLINKEXP=1 PSEUDO_DISABLED=0
FAKEROOTDIRS = ${PSEUDO_LOCALSTATEDIR}
PREFERRED_PROVIDER_virtual/fakeroot-native ?= pseudo-native
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] gcc version mismatch in sdk generation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/08/2011 06:52 PM, James Limbouris wrote:
On Tuesday, 9 August 2011 9:40 AM, Khem Raj wrote:
On Mon, Aug 8, 2011 at 6:33 PM, James Limbouris
ja...@digitalmatter.com.au wrote:
On Tue Aug 9 01:25:55 CEST 2011, Richard Purdie wrote:
On Mon, 2011-08-08 at 05:02 +, James Limbouris wrote:
Hi,
In oe-core, with Angstrom 2010.x, generating an sdk with:
bitbake meta-toolchain-qte
is giving me a toolchain with gcc-4.6.1 binaries in the i686
sysroot, but gcc-4.5.4 runtime libraries in the arm (target)
sysroot. The sdk can't link until a symlink is installed to
trick it into using the 4.5.4 libraries.
I've checked the preferred versions, but they seem to be set
consistently in the disto's conf file, at least as far as I
can see.
'bitbake -s | grep gcc' gives: gcc
:4.5-r39.1+svnr176640 gcc-cross
:4.5-r39.2+svnr176640 gcc-cross-canadian-arm
:4.5-r39.0+svnr176640 gcc-cross-initial
:4.5-r39.0+svnr176640 gcc-cross-intermediate
:4.5-r39.0+svnr176640 gcc-crosssdk
:4.5-r39.0+svnr176640 gcc-crosssdk-initial
:4.5-r39.0+svnr176640 gcc-crosssdk-intermediate
:4.5-r39.0+svnr176640 gcc-runtime
:4.5-r39.1+svnr176640 gcc-runtime-nativesdk
:4.6.1+svnr175454-r5 :4.5-r39.1+svnr176640 gccmakedep
1:1.0.2-r3 libgcc :4.5-r39.1+svnr176640 libgcc-nativesdk
:4.6.1+svnr175454-r3 :4.5-r39.1+svnr176640
The nativesdk and crosssdk versions need to match at the very
least.
Cheers,
Richard
Yes - that's what is so confusing. They seem to match in the
Angstrom conf:
what does SDKGCCVERSION contain ?
Hi,
Here are edited highlights from bitbake -e | grep -i GCC:
Can you try attached patch ? this is for meta-angstrom
Thx
- -Khem
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAk5AnHcACgkQuwUzVZGdMxSX3gCgiMm/l2eOjT992lsqKaxnfuno
QVUAniNpa6BtGGrOjwjxfGFSdYCoHMWm
=EeKC
-END PGP SIGNATURE-
From 8d6f9db776f30a2a88972fdb08856e0799839a25 Mon Sep 17 00:00:00 2001
From: Khem Raj raj.k...@gmail.com
Date: Mon, 8 Aug 2011 19:18:32 -0700
Subject: [PATCH] angstrom-2010.x.conf: Pin
PREFERRED_VERSION_gcc-cross-canadian-${TRANSLATED_TARGET_ARCH}
Signed-off-by: Khem Raj raj.k...@gmail.com
---
conf/distro/angstrom-2010.x.conf |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/conf/distro/angstrom-2010.x.conf b/conf/distro/angstrom-2010.x.conf
index e47561a..6622a1f 100644
--- a/conf/distro/angstrom-2010.x.conf
+++ b/conf/distro/angstrom-2010.x.conf
@@ -106,6 +106,7 @@ PREFERRED_VERSION_binutils ?= ${ANGSTROM_BINUTILS_VERSION
PREFERRED_VERSION_binutils-cross ?= ${ANGSTROM_BINUTILS_VERSION}
PREFERRED_VERSION_binutils-crosssdk ?= ${ANGSTROM_BINUTILS_VERSION}
PREFERRED_VERSION_binutils-cross-canadian?= ${ANGSTROM_BINUTILS_VERSION}
+PREFERRED_VERSION_gcc-cross-canadian-${TRANSLATED_TARGET_ARCH} ?= ${ANGSTROM_GCC_VERSION}
PREFERRED_VERSION_gcc?= ${ANGSTROM_GCC_VERSION}
PREFERRED_VERSION_gcc-cross ?= ${ANGSTROM_GCC_VERSION}
--
1.7.5.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] MINUTES: OE TSC meeting 21-Jul-2011
On Mon, Aug 8, 2011 at 6:09 PM, Jeff Osier-Mixon je...@jefro.net wrote: OE TSC meeting 21-Jul-2011 Attendees: Koen, Khem, Richard, Tom Apologies: Mark, Jefro Minutes: 01) choose a meeting chair khem 02) new topics - melo updates melo VM has some issues where it was dying almost every day per Tom its not hardware issue over next week git will move to the final VM and other services too will then follow 03) action items from last week -- mention on list about features and stabilisation (RP) done -- patches appearing on oe-dev, khem to send email regarding put stuff in meta-oe done, can take further -- write up which scripts to use (khem) 05) Status updates - elections delay between elections? need info from board - duration between votes -- TSC recommends 2 months to the board - oe-core tom is beating up siteinfo and cursing perl fray's multilib work against poky, but he also created a version against oe-core+bitbake -- RP to issue an RFC on fray's multilib stuff - bsp guidelines Phil posted querries on linux-yocto which was discussed in detail khem recommends a document on using tooling to extend linux-yocto to a different machine and another doc to use linux-yocto tooling for a different kernel sourcebase Not sure if people normally follow up to these meetings directly, but I see my name here .. so I'll follow up! Docs covering these are on the top of my list, and I'm working on them right now. consider having a 'normal' linux recipe in OE core that people can bbappend Bruce volunteered There's no reason why people can't bbappend to linux-yocto .. it works, it is just sub optimal compared to merging fixes and making them globally available. I'll make sure to write something up on this if there's interest. Bruce -- add status for next week Paul Eggleton might be working on some OE wiki doc about OE-Core - metadata layer splitting recipes are moving from meta-oe into oe-core somewhat smoothly general idea is to find a way to split off sato, then rearrange the gnome stuff on into e.g. gmae and gnome-proper and clean up spurious deps - infrastructure Raw Transcript (21:11:23) khem: Lets start (21:11:37) RP__: fray is on vacation again (21:11:40) Tartarus: no new agenda items here (21:11:41) khem: we dont have scribe today so someone needs to send transcripts [to Jefro] (21:11:51) ***RP__ can do that (21:11:53) koen: I'm about to fall asleep, so I'd appreciate if someone else can chair (21:12:05) khem: I can (21:12:37) Tartarus: ok, khem chairs (21:12:47) khem: any new items ? (21:12:50) khem: for agenda (21:12:57) koen: not from me (21:13:12) khem: melo updates (21:13:19) khem: I would like to add (21:13:54) ***RP__ doesn't have additions (21:14:39) khem: http://pastebin.com/xa37DyL5 here (21:14:42) khem: agenda (21:14:54) khem: I think melo will fall to infra (21:15:09) khem: AIs from past (21:15:11) RP__: including Richard in case he wants to stop by? :) (21:16:32) ***RP__ guesses this is off an old agenda :) (21:16:59) RP__: Last week I took an AR to mention on list about features and stabilisation. I did that (21:17:06) khem: yes it was I am on a console and weird things can happen with links (21:17:21) khem: OK we can close that AR (21:17:50) khem: I sent email as well to request devs to post patches to new layering structure (21:17:56) khem: there were questions on that (21:18:32) RP__: Did those questions get good answers? (21:18:36) khem: no (21:19:03) RP__: Is the problem someone just needs to write them down or is there some unknown things which are the problem? (21:19:07) Tartarus: There's still a need for oe-core for dummies on the oe wiki (21:19:17) khem: yeah as Tartarus said (21:19:26) khem: people want step by step ramp up guide (21:19:28) Tartarus: no offense, meant, for the log readers, nbtw (21:19:34) Tartarus: I needed that post a while back myself :) (21:20:09) koen: the oe-core and angstrom setupscripts might be to automated for some people (21:20:21) koen: (and even the 3 steps for the angstrom scripts are too much for some) (21:20:36) khem: I guess we need to reply to that thread (21:21:09) khem: Moving on to Status (21:21:32) Tartarus: Well, hang on (21:21:36) RP__: I agree some further documentation would be good. Unfortunately I'm maxed out atm and am not sure I can help there :( (21:21:42) Tartarus: We need to write up Use this script or that script or (21:21:44) Tartarus: and someone needs to do that (21:22:05) khem: yes. I can take it further (21:22:11) Tartarus: ok, thanks (21:22:13) khem: and continue the thread (21:22:34) khem: we will follow up on this next week. (21:22:53) khem: Shall we move on to Status (21:23:00) Tartarus: ok w/ me (21:23:11) koen: the boards seemed to be confused about the elections (21:23:13) koen: -s (21:23:30) koen: so we can pick up the slack or wait (21:23:34) RP__: thanks khem! (21:23:41) khem: ok now RP
Re: [OE-core] gcc version mismatch in sdk generation
On Tuesday, 9 August 2011 10:33 AM, Khem Raj wrote: On 08/08/2011 06:52 PM, James Limbouris wrote: On Tuesday, 9 August 2011 9:40 AM, Khem Raj wrote: On Mon, Aug 8, 2011 at 6:33 PM, James Limbouris ja...@digitalmatter.com.au wrote: On Tue Aug 9 01:25:55 CEST 2011, Richard Purdie wrote: On Mon, 2011-08-08 at 05:02 +, James Limbouris wrote: Hi, In oe-core, with Angstrom 2010.x, generating an sdk with: bitbake meta-toolchain-qte is giving me a toolchain with gcc-4.6.1 binaries in the i686 sysroot, but gcc-4.5.4 runtime libraries in the arm (target) sysroot. The sdk can't link until a symlink is installed to trick it into using the 4.5.4 libraries. I've checked the preferred versions, but they seem to be set consistently in the disto's conf file, at least as far as I can see. 'bitbake -s | grep gcc' gives: gcc :4.5-r39.1+svnr176640 gcc-cross :4.5-r39.2+svnr176640 gcc-cross-canadian-arm :4.5-r39.0+svnr176640 gcc-cross-initial :4.5-r39.0+svnr176640 gcc-cross-intermediate :4.5-r39.0+svnr176640 gcc-crosssdk :4.5-r39.0+svnr176640 gcc-crosssdk-initial :4.5-r39.0+svnr176640 gcc-crosssdk-intermediate :4.5-r39.0+svnr176640 gcc-runtime :4.5-r39.1+svnr176640 gcc-runtime-nativesdk :4.6.1+svnr175454-r5 :4.5-r39.1+svnr176640 gccmakedep 1:1.0.2-r3 libgcc :4.5-r39.1+svnr176640 libgcc-nativesdk :4.6.1+svnr175454-r3 :4.5-r39.1+svnr176640 The nativesdk and crosssdk versions need to match at the very least. Cheers, Richard Yes - that's what is so confusing. They seem to match in the Angstrom conf: what does SDKGCCVERSION contain ? Hi, Here are edited highlights from bitbake -e | grep -i GCC: Can you try attached patch ? this is for meta-angstrom Thx - -Khem Thanks Khem, that did the trick. James ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] eglibc: force GLIBC_EXTRA_OECONF to not be uset for nativesdk
Don't use GLIBC_EXTRA_OECONF for the nativesdk builds. Easiest solution
is to just override it settings. Otherwise we might pickup configure
options ment for the target build.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
meta/recipes-core/eglibc/eglibc.inc |1 +
meta/recipes-core/eglibc/eglibc_2.12.bb |2 +-
meta/recipes-core/eglibc/eglibc_2.13.bb |2 +-
3 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/eglibc/eglibc.inc
b/meta/recipes-core/eglibc/eglibc.inc
index 0f97f82..9088d02 100644
--- a/meta/recipes-core/eglibc/eglibc.inc
+++ b/meta/recipes-core/eglibc/eglibc.inc
@@ -31,6 +31,7 @@ require eglibc-options.inc
LEAD_SONAME = libc.so
GLIBC_EXTRA_OECONF ?=
+GLIBC_EXTRA_OECONF_virtclass-nativesdk =
INHIBIT_DEFAULT_DEPS = 1
ARM_INSTRUCTION_SET = arm
diff --git a/meta/recipes-core/eglibc/eglibc_2.12.bb
b/meta/recipes-core/eglibc/eglibc_2.12.bb
index ce16bd6..1a69bdc 100644
--- a/meta/recipes-core/eglibc/eglibc_2.12.bb
+++ b/meta/recipes-core/eglibc/eglibc_2.12.bb
@@ -1,7 +1,7 @@
require eglibc.inc
DEPENDS += gperf-native
-PR = r21
+PR = r22
SRCREV = 14158
diff --git a/meta/recipes-core/eglibc/eglibc_2.13.bb
b/meta/recipes-core/eglibc/eglibc_2.13.bb
index b0a8bfd..915eb32 100644
--- a/meta/recipes-core/eglibc/eglibc_2.13.bb
+++ b/meta/recipes-core/eglibc/eglibc_2.13.bb
@@ -3,7 +3,7 @@ require eglibc.inc
SRCREV = 14157
DEPENDS += gperf-native
-PR = r11
+PR = r12
PR_append = +svnr${SRCPV}
EGLIBC_BRANCH=eglibc-2_13
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] oe-init-build-env, scripts/oe-buildenv-internal: add error detecting for $BDIR
On 08/08/2011 07:13 PM, Cui, Dexuan wrote: Cui, Dexuan wrote on 2011-08-04: Darren Hart wrote on 2011-08-04: On 08/04/2011 12:37 AM, Cui, Dexuan wrote: Please remember to include a description of the problem and the approach taken to fix it. This eliminates wasted time trying to decipher it later or by people unfamiliar with the history. This is important even for simple changes. In this case something like: The previous fix for a bug in Ubuntu 10.04 readlink, $COMMIT_ID, notified the user when a trailing slash was used. As there is no semantic difference, simply remove any trailing slashes and proceed without nagging the user. Thanks! I'll use the description. diff --git a/scripts/oe-buildenv-internal This shouldn't be a question. If the documented behavior of readlink is to return empty when the path doesn't exist, then assume this to be the case. The latest manual of readlink says readlink should ignore trailing slash. Also, it is a good idea to avoid contractions in printed error messages. echo 2 Error: the directory $PARENTDIR does not exist. Ok, I'll change doesn't to does not. Otherwise, this looks good to me. Please review the new patch (I paste it at the end of the mail, too) http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bug-671id=593e3506f4d4d9f6030100eac8c8e0af7f8ce3eb Hi Darren, Could you please comment on this new version of patch? I sent it out for several days ago. Maybe it was drowned in the mailing list. Hi Dexuan, sorry for the delay, I have been on jury duty for a week, just getting back now. From 593e3506f4d4d9f6030100eac8c8e0af7f8ce3eb Mon Sep 17 00:00:00 2001 From: Dexuan Cui dexuan@intel.com Date: Thu, 04 Aug 2011 06:53:20 + Subject: scripts/oe-buildenv-internal: improve the error detecting for $BDIR Thanks a lot to Darren Hart and Paul Eggleton's suggestions! A description of this improvement from Darren is: Drop the above two lines, we don't need these in the permanent git history :-) Simply adding a pair of CC lines below the Signed-off-by for Paul and myself is sufficient to indicate our involvement. If a significant portion of the patch had been authored by either Paul or myself, then getting our permission to include our Signed-off-by would be appropriate. In this case, a simple CC will suffice. The previous fix for a bug in Ubuntu 10.04 readlink, be2a2764d8ceb398d81714661e6f199c8b11946c, notified the user when a trailing slash was used. As there is no semantic difference, simply remove any trailing slashes and proceed without nagging the user. Signed-off-by: Dexuan Cui dexuan@intel.com CC: Darren Hart dvh...@linux.intel.com CC: Paul Eggleton paul.eggle...@linux.intel.com --- diff --git a/scripts/oe-buildenv-internal b/scripts/oe-buildenv-internal index 117b0c5..9988c9f 100755 --- a/scripts/oe-buildenv-internal +++ b/scripts/oe-buildenv-internal @@ -28,14 +28,22 @@ if [ x$BDIR = x ]; then if [ x$1 = x ]; then BDIR=build else -BDIR=`readlink -f $1` -if [ -z $BDIR ]; then -if expr $1 : '.*/$' /dev/null; then -echo 2 Error: please remove any trailing / in the argument. -else -PARENTDIR=`dirname $1` -echo 2 Error: the directory $PARENTDIR doesn't exist? -fi +BDIR=$1 +if [ $BDIR = / ]; then +echo 2 Error: / is not supported as a build directory. I understand wanting to use stderr, but I don't see the 2 very often in our shell scripts. Is this common practice? If so, it's fine, I'm just wondering. +return 1 +fi + +# Remove possible trailing slash. This is used to work around slashes +# buggy readlink of Ubuntu 10.04 that doesn't ignore trailing slash a buggys/of/in/ slashes +# and hence readlink -f new_dir_to_be_created/ returns empty. +# See YOCTO #671 for details. Please don't include references to bug numbers in the code. Imagine what it would look like if we included every bug in the source! :-) Reference the bug in the git commit comment header. +BDIR=`echo $BDIR | sed -re 's|/+$||'` + +BDIR=`readlink -f $BDIR` +if [ -z $BDIR ]; then +PARENTDIR=`dirname $1` +echo 2 Error: the directory $PARENTDIR does not exist? return 1 fi fi With the trivial changes mentioned above, this looks good to me. -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
