Re: [OE-core] [PATCH 1/1] oe-init-build-env, scripts/oe-buildenv-internal: add error detecting for $BDIR
On 08/03/2011 07:25 PM, Cui, Dexuan wrote:
Darren Hart wrote on 2011-08-03:
On 08/02/2011 11:46 PM, Cui, Dexuan wrote:
Hi Darren, thanks for the suggestion! I considered the idea too,
however, if we use the idea, it looks not that simple to gracefully
and concisely handle the case if a user (by accident or by prank)
passes / as $1 here, i.e., readlink -f would fail. So I didn't do
that.
Hi Dexuan,
I had not considered that case, good catch. I can't think of a valid
use case for BDIR=/. Not only are write permissions unlikely, but
Agree.
the build would conflict with /tmp as well.
if [ $BDIR == / ]; then
echo ERROR: / is not supported as a build directory.
exit 1
fi
BDIR=${BDIR%/}
Hi Darren,
This seems good to me.
Looks ${BDIR%/} can only remove one trailing slash. Do we need to consider
more-than-one-slashes, e.g., $BDIR is /home/poky/build///? :-) (We could
use sed: BDIR=`echo $BDIR | sed -re 's|/+$||'` , but I'm not sure if it
deserves the complexity)
Darren, could you please help to make a patch?
I really have few experience about how to validate a user's input. :-)
At some point I think it's fair for us to say so don't do that when
someone says if I pass this random string of garbage to the script it
gives up and uses the current directory.
As for a patch, I'm on Jury duty all this week and only get to a very
small percentage of my tasks. I would appreciate if you would try to put
one together using the above source snippet, with the suggested changes
from Paul of course. Then just send it to the list with Paul and myself
on CC. We'll review and provided additional Acked-by's to confirm we're
all happy with the end result.
I would suggest you include a patch to first revert the previous patch
that was applied to address this issue.
--
Darren
I would be happy with something like the above (untested). It seems a
lot more clear and direct to me.
In any case, I don't see any reason to bail out and ask the user to
remove a trailing slash. We should just do this and move on. There is
no semantic difference from the user's perspective, and the blame is
to be placed on readlink, not the user.
I agree.
Thanks,
-- Dexuan
--
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
[OE-core] [PATCH] prelink: Add lib64 dirs to prelink.conf
Handle multlib or cases that baselib is lib64.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
meta/recipes-devtools/prelink/prelink/prelink.conf |8
meta/recipes-devtools/prelink/prelink_git.bb |2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/meta/recipes-devtools/prelink/prelink/prelink.conf
b/meta/recipes-devtools/prelink/prelink/prelink.conf
index c5a4f4a..ed30c28 100644
--- a/meta/recipes-devtools/prelink/prelink/prelink.conf
+++ b/meta/recipes-devtools/prelink/prelink/prelink.conf
@@ -12,7 +12,7 @@
-l /usr/bin
-l /usr/X11R6/bin
-l /usr/games
--l /usr/local/lib
--l /lib
--l /usr/lib
--l /usr/X11R6/lib
+-l /usr/local/lib{,64}
+-l /lib{,64}
+-l /usr/lib{,64}
+-l /usr/X11R6/lib{,64}
diff --git a/meta/recipes-devtools/prelink/prelink_git.bb
b/meta/recipes-devtools/prelink/prelink_git.bb
index c653d4d..bb95da7 100644
--- a/meta/recipes-devtools/prelink/prelink_git.bb
+++ b/meta/recipes-devtools/prelink/prelink_git.bb
@@ -10,7 +10,7 @@ LICENSE = GPLv2
LIC_FILES_CHKSUM = file://COPYING;md5=c93c0550bd3173f4504b2cbd8991e50b
SRCREV = ac461e73b17253a4da25c5aafeac7193b553156c
PV = 1.0+git${SRCPV}
-PR = r4
+PR = r5
#
# The cron script attempts to re-prelink the system daily -- on
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [oe-core] ti-codec-engine build error
I have been working on migrating the codec-engine recipe from OE classic to OE-core, As of now, do_compile stage fails as it expects bin/ar in the toolchain path. What would be a correct fix for this? My meta-texasinstruments git tree is at: https://github.com/joelagnel/meta-texasinstruments Here is a build log: [..] # clv5T package/package_ti.xdais.dm.examples.viddec1_copy.c ... /home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-eglibc/sysroots/i686-linux/usr/bin/armv7a-angstrom-linux-gnueabi/arm-angstrom-linux-gnueabi-gcc -c -MD -MF package/lib/lib/release/viddec1_copy/package/package_ti.xdais.dm.examples.viddec1_copy.ov5T.dep -x c -fPIC -Wunused -Wall -fno-strict-aliasing -march=armv5t -Dfar= -Dxdc_target_name__=GCArmv5T -Dxdc_target_types__=gnu/targets/arm/std.h -Dxdc_bld__profile_release -Dxdc_bld__vers_1_0_4_5_4 -O2 -ffunction-sections -fdata-sections -I. -I/home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-eglibc/work/beagleboard-angstrom-linux-gnueabi/ti-codec-engine-2_26_01_09-r102a/codec_engine_2_26_01_09/examples/ti/sdo/ce/examples/codecs/viddec1_copy/../../../../../.. -I/home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-eglibc/work/beagleboard-angstrom-linux-gnueabi/ti-codec-engine-2_26_01_09-r102a/codec_engine_2_26_01_09/packages -I/home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-eglibc/sysroots/beagleboard/usr/share/ti/ti-xdais-tree/packages -I/home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-eglibc/sysroots/beagleboard/usr/share/ti/ti-linuxutils-tree/packages -I/home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-eglibc/sysroots/beagleboard/usr/share/ti/ti-framework-components-tree/packages -I/home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-eglibc/sysroots/beagleboard/usr/share/ti/ti-biosutils-tree/packages -I/home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-eglibc/sysroots/beagleboard/usr/share/ti/ti-local-power-manager-tree/packages -I/home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-eglibc/sysroots/beagleboard/usr/share/ti/ti-edma3lld-tree/packages -I/home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-eglibc/sysroots/beagleboard/usr/share/ti/ti-dspbios-tree/packages -I/home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-eglibc/sysroots/beagleboard/usr/share/ti/ti-dsplink-tree -I/home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-eglibc/sysroots/beagleboard/usr/share/ti/ti-xdctools-tree/packages -I../../../../.. -o package/lib/lib/release/viddec1_copy/package/package_ti.xdais.dm.examples.viddec1_copy.ov5T package/package_ti.xdais.dm.examples.viddec1_copy.c rm -f package/lib/lib/release/viddec1_copy/viddec1_copy.ov5T # # clv5T viddec1_copy.c ... /home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-eglibc/sysroots/i686-linux/usr/bin/armv7a-angstrom-linux-gnueabi/arm-angstrom-linux-gnueabi-gcc -c -MD -MF package/lib/lib/release/viddec1_copy/viddec1_copy.ov5T.dep -x c -fPIC -Wunused -Wall -fno-strict-aliasing -march=armv5t -Dfar= -Dxdc_target_name__=GCArmv5T -Dxdc_target_types__=gnu/targets/arm/std.h -Dxdc_bld__profile_release -Dxdc_bld__vers_1_0_4_5_4 -O2 -ffunction-sections -fdata-sections -I. -I/home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-eglibc/work/beagleboard-angstrom-linux-gnueabi/ti-codec-engine-2_26_01_09-r102a/codec_engine_2_26_01_09/examples/ti/sdo/ce/examples/codecs/viddec1_copy/../../../../../.. -I/home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-eglibc/work/beagleboard-angstrom-linux-gnueabi/ti-codec-engine-2_26_01_09-r102a/codec_engine_2_26_01_09/packages -I/home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-eglibc/sysroots/beagleboard/usr/share/ti/ti-xdais-tree/packages -I/home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-eglibc/sysroots/beagleboard/usr/share/ti/ti-linuxutils-tree/packages -I/home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-eglibc/sysroots/beagleboard/usr/share/ti/ti-framework-components-tree/packages -I/home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-eglibc/sysroots/beagleboard/usr/share/ti/ti-biosutils-tree/packages -I/home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-eglibc/sysroots/beagleboard/usr/share/ti/ti-local-power-manager-tree/packages -I/home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-eglibc/sysroots/beagleboard/usr/share/ti/ti-edma3lld-tree/packages -I/home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-eglibc/sysroots/beagleboard/usr/share/ti/ti-dspbios-tree/packages -I/home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-eglibc/sysroots/beagleboard/usr/share/ti/ti-dsplink-tree -I/home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-eglibc/sysroots/beagleboard/usr/share/ti/ti-xdctools-tree/packages -I../../../../.. -o
[OE-core] [PATCH] tune/arch-powerpc64: include arch-powerpc.inc to keep things in sync
Added a DEFAULTTUNE setting and included arch-powerpc.inc. This way we
pick up the changes to TUNE_PKGARCH and things should be kept more in
sync going forward.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
.../machine/include/powerpc/arch-powerpc64.inc |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/meta/conf/machine/include/powerpc/arch-powerpc64.inc
b/meta/conf/machine/include/powerpc/arch-powerpc64.inc
index a965d59..7ef8ddc 100644
--- a/meta/conf/machine/include/powerpc/arch-powerpc64.inc
+++ b/meta/conf/machine/include/powerpc/arch-powerpc64.inc
@@ -1,3 +1,7 @@
+DEFAULTTUNE ?= powerpc64
+
+require conf/machine/include/powerpc/arch-powerpc.inc
+
TUNEVALID[m64] = Power ELF64 standard ABI
TUNE_CONFLICTS[m64] = m32 nf
TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, m64, -m64, , d)}
--
1.7.3.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] bitbake: Allow seting of baselib
Allow for baselib to be set to something other than 'lib'. This is useful
for the 64-bit arch cases in which we want baselib set to 'lib64'.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
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..c50ffb9 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -7,7 +7,7 @@
#
# Used by multilib code to change the library paths
-baselib = lib
+baselib = ${@d.getVar('BASE_LIB', True) or 'lib'}
# Path prefixes
export base_prefix =
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] arch-powerpc64: set BASE_LIB to 'lib64'
Default baselib location on ppc64 to 'lib64'. This matches what other
Linux ppc64 distro's have done to date and keeps thing in sync for the
multilib case.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
.../machine/include/powerpc/arch-powerpc64.inc |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/meta/conf/machine/include/powerpc/arch-powerpc64.inc
b/meta/conf/machine/include/powerpc/arch-powerpc64.inc
index 7ef8ddc..7681eae 100644
--- a/meta/conf/machine/include/powerpc/arch-powerpc64.inc
+++ b/meta/conf/machine/include/powerpc/arch-powerpc64.inc
@@ -10,3 +10,4 @@ TUNE_ARCH .= ${@bb.utils.contains(TUNE_FEATURES, [ m64
], powerpc64, ,
AVAILTUNES += powerpc64
TUNE_FEATURES_tune-powerpc64 ?= m64 fpu-hard
BASE_LIB_tune-powerpc64 = lib64
+BASE_LIB = lib64
--
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] [oe-core] ti-codec-engine build error
Op 4 aug. 2011, om 08:07 heeft Joel A Fernandes het volgende geschreven:
I have been working on migrating the codec-engine recipe from OE
classic to OE-core,
As of now, do_compile stage fails as it expects bin/ar in the
toolchain path. What would be a correct fix for this?
My meta-texasinstruments git tree is at:
https://github.com/joelagnel/meta-texasinstruments
Here is a build log:
[..]
# clv5T viddec1_copy.c ...
/home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-eglibc/sysroots/i686-linux/usr/bin/armv7a-angstrom-linux-gnueabi/arm-angstrom-linux-gnueabi-gcc
-c -MD -MF package/lib/lib/release/viddec1_copy/viddec1_copy.ov5T.dep
So here it's picking up TOOLCHAIN_PATH correctly thru CGTOOLS_V5T
make[1]:
/home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-eglibc/sysroots/i686-linux/usr/bin/armv7a-angstrom-linux-gnueabi/arm-angstrom-linux-gnueabi/bin/ar:
But it seems to want to call ar differently. In other recipes we add the
following to make:
AR=${TOOLCHAIN_PATH}/${TARGET_PREFIX}ar \
ARCHIVER=${TOOLCHAIN_PATH}/${TARGET_PREFIX}ar \
And a minor nit: please copy over only 1 version when moving things to meta-ti,
the latest version is usually fine.
regards,
Koen
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] 64-bit gcc hack patch /
What is meta/recipes-devtools/gcc/gcc-4.6/64bithack.patch really accomplishing at this point? Its not clear to me what benefit or what is really impacted by the following change: MULTILIB_OPTIONS = m64/m32 -MULTILIB_DIRNAMES = 64 32 -MULTILIB_OSDIRNAMES = ../lib64 $(if $(wildcard $(shell echo $(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib) +MULTILIB_DIRNAMES = . 32 +MULTILIB_OSDIRNAMES = . $(if $(wildcard $(shell echo $(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib) Trying to decide if the ppc equivalent of this patch is really needed or not. - k ___ 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/3 Khem Raj raj.k...@gmail.com: There is a smart script in scripts/ dir that you could use something like this runqemu /var/oe-core/tmp-eglibc/deploy/images/qemuarm/zImage-qemuarm.bin /var/oe-core/tmp-eglibc/deploy/images/qemuarm/console-image-qemuarm.ext2 and it will setup everything (even networking) for you Already tried this one, but for some unknown reasons it doesn't work, I get the following output: - samuel@S-Linux:/var/oe-core/setup-scripts$ 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: sudo runqemu-ifup gid native-sysroot-basedir samuel@S-Linux:/var/oe-core/setup-scripts$ - This is all, no QEMU window appears or any other messages, or do I have run something else. For remote debugging purpose I wrote a generic script that will set up a tap and bridge interface and restores the network connection after qemu closes. This script can also run QEMU with standard network settings. Basically runqemu and my scripts should do the same thing(?), but since runqemu doesn't work for me I made my own scripts (also it won't need sudo if the standard network option is used). The scripts are attached in this mail, to run the script you could use sh /somedir/generic_qemu_loader.sh --help. This script however may not work on other systems than ubuntu, I share it only for information exchange purpose. If you still want to use it, keep in thought that I am a beginner in shell coding! The difference between the standard network settings and the bridge/tap interfaces is, that the standard network only supports outgoing TCP and UDP connections while the bridge/tap interface can be used to host, for example, a gdbserver. Regards Samuel generic_qemu_loader.tar.gz Description: GNU Zip compressed data ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] eglibc testing?
On Thu, 2011-06-30 at 07:29 -0700, Khem Raj wrote: On 06/30/2011 03:32 AM, Phil Blundell wrote: On Thu, 2011-06-16 at 16:18 -0700, Khem Raj wrote: Yes I think I should put together my mechanism somewhere and post it and dejaGNU setup I use for cross testing Did you get a chance to do this at all? so far no. Let me collect them and make sure they work Just a quick reminder about this :-) p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] eglibc-package.inc: Fixed error in referencing PKGSUFFIX
[YOCTO #1329] Added the missing $ when referencing PKGSUFFIX in FILES_*
variables set.
Signed-off-by: Lianhao Lu lianhao...@intel.com
---
meta/recipes-core/eglibc/eglibc-package.inc |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-core/eglibc/eglibc-package.inc
b/meta/recipes-core/eglibc/eglibc-package.inc
index 77519d2..5308bb9 100644
--- a/meta/recipes-core/eglibc/eglibc-package.inc
+++ b/meta/recipes-core/eglibc/eglibc-package.inc
@@ -56,10 +56,10 @@ libc_baselibs = ${base_libdir}/libcrypt*.so.*
${base_libdir}/libcrypt-*.so ${ba
FILES_${PN} = ${libc_baselibs} ${libexecdir}/*
${@base_conditional('USE_LDCONFIG', '1', '${base_sbindir}/ldconfig
${sysconfdir}/ld.so.conf', '', d)}
FILES_ldd${PKGSUFFIX} = ${bindir}/ldd
FILES_libsegfault${PKGSUFFIX} = ${base_libdir}/libSegFault*
-FILES_libcidn{PKGSUFFIX} = ${base_libdir}/libcidn-*.so
${base_libdir}/libcidn.so.*
-FILES_libmemusage{PKGSUFFIX} = ${base_libdir}/libmemusage.so
-FILES_eglibc-extra-nss{PKGSUFFIX} = ${base_libdir}/libnss_*-*.so
${base_libdir}/libnss_*.so.*
-FILES_sln{PKGSUFFIX} = /sbin/sln
+FILES_libcidn${PKGSUFFIX} = ${base_libdir}/libcidn-*.so
${base_libdir}/libcidn.so.*
+FILES_libmemusage${PKGSUFFIX} = ${base_libdir}/libmemusage.so
+FILES_eglibc-extra-nss${PKGSUFFIX} = ${base_libdir}/libnss_*-*.so
${base_libdir}/libnss_*.so.*
+FILES_sln${PKGSUFFIX} = /sbin/sln
FILES_${PN}-pic = ${libdir}/*_pic.a ${libdir}/*_pic.map ${libdir}/libc_pic/
FILES_libsotruss${PKGSUFFIX} = ${libdir}/audit/sotruss-lib.so
FILES_${PN}-dev_append += ${bindir}/rpcgen ${libdir}/*.a \
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] Fixed error in referencing PKGSUFFIX
$ was missing when referencing PKGSUFFIX in eglibc-package.inc.
This patch fixed the BUG #1329.
The following changes since commit fbb734e5753655de30c82c0a036c9043820e02cb:
Dongxiao Xu (1):
multilib: Use BPN instead of PN for style like lib${PN}
are available in the git repository at:
git://git.yoctoproject.org/poky-contrib llu/bug1329
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=llu/bug1329
Lianhao Lu (1):
eglibc-package.inc: Fixed error in referencing PKGSUFFIX
meta/recipes-core/eglibc/eglibc-package.inc |8
1 files changed, 4 insertions(+), 4 deletions(-)
___
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] eglibc-package.inc: Fixed error in referencing PKGSUFFIX
On Thu, 2011-08-04 at 18:36 +0800, Lianhao Lu wrote:
[YOCTO #1329] Added the missing $ when referencing PKGSUFFIX in FILES_*
variables set.
Signed-off-by: Lianhao Lu lianhao...@intel.com
---
meta/recipes-core/eglibc/eglibc-package.inc |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-core/eglibc/eglibc-package.inc
b/meta/recipes-core/eglibc/eglibc-package.inc
index 77519d2..5308bb9 100644
--- a/meta/recipes-core/eglibc/eglibc-package.inc
+++ b/meta/recipes-core/eglibc/eglibc-package.inc
@@ -56,10 +56,10 @@ libc_baselibs = ${base_libdir}/libcrypt*.so.*
${base_libdir}/libcrypt-*.so ${ba
FILES_${PN} = ${libc_baselibs} ${libexecdir}/*
${@base_conditional('USE_LDCONFIG', '1', '${base_sbindir}/ldconfig
${sysconfdir}/ld.so.conf', '', d)}
FILES_ldd${PKGSUFFIX} = ${bindir}/ldd
FILES_libsegfault${PKGSUFFIX} = ${base_libdir}/libSegFault*
-FILES_libcidn{PKGSUFFIX} = ${base_libdir}/libcidn-*.so
${base_libdir}/libcidn.so.*
-FILES_libmemusage{PKGSUFFIX} = ${base_libdir}/libmemusage.so
-FILES_eglibc-extra-nss{PKGSUFFIX} = ${base_libdir}/libnss_*-*.so
${base_libdir}/libnss_*.so.*
-FILES_sln{PKGSUFFIX} = /sbin/sln
+FILES_libcidn${PKGSUFFIX} = ${base_libdir}/libcidn-*.so
${base_libdir}/libcidn.so.*
+FILES_libmemusage${PKGSUFFIX} = ${base_libdir}/libmemusage.so
+FILES_eglibc-extra-nss${PKGSUFFIX} = ${base_libdir}/libnss_*-*.so
${base_libdir}/libnss_*.so.*
+FILES_sln${PKGSUFFIX} = /sbin/sln
FILES_${PN}-pic = ${libdir}/*_pic.a ${libdir}/*_pic.map ${libdir}/libc_pic/
FILES_libsotruss${PKGSUFFIX} = ${libdir}/audit/sotruss-lib.so
FILES_${PN}-dev_append += ${bindir}/rpcgen ${libdir}/*.a \
Thanks, merged to master with added PR bumps.
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 1/1] oe-init-build-env, scripts/oe-buildenv-internal: add error detecting for $BDIR
On Tue, 2011-08-02 at 21:06 -0700, Darren Hart wrote: On 08/02/2011 04:43 AM, Richard Purdie wrote: On Tue, 2011-08-02 at 14:08 +0800, Dexuan Cui wrote: [YOCTO #671] readlink -f in Ubuntu 10.04 is buggy: it doesn't ignore a trailing / (e.g., readlink -f /tmp/non-existent-dir/ returns nothing, but according to http://www.gnu.org/s/coreutils/manual/coreutils.pdf it should do that -- hence we get bug 671. It seems Ubuntu 10.10 or even later Ubuntu 11.04, and other Linux distributions(e.g., Open Suse 11.4) haven't such an issue. So I think we should detect this and ask Ubuntu 10.04 users to avoid supply a path with trailing slash here. Moreever, I also add the detection of non-existent path, e.g., source oe-init-build-env /non-existent-dir/build can be detected and we'll print an error msg. And, if we get errors in oe-buildenv-internal, we should stop the script and shouldn't further run. Signed-off-by: Dexuan Cui dexuan@intel.com Merged to master, thanks. For a patch to address a relatively benign bug I thought the standard procedure would be for it to await feedback for more than 5 hours. I was hoping to have an opportunity to review this fix as I was working with the team in root causing the bug. It is near impossible for me to tell who (if anyone) is working jointly on an issue or expecting to review a patch. All I see are the complaints when things don't merge promptly or something less than ideal merges too soon (i.e. I can't win) :(. If a group of people want to review and ack a patch before its accepted can you please indicate this somewhere in the patch so I stand a chance of figuring out what people are expecting me to do... In this case the change isn't bad, there are just ways to improve it so please send follow up patches. 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 1/1] oe-init-build-env, scripts/oe-buildenv-internal: add error detecting for $BDIR
On 08/04/2011 05:07 AM, Richard Purdie wrote: On Tue, 2011-08-02 at 21:06 -0700, Darren Hart wrote: On 08/02/2011 04:43 AM, Richard Purdie wrote: On Tue, 2011-08-02 at 14:08 +0800, Dexuan Cui wrote: [YOCTO #671] readlink -f in Ubuntu 10.04 is buggy: it doesn't ignore a trailing / (e.g., readlink -f /tmp/non-existent-dir/ returns nothing, but according to http://www.gnu.org/s/coreutils/manual/coreutils.pdf it should do that -- hence we get bug 671. It seems Ubuntu 10.10 or even later Ubuntu 11.04, and other Linux distributions(e.g., Open Suse 11.4) haven't such an issue. So I think we should detect this and ask Ubuntu 10.04 users to avoid supply a path with trailing slash here. Moreever, I also add the detection of non-existent path, e.g., source oe-init-build-env /non-existent-dir/build can be detected and we'll print an error msg. And, if we get errors in oe-buildenv-internal, we should stop the script and shouldn't further run. Signed-off-by: Dexuan Cui dexuan@intel.com Merged to master, thanks. For a patch to address a relatively benign bug I thought the standard procedure would be for it to await feedback for more than 5 hours. I was hoping to have an opportunity to review this fix as I was working with the team in root causing the bug. It is near impossible for me to tell who (if anyone) is working jointly on an issue or expecting to review a patch. All I see are the complaints when things don't merge promptly or something less than ideal merges too soon (i.e. I can't win) :(. In this case I was trying to refer back to what I had understood to be the norm (waiting for 24 hours) to allow for feedback. I know it wasn't a hard rule, but I didn't see any degree of urgency with this patch. If your process is different than my understanding, please correct my thinking so I know what to expect going forward. If not, then the above is just meant as a friendly reminder that I, at least, am operating under the assumption that patches will have a 24 hour review window unless there is a pressing need to merge them sooner. If a group of people want to review and ack a patch before its accepted can you please indicate this somewhere in the patch so I stand a chance of figuring out what people are expecting me to do... This is a critical part of the patch review process. 100% agreed. The send-pull-requuest script knows to look for the CC: line below the Signed-off-by for people whose input is relevant to the patch. Please make use of this function to first notify them (people who helped on the bug, recipe authors, maintainers, bug introducer, or people who have recently modified the files in question) that a change is on the list that may benefit from their review and second to notify the person responsible for merging the patch that there are others involved who should have an opportunity to provide feedback before the patch is merged. Thanks, -- 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
Re: [OE-core] [PATCH 1/1] oe-init-build-env, scripts/oe-buildenv-internal: add error detecting for $BDIR
On 08/04/2011 12:37 AM, Cui, Dexuan wrote:
Darren Hart wrote on 2011-08-04:
As for a patch, I'm on Jury duty all this week and only get to a very
small percentage of my tasks. I would appreciate if you would try to
put one together using the above source snippet, with the suggested
changes from Paul of course. Then just send it to the list with Paul
and myself on CC. We'll review and provided additional Acked-by's to
confirm we're all happy with the end result.
I made a patch according to your and Paul's suggestions.
Please review the patch (I also pasted at the end of this mail):
http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bug-671id=13cd1538bc5be078039be2054f117610e2425951
Please note I use sed to remove any trailing slash since ${BDIR%/} can only
remove one trailing slash and this can cause issue, e.g., if $1 is
/tmp/build_new//, *on Ubuntu 10.04*, we would get a weird msg Error: the
directory /tmp doesn't exist?
I would suggest you include a patch to first revert the previous patch
that was applied to address this issue.
I'm trying to patch the first patch to save a revert commit... :-)
Thanks,
-- Dexuan
commit 13cd1538bc5be078039be2054f117610e2425951
Author: Dexuan Cui dexuan@intel.com
Date: Thu Aug 4 14:53:20 2011 +0800
scripts/oe-buildenv-internal: improve the error detecting for $BDIR
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 a lot to Darren Hart and Paul Eggleton's sugestion!
Signed-off-by: Dexuan Cui dexuan@intel.com
diff --git a/scripts/oe-buildenv-internal b/scripts/oe-buildenv-internal
index 117b0c5..4a44174 100755
--- a/scripts/oe-buildenv-internal
+++ b/scripts/oe-buildenv-internal
@@ -28,14 +28,16 @@ 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.
+return 1
+fi
+BDIR=`echo $BDIR | sed -re 's|/+$||'`
+BDIR=`readlink -f $BDIR`
+if [ -z $BDIR ]; then
+PARENTDIR=`dirname $1`
+echo 2 Error: the directory $PARENTDIR doesn't exist?
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. Also, it is a good idea to avoid contractions in printed error
messages.
echo 2 Error: the directory $PARENTDIR does not exist.
Otherwise, this looks good to me.
Thanks Dexuan!
--
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
Re: [OE-core] [PATCH 3/9] Various site files: Drop monotone
On Wed, 2011-07-27 at 15:56 -0700, Tom Rini wrote:
Not in oe-core nor meta-oe and based on oe.dev, possibly incomplete.
Signed-off-by: Tom Rini tom_r...@mentor.com
---
meta/site/arm-common|3 ---
meta/site/arm-linux |3 ---
meta/site/common-glibc |3 ---
meta/site/ix86-common |3 ---
meta/site/mips-linux|5 -
meta/site/mips-linux-uclibc |5 -
meta/site/mipsel-linux |5 -
meta/site/powerpc32-linux |4
meta/site/sh-common |3 ---
9 files changed, 0 insertions(+), 34 deletions(-)
diff --git a/meta/site/arm-common b/meta/site/arm-common
index 2129298..7317a13 100644
--- a/meta/site/arm-common
+++ b/meta/site/arm-common
@@ -116,9 +116,6 @@ with_broken_putenv=${with_broken_putenv=no}
# links
ac_cv_lib_png_png_create_info_struct=${ac_cv_lib_png_png_create_info_struct=yes}
-# mono
-cv_mono_sizeof_sunpath=108
-
# mysql
mysql_cv_func_atomic_sub=${mysql_cv_func_atomic_sub=no}
mysql_cv_func_atomic_add=${mysql_cv_func_atomic_add=no}
Isn't mono different from monotone?
We don't have mono in OE.core either so the patch is probably fine but I
just wanted to mention it...
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Error running QEMU with oe-core / angstrom console-image, hwclock: can't open '/dev/misc/rtc' : No such file or directory
Hi, if anyone might be interested, after a code review I have redone parts of the scripts. They should be much more readable now and the user can pass more parameters (like kernel image, root filesystem, memory and parameters to qemu), however this still might not work on every machine. This scripts are not a replacement for runqemu, they where just created because runqemu does not work on my machine. Normal users would probably do better if they use runqemu (I've tried it like it is described here http://sakrah.homelinux.org/blog/2011/03/using-openembedded-core-to-build-angstrom-for-qemu/ and like Khem hinted in his mail but it didn't won't work for me) In the future I might update this script and to make things more comfortable you can allways view the latest version, without downloading any files, on the pastebin account I created solely for this purpose: http://pastebin.com/u/SkipIfEqual This scripts where tested on ubuntu inside a network with a DHCP and work fine for me (can connect from host to guest (QEMU) and vice versa, from the host to the internet and from the guest to the internet). Regards Samuel ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] prelink issue with ppc64?
On Aug 4, 2011, at 12:37 AM, Kumar Gala wrote: On Aug 3, 2011, at 10:09 AM, Mark Hatle wrote: On 8/3/11 9:53 AM, Kumar Gala wrote: On Aug 3, 2011, at 9:37 AM, Mark Hatle wrote: On 8/3/11 12:35 AM, Kumar Gala wrote: If prelink gets a chance to properly run I get a rootfs that does: /sbin/init: relocation error: /lib64/libc.so.6: symbol _rtld_global_ro, version GLIBC_PRIVATE not defined in file ld64.so.1 with link time reference if 'baselib' is set to /lib we get: /local/home/galak/git/poky/build-p5020/tmp/sysroots/x86_64-linux/usr/sbin/prelink: /sbin/init.sysvinit: Using /lib/ld64.so.1, not /lib64/ld64.so.1 as dynamic linker if 'baselib' is set to /lib64 we get: Assigned virtual address space slots for libraries: /lib64/ld64.so.1 0080f491-0080f49473d0 /lib64/libc.so.6 0080f495-0080f4afe090 /lib64/libdl.so.2 0080f4b1-0080f4b23520 /lib64/libcrypt.so.1 0080f4b1-0080f4b57708 /lib64/libutil.so.1 0080f4b1-0080f4b234a0 Would prelink /lib64/ld-2.13.so Would prelink /lib64/libc-2.13.so Not sure what prelink is doing but it seems to breaking things. Any ideas? --- I'm also concerned that we use /etc/prelink.conf when invoking prelink. Prelinker is being run within the rootfs, so the /etc/prelink.conf being used is the one inside of the image -- NOT the system version. Is this because of psuedo or something else? In the cross prelinker, we pass in the --root=image. This instructs the cross-prelinker to prefix image to most paths. I would suspect that the cross-prelinker rtld emulation is likely setup for the LSB style library paths and may be causing some of the problems. You can run the cross-prelinker's rtld emulation by running the prelink-rtld program located in build/tmp-eglibc/work/x86_64-linux/usr/sbin/prelink-rtld Passing --root=path will setup the sysroot path for reference, adding in --target-paths will allow you to pass further arguments as referenced on the sysroot. So prelink-rtld --root=/foo/bar/build/sysroot/image --target-paths /sbin/init Should give you back an ldd like syntax within the sysroot, for /sbin/init. (without --target-paths, you need to specify the full path to the /sbin/init.. this is useful when running the rtld against items outside of the image.) I'd suggest simply disabling prelink and getting everything to work first.. once it does we can work through any prelinker issues. (Prelink on PPC64 hasn't been tested within the oe-core environment.. so it could very well have issues beyond the ld.so path.) Everything else is working, so prelink is what fails for me (at least for a simple minimal) build. any suggestions on how to try and debug further, who might be more familiar with prelink and what its doing? When I ran readelf -a on ld-2.13.so after prelink was getting weird results, not sure if thats normal or not. I'm the prelink maintainer for Yocto, however I know more about the way the cross-prelinker functionality works then how the ELF specific prelink functions work. I've been relying on the upstream prelink project to manage the individual architecture/ABI prelink standards. My suggestion is to disable cross-prelinking, and revert to the upstream prelink project -- run the binary on the target and see if it fails in the same way. If it does, then we know it's a deeper problem then the cross prelink integration. You can pull down the git repository: git://git.yoctoproject.org/prelink-cross.git The master branch is identical to the upstream SVN branch. The cross_prelink branch is the current state of integration. So running prelink on target seems ok. I used the version from prelink_git.bb. - k I get the following output when running cross_prelink by hand: prelink: /lib64/libc.so.6: Recorded 1 dependencies, now seeing -1 I noticed this as well (in dmesg): prelink-rtld[14492]: segfault at 289986a94 ip 00408de2 sp 7fff65ad3c10 error 4 in prelink-rtld[40+e000] - k ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL v2 00/33] Re-Spun with Tom's siteinfo update
On Wed, 2011-08-03 at 15:10 -0700, Saul Wold wrote:
Richard,
This has been built, I have done a first pass review over these
and most seem correct to me, Koen's patch to make the icons dependency
dynamic seems Ok to me, but I am not sure when the RDEPENDS are processed
compared to when populate_packages_append() is run, will this
RDEPENDS be updated correctly.
I built world yesterday with some of the same failures seen
in master
Sau!
The following changes since commit fbb734e5753655de30c82c0a036c9043820e02cb:
multilib: Use BPN instead of PN for style like lib${PN} (2011-08-03
18:06:04 +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
Dmitry Eremin-Solenikov (1):
eglibc: fix build for armv4 machines
Kang Kai (1):
libnewt: update to 0.52.13
Koen Kooi (1):
gtk-icon-cache bbclass: only add runtime dependencies on
hicolor-icon-theme when installing icons
** RP - Will the RDEPENDS be updated correctly? **
Kumar Gala (2):
binutils: Add support for powerpc e5500 core
eglibc_2.13: Add support for handling sqrt sqrtf on powerpc
Lianhao Lu (1):
environment files: Added and unified version related variables.
Martin Jansa (2):
polkit: depend on intltool-native instead of intltool
libfm: depend on intltool-native instead of intltool
Mei Lei (1):
aspell: upgrade from 0.60.6 to 0.60.6.1
Noor, Ahsan (3):
bison: Add dependency on flex-native
kernel,cml1.bbclass: Move menuconfig to cml1
kernel.bbcalss: Added do_savedefconfig task.
Saul Wold (2):
glibc: Remove unused version
libxt: Add depends for util-linux and libxcb
Tom Rini (10):
connman_test.sh: Rework for busybox 'ps'
sudo: Drop sudo_cv_uid_t_len from site files
tcl: Add tcl_cv_api_serial to siteinfo
Various site files: Drop monotone
Various siteinfo files: Consolidate ac_cv_func_getaddrinfo
Various siteinfo files: Drop enca section
Various siteinfo files: Consolidate va_copy/__va_copy/va_val_copy
site/common-linux: Add ac_cv_file__dev_zero=yes
siteinfo: Add posix_getpwuid_r posix_getgrgid_r posix_getpwnam_r to
uclibc
Various siteinfo: Drop rp-pppoe variables
Yu Ke (1):
SRC_URI, S: use BPN instead of PN for multilib case
Zhai Edwin (8):
lighttpd: Upgrade to 1.4.29
libsoup-2.4: Upgrade to 2.34.2
libassuan: Upgrade to 2.0.2
gpgme: Upgrade to 1.3.1
parted: Upgrade to 3.0
apr: Upgrade to 1.4.5
apr-util: Upgrade to 1.3.12
xserver-nodm-init: Fix X start failure on some platform
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 1/2] bitbake: Allow seting of baselib
On Thu, 2011-08-04 at 02:28 -0500, Kumar Gala wrote:
Allow for baselib to be set to something other than 'lib'. This is useful
for the 64-bit arch cases in which we want baselib set to 'lib64'.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
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..c50ffb9 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -7,7 +7,7 @@
#
# Used by multilib code to change the library paths
-baselib = lib
+baselib = ${@d.getVar('BASE_LIB', True) or 'lib'}
# Path prefixes
export base_prefix =
Can you not do:
baselib_powerpc64 = lib64
here?
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] oe-init-build-env, scripts/oe-buildenv-internal: add error detecting for $BDIR
On Thu, 2011-08-04 at 06:37 -0700, Darren Hart wrote: On 08/04/2011 05:07 AM, Richard Purdie wrote: On Tue, 2011-08-02 at 21:06 -0700, Darren Hart wrote: On 08/02/2011 04:43 AM, Richard Purdie wrote: On Tue, 2011-08-02 at 14:08 +0800, Dexuan Cui wrote: [YOCTO #671] readlink -f in Ubuntu 10.04 is buggy: it doesn't ignore a trailing / (e.g., readlink -f /tmp/non-existent-dir/ returns nothing, but according to http://www.gnu.org/s/coreutils/manual/coreutils.pdf it should do that -- hence we get bug 671. It seems Ubuntu 10.10 or even later Ubuntu 11.04, and other Linux distributions(e.g., Open Suse 11.4) haven't such an issue. So I think we should detect this and ask Ubuntu 10.04 users to avoid supply a path with trailing slash here. Moreever, I also add the detection of non-existent path, e.g., source oe-init-build-env /non-existent-dir/build can be detected and we'll print an error msg. And, if we get errors in oe-buildenv-internal, we should stop the script and shouldn't further run. Signed-off-by: Dexuan Cui dexuan@intel.com Merged to master, thanks. For a patch to address a relatively benign bug I thought the standard procedure would be for it to await feedback for more than 5 hours. I was hoping to have an opportunity to review this fix as I was working with the team in root causing the bug. It is near impossible for me to tell who (if anyone) is working jointly on an issue or expecting to review a patch. All I see are the complaints when things don't merge promptly or something less than ideal merges too soon (i.e. I can't win) :(. In this case I was trying to refer back to what I had understood to be the norm (waiting for 24 hours) to allow for feedback. I know it wasn't a hard rule, but I didn't see any degree of urgency with this patch. If your process is different than my understanding, please correct my thinking so I know what to expect going forward. If not, then the above is just meant as a friendly reminder that I, at least, am operating under the assumption that patches will have a 24 hour review window unless there is a pressing need to merge them sooner. Fair comment, its a 24 hour guideline and I thought that patch was safe enough :/. I'll try and ensure I don't do that again. 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] connman_test.sh: Rework for busybox 'ps'
On 07/27/2011 03:01 PM, Tom Rini wrote: This script has two problems today. First, it does 'ps -ef cmd' in failure which real ps doesn't grok and busybox ps just ignores the argument on. Switch that to 'ps -ef'. Second, busybox ps -o doesn't understand cmd but does understand comm. Using comm lets us simplify the test logic as well, so switch to that. Signed-off-by: Tom Rinitom_r...@mentor.com --- scripts/qemuimage-tests/tools/connman_test.sh |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/scripts/qemuimage-tests/tools/connman_test.sh b/scripts/qemuimage-tests/tools/connman_test.sh index d7e63e7..dd5554c 100644 --- a/scripts/qemuimage-tests/tools/connman_test.sh +++ b/scripts/qemuimage-tests/tools/connman_test.sh @@ -27,21 +27,21 @@ if [ ! -f /usr/sbin/connmand ]; then fi # Check if connmand is running in background -count=`ps -eo cmd | cut -d -f 1 | grep -c connmand` +count=`ps -eo comm | grep -c connmand` if [ $count -ne 1 ]; then Target_Info connmand has issue when running in background, Pls, check the output of ps - ps -ef cmd | grep connmand + ps -ef | grep connmand exit 1 fi # Check if there is always only one connmand running in background if [ connmand /dev/null 21 ]; then Target_Info connmand command run without problem - count=`ps -eo cmd | cut -d -f 1 | grep -c connmand` + count=`ps -eo comm | grep -c connmand` if [ $count -ne 1 ]; then Target_Info There are more than one connmand running in background, Pls, check the output of ps - ps -ef cmd | grep connmand + ps -ef | grep connmand exit 1 else Target_Info There is always one connmand running in background, test pass Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] tcl: Fix packaging of platform independent files
On Wed, 2011-08-03 at 21:03 +0100, Phil Blundell wrote:
On Wed, 2011-08-03 at 10:43 -0500, Kumar Gala wrote:
Tcl's doesn't utilize ${baselib} for platform independent files but
defines it as follows:
TCL_LIBRARY = $(prefix)/lib/tcl$(VERSION)
Match that so if ${baselib} is not just /lib things work properly.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
Even better would be bashing tcl so that it puts its bits in ${datadir}
where they belong. :-) But your patch is fine though.
Agreed, this would be the ideal solution...
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCHv2] gst-plugins: partially sync packaging with OE .dev
On 07/28/2011 03:14 AM, Koen Kooi wrote:
Op 28 jul. 2011, om 11:49 heeft Phil Blundell het volgende geschreven:
On Thu, 2011-07-28 at 11:44 +0200, Koen Kooi wrote:
+ALLOW_EMPTY = 1
Is that necessary? You seem to be setting ALLOW_EMPTY_${PN}-meta=1 in
your python code anyway.
In OE classic that was to keep ${PN} alive after all libs and apps were
removed, I'm not sure we need it in OE-core.
Koen,
Are you re-submitting a v2 pf this patch or do you still want it to go
as is?
Sau!
regards,
Koen
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] polkit: depend on intltool-native instead of intltool
On 07/28/2011 11:43 PM, Martin Jansa wrote:
Signed-off-by: Martin Jansamartin.ja...@gmail.com
---
meta/recipes-extended/polkit/polkit_0.101.bb |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-extended/polkit/polkit_0.101.bb
b/meta/recipes-extended/polkit/polkit_0.101.bb
index 64cca10..f3a6f1c 100644
--- a/meta/recipes-extended/polkit/polkit_0.101.bb
+++ b/meta/recipes-extended/polkit/polkit_0.101.bb
@@ -12,7 +12,7 @@ SRC_URI =
http://hal.freedesktop.org/releases/polkit-${PV}.tar.gz \
PAM_SRC_URI = file://polkit-1_pam.patch
PR = r1
-DEPENDS = libpam expat dbus-glib eggdbus intltool
+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
Merged into OE-Core
Thanks
Sau!
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libfm: depend on intltool-native instead of intltool
On 07/28/2011 11:43 PM, Martin Jansa wrote: Signed-off-by: Martin Jansamartin.ja...@gmail.com --- meta/recipes-support/libfm/libfm_0.1.14.bb |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/meta/recipes-support/libfm/libfm_0.1.14.bb b/meta/recipes-support/libfm/libfm_0.1.14.bb index 5c7e95c..38f1d73 100644 --- a/meta/recipes-support/libfm/libfm_0.1.14.bb +++ b/meta/recipes-support/libfm/libfm_0.1.14.bb @@ -8,7 +8,7 @@ LIC_FILES_CHKSUM = file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552 \ file://src/base/fm-config.h;endline=23;md5=ad0fc418c3cf041eea35ddb3daf37f17 SECTION = x11/libs -DEPENDS = gtk+ menu-cache intltool +DEPENDS = gtk+ menu-cache intltool-native PR = r3 Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1]aspell: upgrade from 0.60.6 to 0.60.6.1
On 07/31/2011 05:41 PM, Mei Lei wrote:
Hi Saul,
This pull request upgrade aspell from 0.60.6 to 0.60.6.1, please review
it.
Thanks
Lei
The following changes since commit f94b781695cd8fa387daff16ecbf3987a0883018:
Bruce Ashfield (1):
poky.conf: explicitly referenced preferred linux-yocto version
are available in the git repository at:
git://git.pokylinux.org/poky-contrib lmei3/upgrade-0730
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=lmei3/upgrade-0730
Mei Lei (1):
aspell: upgrade from 0.60.6 to 0.60.6.1
.../{aspell_0.60.6.bb = aspell_0.60.6.1.bb} |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
rename meta/recipes-support/aspell/{aspell_0.60.6.bb = aspell_0.60.6.1.bb}
(82%)
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Merged into OE-Core
Thanks
Sau!
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] bison: Add dependency on flex-native
On 08/01/2011 03:16 AM, Noor, Ahsan wrote:
* This is 0479b70418ef553859029911c57c63a7aaebe299 from OE. flex-native is
needed to build bison. The dependency was being satisfied indirectly but we
need to add it explicitly.
Signed-off-by: Noor, Ahsannoor_ah...@mentor.com
---
meta/recipes-devtools/bison/bison_2.3.bb |4 ++--
meta/recipes-devtools/bison/bison_2.5.bb |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-devtools/bison/bison_2.3.bb
b/meta/recipes-devtools/bison/bison_2.3.bb
index 22f884b..388476b 100644
--- a/meta/recipes-devtools/bison/bison_2.3.bb
+++ b/meta/recipes-devtools/bison/bison_2.3.bb
@@ -7,9 +7,9 @@ HOMEPAGE = http://www.gnu.org/software/bison/;
LICENSE = GPLv2
LIC_FILES_CHKSUM = file://COPYING;md5=eb723b61539feef013de476e68b5c50a
SECTION = devel
-DEPENDS = bison-native
+DEPENDS = bison-native flex-native
-PR = r0
+PR = r1
BASE_SRC_URI = ${GNU_MIRROR}/bison/bison-${PV}.tar.gz \
file://bison-2.3_m4.patch
diff --git a/meta/recipes-devtools/bison/bison_2.5.bb
b/meta/recipes-devtools/bison/bison_2.5.bb
index 63f4e76..eb5d87c 100644
--- a/meta/recipes-devtools/bison/bison_2.5.bb
+++ b/meta/recipes-devtools/bison/bison_2.5.bb
@@ -7,9 +7,9 @@ HOMEPAGE = http://www.gnu.org/software/bison/;
LICENSE = GPLv3
LIC_FILES_CHKSUM = file://COPYING;md5=d32239bcb673463ab874e80d47fae504
SECTION = devel
-DEPENDS = bison-native
+DEPENDS = bison-native flex-native
-PR = r0
+PR = r1
BASE_SRC_URI = ${GNU_MIRROR}/bison/bison-${PV}.tar.gz \
file://m4.patch \
Merged into OE-Core
Thanks
Sau!
___
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 bbclass: only add runtime dependencies on hicolor-icon-theme when installing icons
On 08/01/2011 04:08 AM, Koen Kooi wrote:
Tested with gnome-icon-theme and libsoup recipes on angstrom.
Signed-off-by: Koen Kooik...@openembedded.org
---
meta/classes/gtk-icon-cache.bbclass |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/meta/classes/gtk-icon-cache.bbclass
b/meta/classes/gtk-icon-cache.bbclass
index dcabaf5..d9b5d1b 100644
--- a/meta/classes/gtk-icon-cache.bbclass
+++ b/meta/classes/gtk-icon-cache.bbclass
@@ -1,5 +1,4 @@
FILES_${PN} += ${datadir}/icons/hicolor
-RDEPENDS += hicolor-icon-theme
# This could run on the host as icon cache files are architecture independent,
# but there is no gtk-update-icon-cache built natively.
@@ -34,7 +33,12 @@ python populate_packages_append () {
icon_dir = '%s/%s/%s/icons' % (pkgdest, pkg,
bb.data.getVar('datadir', d, 1))
if not os.path.exists(icon_dir):
continue
-
+
+ bb.note(adding hicolor-icon-theme dependency to %s % pkg)
+ rdepends = bb.data.getVar('RDEPENDS', d, 1)
+ rdepends += hicolor-icon-theme
+ bb.data.setVar('RDEPENDS', rdepends, d)
+
bb.note(adding gtk-icon-cache postinst and postrm scripts to
%s % pkg)
postinst = bb.data.getVar('pkg_postinst_%s' % pkg, d, 1) or
bb.data.getVar('pkg_postinst', d, 1)
Merged into OE-Core
Thanks
Sau!
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] Set version related variables in environment files.
On 08/01/2011 09:20 PM, Lianhao Lu wrote: Fixed bug #1306. Have all the environment files created by meta-toolchain, meta-ide-support and meta-envrionment-xxx contain the same version related variables. The following changes since commit 2a41a311ddda11713296391050f3c2c1b2c1d3d3: Koen Kooi (1): arch-armv7a.inc: fix armv7a-vfp-neon - armv7a compat case are available in the git repository at: git://git.yoctoproject.org/poky-contrib llu/bug1306 http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=llu/bug1306 Lianhao Lu (1): environment files: Added and unified version related variables. meta/classes/toolchain-scripts.bbclass |3 +++ meta/recipes-core/meta/meta-environment.bb |2 +- meta/recipes-core/meta/meta-ide-support.bb |2 +- meta/recipes-core/meta/meta-toolchain.bb |2 +- 4 files changed, 6 insertions(+), 3 deletions(-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core Merged into OE-Core Thanks Sau! ___ 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
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 b/scripts/oe-buildenv-internal index 117b0c5..4a44174 100755 --- a/scripts/oe-buildenv-internal +++ b/scripts/oe-buildenv-internal @@ -28,14 +28,16 @@ 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. + return 1 +fi +BDIR=`echo $BDIR | sed -re 's|/+$||'` + BDIR=`readlink -f $BDIR` +if [ -z $BDIR ]; then + PARENTDIR=`dirname $1` +echo 2 Error: the directory $PARENTDIR doesn't exist? 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 Thanks! -- Dexuan commit 593e3506f4d4d9f6030100eac8c8e0af7f8ce3eb Author: Dexuan Cui dexuan@intel.com Date: Thu Aug 4 14:53:20 2011 +0800 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: 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 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. +return 1 +fi + +# Remove possible trailing slash. This is used to work around +# buggy readlink of Ubuntu 10.04 that doesn't ignore trailing slash +# and hence readlink -f new_dir_to_be_created/ returns empty. +# See YOCTO #671 for details. +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 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernel.bbcalss: Added do_savedefconfig task.
On 08/02/2011 05:30 AM, Noor, Ahsan wrote:
* Added do_savedefconfig task to kernel.bbclass.
Signed-off-by: Noor, Ahsannoor_ah...@mentor.com
---
meta/classes/kernel.bbclass |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 25d2629..f2f05b1 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -197,6 +197,12 @@ kernel_do_configure() {
do_configure[depends] += ${INITRAMFS_TASK}
+do_savedefconfig() {
+ oe_runmake savedefconfig
+}
+do_savedefconfig[nostamp] = 1
+addtask savedefconfig after do_configure
+
pkg_postinst_kernel () {
cd /${KERNEL_IMAGEDEST}; update-alternatives --install
/${KERNEL_IMAGEDEST}/${KERNEL_IMAGETYPE} ${KERNEL_IMAGETYPE}
${KERNEL_IMAGETYPE}-${KERNEL_VERSION} ${KERNEL_PRIORITY} || true
}
Merged into OE-Core
Thanks
Sau!
___
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 Thu, 2011-08-04 at 22:49 +0800, Cui, Dexuan wrote: +BDIR=`readlink -f $BDIR` +if [ -z $BDIR ]; then +PARENTDIR=`dirname $1` +echo 2 Error: the directory $PARENTDIR does not exist? return 1 fi fi Just out of curiosity, could you not just do mkdir -p $BDIR and avoid this whole set of complicated tests? Or is there some reason why it's actually important to know whether the parent directory existed already? p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernel,cml1.bbclass: Move menuconfig to cml1
On 07/29/2011 05:24 AM, Noor, Ahsan wrote:
* The menuconfig target exists in places other than the kernel that use kernel
style config.
Signed-off-by: Noor, Ahsannoor_ah...@mentor.com
---
meta/classes/cml1.bbclass | 12
meta/classes/kernel.bbclass | 15 ---
2 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/meta/classes/cml1.bbclass b/meta/classes/cml1.bbclass
index 79218b4..a747af5 100644
--- a/meta/classes/cml1.bbclass
+++ b/meta/classes/cml1.bbclass
@@ -6,3 +6,15 @@ cml1_do_configure() {
EXPORT_FUNCTIONS do_configure
addtask configure after do_unpack do_patch before do_compile
+
+do_menuconfig() {
+ export TERMWINDOWTITLE=${PN} Configuration
+ export SHELLCMDS=make menuconfig
+ ${TERMCMDRUN}
+ if [ $? -ne 0 ]; then
+ oefatal '${TERMCMD}' not found. Check TERMCMD variable.
+ fi
+}
+do_menuconfig[nostamp] = 1
+addtask menuconfig after do_configure
+
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 9c492a3..25d2629 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -197,21 +197,6 @@ kernel_do_configure() {
do_configure[depends] += ${INITRAMFS_TASK}
-do_menuconfig() {
-export DISPLAY='${DISPLAY}'
-export DBUS_SESSION_BUS_ADDRESS='${DBUS_SESSION_BUS_ADDRESS}'
-export XAUTHORITY='${XAUTHORITY}'
- export TERMWINDOWTITLE=${PN} Kernel Configuration
- export SHELLCMDS=make menuconfig
- ${TERMCMDRUN}
- if [ $? -ne 0 ]; then
- echo Fatal: '${TERMCMD}' not found. Check TERMCMD variable.
- exit 1
- fi
-}
-do_menuconfig[nostamp] = 1
-addtask menuconfig after do_configure
-
pkg_postinst_kernel () {
cd /${KERNEL_IMAGEDEST}; update-alternatives --install
/${KERNEL_IMAGEDEST}/${KERNEL_IMAGETYPE} ${KERNEL_IMAGETYPE}
${KERNEL_IMAGETYPE}-${KERNEL_VERSION} ${KERNEL_PRIORITY} || true
}
Merged into OE-Core
Thanks
Sau!
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Yocto post 1.1 development focus areas?
[Cross posted but please reply on the Yocto list] We're starting to think about the development focus for post Yocto 1.1 and are collecting ideas on the unscheduled feature list on the wiki: https://wiki.yoctoproject.org/wiki/Yocto_Project_Unscheduled_Feature_List This is an opportunity for people to mention all the if only we had X functionality ideas they might think of as they use the system. Obviously there are no promises anything listed will get worked on but if its not there, the likelihood of it not happening is significantly higher :) 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] eglibc_2.13: Add support for handling sqrt sqrtf on powerpc
On 08/01/2011 07:26 AM, Kumar Gala wrote:
Some of powerpc's dont support the fsqrt[s] instructions so we need an
implementation of the library functions for those processors.
Signed-off-by: Kumar Galaga...@kernel.crashing.org
---
.../recipes-core/eglibc/eglibc-2.13/ppc-sqrt.patch | 538
meta/recipes-core/eglibc/eglibc_2.13.bb|3 +-
2 files changed, 540 insertions(+), 1 deletions(-)
create mode 100644 meta/recipes-core/eglibc/eglibc-2.13/ppc-sqrt.patch
diff --git a/meta/recipes-core/eglibc/eglibc-2.13/ppc-sqrt.patch
b/meta/recipes-core/eglibc/eglibc-2.13/ppc-sqrt.patch
new file mode 100644
index 000..203040c
--- /dev/null
+++ b/meta/recipes-core/eglibc/eglibc-2.13/ppc-sqrt.patch
@@ -0,0 +1,538 @@
+Upstream-Status: Pending
+
+2011-03-22 Joseph Myersjos...@codesourcery.com
+
+Merge from SG++ 2.11:
+
+2010-10-05 Nathan Froydfroy...@codesourcery.com
+
+Issue #9382
+
+* sysdeps/powerpc/powerpc32/603e/: New directory.
+* sysdeps/unix/sysv/linux/powerpc/powerpc32/e500mc/: New directory.
+* sysdeps/unix/sysv/linux/powerpc/powerpc32/603e/: New directory.
+* sysdeps/unix/sysv/linux/powerpc/powerpc32/7400/: New directory.
+* sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrtf.c: Update.
+* sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c: Update.
+* sysdeps/powerpc/powerpc64/e5500/fpu/Implies: New file.
+
+Index: libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c
+===
+--- /dev/null
libc/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c
+@@ -0,0 +1,134 @@
++/* Double-precision floating point square root.
++ Copyright (C) 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
++ modify it under the terms of the GNU Lesser General Public
++ License as published by the Free Software Foundation; either
++ version 2.1 of the License, or (at your option) any later version.
++
++ The GNU C Library is distributed in the hope that it will be useful,
++ but WITHOUT ANY WARRANTY; without even the implied warranty of
++ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
++ Lesser General Public License for more details.
++
++ You should have received a copy of the GNU Lesser General Public
++ License along with the GNU C Library; if not, write to the Free
++ Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
++ 02111-1307 USA. */
++
++#includemath.h
++#includemath_private.h
++#includefenv_libc.h
++#includeinttypes.h
++
++#includesysdep.h
++#includeldsodefs.h
++
++static const ieee_float_shape_type a_nan = {.word = 0x7fc0 };
++static const ieee_float_shape_type a_inf = {.word = 0x7f80 };
++static const float two108 = 3.245185536584267269e+32;
++static const float twom54 = 5.551115123125782702e-17;
++static const float half = 0.5;
++
++/* The method is based on the descriptions in:
++
++ _The Handbook of Floating-Pointer Arithmetic_ by Muller et al., chapter 5;
++ _IA-64 and Elementary Functions: Speed and Precision_ by Markstein,
chapter 9
++
++ We find the actual square root and half of its reciprocal
++ simultaneously. */
++
++#ifdef __STDC__
++double
++__ieee754_sqrt (double b)
++#else
++double
++__ieee754_sqrt (b)
++ double b;
++#endif
++{
++ if (__builtin_expect (b 0, 1))
++{
++ double y, g, h, d, r;
++ ieee_double_shape_type u;
++
++ if (__builtin_expect (b != a_inf.value, 1))
++{
++ fenv_t fe;
++
++ fe = fegetenv_register ();
++
++ u.value = b;
++
++ relax_fenv_state ();
++
++ __asm__ (frsqrte %[estimate], %[x]\n
++ : [estimate] =f (y) : [x] f (b));
++
++ /* Following Muller et al, page 168, equation 5.20.
++
++ h goes to 1/(2*sqrt(b))
++ g goes to sqrt(b).
++
++ We need three iterations to get within 1ulp. */
++
++ /* Indicate that these can be performed prior to the branch. GCC
++ insists on sinking them below the branch, however; it seems like
++ they'd be better before the branch so that we can cover any
latency
++ from storing the argument and loading its high word. Oh well.
*/
++
++ g = b * y;
++ h = 0.5 * y;
++
++ /* Handle small numbers by scaling. */
++ if (__builtin_expect ((u.parts.msw 0x7ff0)= 0x0200, 0))
++return __ieee754_sqrt (b * two108) * twom54;
++
++#define FMADD(a_, c_, b_) \
++ ({ double __r;\
++ __asm__ (fmadd %[r], %[a], %[c], %[b]\n \
++ : [r] =f (__r) : [a] f (a_), [c] f (c_), [b] f
(b_)); \
++ __r;})
++#define FNMSUB(a_, c_, b_)
Re: [OE-core] [PATCH] binutils: Add support for powerpc e5500 core
On 08/01/2011 07:30 AM, Kumar Gala wrote:
Add powerpc e5500 core support to binutils so its recognized by
assember, etc. The e5500 is a 64-bit core from Freescale utilized in
the P5020 SoC.
Signed-off-by: Kumar Galaga...@kernel.crashing.org
---
.../binutils/binutils/binutils-powerpc-e5500.patch | 112
meta/recipes-devtools/binutils/binutils_2.21.1.bb |3 +-
2 files changed, 114 insertions(+), 1 deletions(-)
create mode 100644
meta/recipes-devtools/binutils/binutils/binutils-powerpc-e5500.patch
diff --git
a/meta/recipes-devtools/binutils/binutils/binutils-powerpc-e5500.patch
b/meta/recipes-devtools/binutils/binutils/binutils-powerpc-e5500.patch
new file mode 100644
index 000..1de164d
--- /dev/null
+++ b/meta/recipes-devtools/binutils/binutils/binutils-powerpc-e5500.patch
@@ -0,0 +1,112 @@
+Upstream-Status: Pending
+
+Add support for FSL PowerPC e5500 core.
+
+Signed-off-by: Edmar Wienskoskied...@freescale.com
+Signed-off-by: Kumar Galaga...@kernel.crashing.org
+
+Index: binutils-2.21.1/bfd/archures.c
+===
+--- binutils-2.21.1.orig/bfd/archures.c
binutils-2.21.1/bfd/archures.c
+@@ -231,6 +231,7 @@ DESCRIPTION
+ .#define bfd_mach_ppc_e500 500
+ .#define bfd_mach_ppc_e500mc5001
+ .#define bfd_mach_ppc_e500mc64 5005
++.#define bfd_mach_ppc_e5500 5006
+ .#define bfd_mach_ppc_titan 83
+ . bfd_arch_rs6000,{* IBM RS/6000 *}
+ .#define bfd_mach_rs6k6000
+Index: binutils-2.21.1/bfd/bfd-in2.h
+===
+--- binutils-2.21.1.orig/bfd/bfd-in2.h
binutils-2.21.1/bfd/bfd-in2.h
+@@ -1918,6 +1918,7 @@ enum bfd_architecture
+ #define bfd_mach_ppc_e500 500
+ #define bfd_mach_ppc_e500mc5001
+ #define bfd_mach_ppc_e500mc64 5005
++#define bfd_mach_ppc_e5500 5006
+ #define bfd_mach_ppc_titan 83
+ bfd_arch_rs6000,/* IBM RS/6000 */
+ #define bfd_mach_rs6k 6000
+Index: binutils-2.21.1/bfd/cpu-powerpc.c
+===
+--- binutils-2.21.1.orig/bfd/cpu-powerpc.c
binutils-2.21.1/bfd/cpu-powerpc.c
+@@ -352,6 +352,20 @@ const bfd_arch_info_type bfd_powerpc_arc
+ FALSE, /* not the default */
+ powerpc_compatible,
+ bfd_default_scan,
++bfd_powerpc_archs[19]
++ },
++ {
++64, /* 64 bits in a word */
++64, /* 64 bits in an address */
++8, /* 8 bits in a byte */
++bfd_arch_powerpc,
++bfd_mach_ppc_e5500,
++powerpc,
++powerpc:e5500,
++3,
++FALSE, /* not the default */
++powerpc_compatible,
++bfd_default_scan,
+ 0
+ }
+ };
+Index: binutils-2.21.1/gas/config/tc-ppc.c
+===
+--- binutils-2.21.1.orig/gas/config/tc-ppc.c
binutils-2.21.1/gas/config/tc-ppc.c
+@@ -1236,6 +1236,7 @@ PowerPC options:\n\
+ -me500, -me500x2generate code for Motorola e500 core complex\n\
+ -me500mc, generate code for Freescale e500mc core complex\n\
+ -me500mc64, generate code for Freescale e500mc64 core complex\n\
++-me5500,generate code for Freescale e5500 core complex\n\
+ -mspe generate code for Motorola SPE instructions\n\
+ -mtitan generate code for AppliedMicro Titan core complex\n\
+ -mregnames Allow symbolic names for registers\n\
+Index: binutils-2.21.1/gas/doc/as.texinfo
+===
+--- binutils-2.21.1.orig/gas/doc/as.texinfo
binutils-2.21.1/gas/doc/as.texinfo
+@@ -432,7 +432,7 @@ gcc(1), ld(1), and the Info entries for
+[@b{-a32}|@b{-a64}]
+
[@b{-mpwrx}|@b{-mpwr2}|@b{-mpwr}|@b{-m601}|@b{-mppc}|@b{-mppc32}|@b{-m603}|@b{-m604}|@b{-m403}|@b{-m405}|
+
@b{-m440}|@b{-m464}|@b{-m476}|@b{-m7400}|@b{-m7410}|@b{-m7450}|@b{-m7455}|@b{-m750cl}|@b{-mppc64}|
+-
@b{-m620}|@b{-me500}|@b{-e500x2}|@b{-me500mc}|@b{-me500mc64}|@b{-mppc64bridge}|@b{-mbooke}|
++
@b{-m620}|@b{-me500}|@b{-e500x2}|@b{-me500mc}|@b{-me500mc64}|@b{-me5500}|@b{-mppc64bridge}|@b{-mbooke}|
+
@b{-mpower4}|@b{-mpr4}|@b{-mpower5}|@b{-mpwr5}|@b{-mpwr5x}|@b{-mpower6}|@b{-mpwr6}|
+
@b{-mpower7}|@b{-mpw7}|@b{-ma2}|@b{-mcell}|@b{-mspe}|@b{-mtitan}|@b{-me300}|@b{-mcom}]
+[@b{-many}] [@b{-maltivec}|@b{-mvsx}]
+Index: binutils-2.21.1/gas/doc/c-ppc.texi
+===
+--- binutils-2.21.1.orig/gas/doc/c-ppc.texi
binutils-2.21.1/gas/doc/c-ppc.texi
+@@ -85,6 +85,9 @@ Generate code for Freescale e500mc core
+ @item -me500mc64
+ Generate code for Freescale e500mc64 core complex.
+
++@item -me5500
++Generate code for Freescale e5500 core complex.
++
+ @item -mspe
+ Generate code for Motorola SPE instructions.
+
+Index: binutils-2.21.1/opcodes/ppc-dis.c
+===
+---
Re: [OE-core] [PATCH] image-mklibs.bbclass: Utilize ${base_libdir} instead of static /lib
On 8/3/11 11:03 PM, Kumar Gala wrote:
We might redefine ${base_libdir} from being set to just /lib.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
Only tangentially related to this patch.. It doesn't appear mklibs has knowledge
of multilibs.. but I don't think anyone would use mklibs with a multilib
environment. So something we might want to add is a warning that mklibs and
multilibs don't work together.
--Mark
---
meta/classes/image-mklibs.bbclass |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/meta/classes/image-mklibs.bbclass
b/meta/classes/image-mklibs.bbclass
index d6630c4..69dac2f 100644
--- a/meta/classes/image-mklibs.bbclass
+++ b/meta/classes/image-mklibs.bbclass
@@ -17,19 +17,19 @@ mklibs_optimize_image_doit() {
case ${TARGET_ARCH} in
powerpc | mips | microblaze )
- dynamic_loader=/lib/ld.so.1
+ dynamic_loader=${base_libdir}/ld.so.1
;;
powerpc64)
dynamic_loader=${base_libdir}/ld64.so.1
;;
x86_64)
- dynamic_loader=/lib/ld-linux-x86-64.so.2
+ dynamic_loader=${base_libdir}/ld-linux-x86-64.so.2
;;
i586 )
- dynamic_loader=/lib/ld-linux.so.2
+ dynamic_loader=${base_libdir}/ld-linux.so.2
;;
arm )
- dynamic_loader=/lib/ld-linux.so.3
+ dynamic_loader=${base_libdir}/ld-linux.so.3
;;
* )
dynamic_loader=/unknown_dynamic_linker
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/9] Re-sync and update siteinfo, round 2
On 07/27/2011 03:56 PM, Tom Rini wrote: Hey all, Here's my last series before I try the clean slate approach to updating the siteinfo files. In a few cases there's some behavior change and that's a good thing. In short, for sudo we set a variable to the default if not set, so stop doing that. For tcl, we had correctly figured out an optional variable in one case, and now we re-use it everywhere. We drop out totally monotone (not in oe-core nor meta-oe nor oe.dev), rp-pppoe (meta-oe, correctly) and enca (not needed when oe.dev is moved over, not in oe-core nor meta-oe). Finally there's a few sets of $libc variables being moved to the common-$libc files. Of slight note here is that va_copy doing a value copy (va_val_copy) is arch dependent and we were getting this wrong in some cases on x86_64. Given that it's assumed to be true when not set from what I can see, it's possible we're going from implicit breakage to explicit breakage here in some of the less common arches, but that's better (IMHO) that the alternative. I've build-tested world on qemux86/qemux86-64 and core-image-sato on qemuppc/qemumips for eglibc and some smaller subsets (in checking the is it really? in making uclibc changes) for uclibc over the past few weeks. I've got a world build going now for qemux86-64 and will kick off qemux86 next but I don't expect any failures nor believe waiting on these to complete should be gating. The following changes since commit 1fe892ab6876c405599c79657221a8b4675b6ecf: Matthew McClintock (1): Update TERMCMD message to align with previous change are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib trini/update-siteinfo-round-2-v1 http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=trini/update-siteinfo-round-2-v1 Tom Rini (9): sudo: Drop sudo_cv_uid_t_len from site files tcl: Add tcl_cv_api_serial to siteinfo Various site files: Drop monotone Various siteinfo files: Consolidate ac_cv_func_getaddrinfo Various siteinfo files: Drop enca section Various siteinfo files: Consolidate va_copy/__va_copy/va_val_copy site/common-linux: Add ac_cv_file__dev_zero=yes siteinfo: Add posix_getpwuid_r posix_getgrgid_r posix_getpwnam_r to uclibc Various siteinfo: Drop rp-pppoe variables meta/recipes-devtools/tcltk/tcl_8.5.9.bb |2 +- meta/site/arm-common | 25 +-- meta/site/arm-linux |9 meta/site/common-glibc | 12 -- meta/site/common-linux |3 ++ meta/site/common-uclibc | 15 ++ meta/site/ix86-common| 31 ++--- meta/site/mips-common| 18 meta/site/mips-linux | 25 +--- meta/site/mips-linux-uclibc | 24 +-- meta/site/mipsel-linux | 26 +--- meta/site/mipsel-linux-uclibc| 12 +-- meta/site/powerpc-linux | 13 --- meta/site/powerpc32-linux| 17 meta/site/sh-common | 24 +- meta/site/x86_64-linux | 14 ++-- meta/site/x86_64-linux-uclibc| 12 +++--- 17 files changed, 77 insertions(+), 205 deletions(-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core Merged into OE-Core Thanks for your help and patience on getting this one merged. Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] replace PN with BPN in SRC_URI and S for multilib
On 07/29/2011 06:59 PM, Yu Ke wrote: in multilibcase, PN has multilib prefix, so it is not correct to use PN in SRC_URI and S. instead, we've dedicately pruned multilib prefix in BPN, so BPN is the right alternative for PN. The following changes since commit f94b781695cd8fa387daff16ecbf3987a0883018: Bruce Ashfield (1): poky.conf: explicitly referenced preferred linux-yocto version are available in the git repository at: git://git.pokylinux.org/poky-contrib kyu3/src-uri http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=kyu3/src-uri Yu Ke (1): SRC_URI, S: use BPN instead of PN for multilib case .../farsight/farsight2_0.0.9.bb|2 +- .../loudmouth/loudmouth_1.4.0.bb |2 +- .../opensync/libopensync-plugin_0.36.inc |2 +- .../telepathy/telepathy-farsight_0.0.7.bb |2 +- .../telepathy/telepathy-gabble_0.7.8.bb|2 +- .../recipes-connectivity/wbxml/wbxml2_0.9.2.bb |2 +- .../recipes-gnome/gcalctool/gcalctool_5.7.32.bb|2 +- .../recipes-gnome/gcalctool/gcalctool_5.8.17.bb|2 +- .../recipes-gnome/libgtkstylus/libgtkstylus_0.5.bb |2 +- meta-demoapps/recipes-gnome/wv/wv_1.2.0.bb |2 +- meta-demoapps/recipes-sato/kf/kf_0.5.4.1.bb|2 +- .../matchbox-themes-extra_git.bb |2 +- .../recipes-support/poppler/poppler-data_0.1.bb|2 +- meta-demoapps/recipes-support/poppler/poppler.inc |2 +- .../omap3-sgx-modules_1.3.13.1397.bb |4 ++-- meta/recipes-bsp/zaurusd/zaurusd_svn.bb|2 +- .../galago/galago-daemon_0.5.1.bb |2 +- .../iproute2/iproute2_2.6.38.bb|2 +- meta/recipes-connectivity/ofono/ofono_0.50.bb |2 +- .../telepathy/telepathy-glib_0.14.3.bb |2 +- .../telepathy/telepathy-idle_0.1.8.bb |2 +- .../telepathy/telepathy-python_0.15.19.bb |2 +- meta/recipes-core/dbus-wait/dbus-wait_svn.bb |2 +- .../glib-networking/glib-networking_2.28.7.bb |2 +- meta/recipes-devtools/distcc/distcc_2.18.3.bb |2 +- .../subversion/subversion_1.6.15.bb|2 +- meta/recipes-extended/blktool/blktool_4-6.bb |2 +- .../recipes-extended/chkconfig/chkconfig_1.3.52.bb |2 +- meta/recipes-extended/libidn/libidn_0.6.14.bb |2 +- meta/recipes-extended/libidn/libidn_1.22.bb|2 +- meta/recipes-extended/libtirpc/libtirpc_0.2.2.bb |4 ++-- meta/recipes-extended/mktemp/mktemp_1.7.bb |2 +- meta/recipes-extended/xdg-utils/xdg-utils_1.0.2.bb |2 +- .../ttf-fonts/liberation-fonts_1.06.bb |2 +- .../xorg-driver/xf86-driver-common.inc |2 +- meta/recipes-multimedia/libomxil/libomxil_0.3.3.bb |2 +- meta/recipes-sato/eds/eds-tools_bzr.bb |2 +- meta/recipes-sato/gaku/gaku_svn.bb |2 +- meta/recipes-sato/libical/libical_0.46.bb |2 +- meta/recipes-sato/libowl/libowl_svn.bb |2 +- .../recipes-sato/owl-video-widget/libowl-av_svn.bb |2 +- meta/recipes-sato/puzzles/oh-puzzles_svn.bb|2 +- meta/recipes-sato/puzzles/puzzles_r9175.bb |2 +- meta/recipes-sato/screenshot/screenshot_svn.bb |2 +- meta/recipes-support/apr/apr-util_1.3.10.bb|2 +- meta/recipes-support/apr/apr_1.4.2.bb |2 +- meta/recipes-support/liboil/liboil_0.3.17.bb |2 +- meta/recipes-support/neon/neon_0.29.5.bb |2 +- 48 files changed, 50 insertions(+), 50 deletions(-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] prelink issue with ppc64?
On 8/4/11 12:37 AM, Kumar Gala wrote: On Aug 3, 2011, at 10:09 AM, Mark Hatle wrote: On 8/3/11 9:53 AM, Kumar Gala wrote: On Aug 3, 2011, at 9:37 AM, Mark Hatle wrote: On 8/3/11 12:35 AM, Kumar Gala wrote: If prelink gets a chance to properly run I get a rootfs that does: /sbin/init: relocation error: /lib64/libc.so.6: symbol _rtld_global_ro, version GLIBC_PRIVATE not defined in file ld64.so.1 with link time reference if 'baselib' is set to /lib we get: /local/home/galak/git/poky/build-p5020/tmp/sysroots/x86_64-linux/usr/sbin/prelink: /sbin/init.sysvinit: Using /lib/ld64.so.1, not /lib64/ld64.so.1 as dynamic linker if 'baselib' is set to /lib64 we get: Assigned virtual address space slots for libraries: /lib64/ld64.so.1 0080f491-0080f49473d0 /lib64/libc.so.6 0080f495-0080f4afe090 /lib64/libdl.so.2 0080f4b1-0080f4b23520 /lib64/libcrypt.so.1 0080f4b1-0080f4b57708 /lib64/libutil.so.1 0080f4b1-0080f4b234a0 Would prelink /lib64/ld-2.13.so Would prelink /lib64/libc-2.13.so Not sure what prelink is doing but it seems to breaking things. Any ideas? --- I'm also concerned that we use /etc/prelink.conf when invoking prelink. Prelinker is being run within the rootfs, so the /etc/prelink.conf being used is the one inside of the image -- NOT the system version. Is this because of psuedo or something else? In the cross prelinker, we pass in the --root=image. This instructs the cross-prelinker to prefix image to most paths. I would suspect that the cross-prelinker rtld emulation is likely setup for the LSB style library paths and may be causing some of the problems. You can run the cross-prelinker's rtld emulation by running the prelink-rtld program located in build/tmp-eglibc/work/x86_64-linux/usr/sbin/prelink-rtld Passing --root=path will setup the sysroot path for reference, adding in --target-paths will allow you to pass further arguments as referenced on the sysroot. So prelink-rtld --root=/foo/bar/build/sysroot/image --target-paths /sbin/init Should give you back an ldd like syntax within the sysroot, for /sbin/init. (without --target-paths, you need to specify the full path to the /sbin/init.. this is useful when running the rtld against items outside of the image.) I'd suggest simply disabling prelink and getting everything to work first.. once it does we can work through any prelinker issues. (Prelink on PPC64 hasn't been tested within the oe-core environment.. so it could very well have issues beyond the ld.so path.) Everything else is working, so prelink is what fails for me (at least for a simple minimal) build. any suggestions on how to try and debug further, who might be more familiar with prelink and what its doing? When I ran readelf -a on ld-2.13.so after prelink was getting weird results, not sure if thats normal or not. I'm the prelink maintainer for Yocto, however I know more about the way the cross-prelinker functionality works then how the ELF specific prelink functions work. I've been relying on the upstream prelink project to manage the individual architecture/ABI prelink standards. My suggestion is to disable cross-prelinking, and revert to the upstream prelink project -- run the binary on the target and see if it fails in the same way. If it does, then we know it's a deeper problem then the cross prelink integration. You can pull down the git repository: git://git.yoctoproject.org/prelink-cross.git The master branch is identical to the upstream SVN branch. The cross_prelink branch is the current state of integration. So running prelink on target seems ok. I used the version from prelink_git.bb. The prelink_git versions should be the cross-prelink version. The only difference MIGHT be the rtld emulation, but I'm not sure. Any chance you can diff the output between the cross prelink and the on-target prelink? The other thing is to run the prelinker (on both systems) with the -v. This should give a more verbose set of prelinker information. It would be interesting if there are any differences between the two. --Mark - 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
Re: [OE-core] [PATCH] prelink: Add lib64 dirs to prelink.conf
On 8/4/11 1:05 AM, Kumar Gala wrote:
Handle multlib or cases that baselib is lib64.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
Acked-by: Mark Hatle mark.ha...@windriver.com
(BTW I think as we move more into the multilib stuff, we'll likely want to
generate this list from the final multilib configuration.. but for now this
should be good.)
---
meta/recipes-devtools/prelink/prelink/prelink.conf |8
meta/recipes-devtools/prelink/prelink_git.bb |2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/meta/recipes-devtools/prelink/prelink/prelink.conf
b/meta/recipes-devtools/prelink/prelink/prelink.conf
index c5a4f4a..ed30c28 100644
--- a/meta/recipes-devtools/prelink/prelink/prelink.conf
+++ b/meta/recipes-devtools/prelink/prelink/prelink.conf
@@ -12,7 +12,7 @@
-l /usr/bin
-l /usr/X11R6/bin
-l /usr/games
--l /usr/local/lib
--l /lib
--l /usr/lib
--l /usr/X11R6/lib
+-l /usr/local/lib{,64}
+-l /lib{,64}
+-l /usr/lib{,64}
+-l /usr/X11R6/lib{,64}
diff --git a/meta/recipes-devtools/prelink/prelink_git.bb
b/meta/recipes-devtools/prelink/prelink_git.bb
index c653d4d..bb95da7 100644
--- a/meta/recipes-devtools/prelink/prelink_git.bb
+++ b/meta/recipes-devtools/prelink/prelink_git.bb
@@ -10,7 +10,7 @@ LICENSE = GPLv2
LIC_FILES_CHKSUM = file://COPYING;md5=c93c0550bd3173f4504b2cbd8991e50b
SRCREV = ac461e73b17253a4da25c5aafeac7193b553156c
PV = 1.0+git${SRCPV}
-PR = r4
+PR = r5
#
# The cron script attempts to re-prelink the system daily -- on
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] eglibc testing?
On Thursday, August 04, 2011 10:24:00 AM Phil Blundell wrote: On Thu, 2011-06-30 at 07:29 -0700, Khem Raj wrote: On 06/30/2011 03:32 AM, Phil Blundell wrote: On Thu, 2011-06-16 at 16:18 -0700, Khem Raj wrote: Yes I think I should put together my mechanism somewhere and post it and dejaGNU setup I use for cross testing Did you get a chance to do this at all? so far no. Let me collect them and make sure they work Just a quick reminder about this :-) Sorry Phil, I owe it to you :) I have not finished it yet. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- Khem Raj ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] prelink issue with ppc64?
On 8/4/11 9:03 AM, Kumar Gala wrote: On Aug 4, 2011, at 12:37 AM, Kumar Gala wrote: On Aug 3, 2011, at 10:09 AM, Mark Hatle wrote: On 8/3/11 9:53 AM, Kumar Gala wrote: On Aug 3, 2011, at 9:37 AM, Mark Hatle wrote: On 8/3/11 12:35 AM, Kumar Gala wrote: If prelink gets a chance to properly run I get a rootfs that does: /sbin/init: relocation error: /lib64/libc.so.6: symbol _rtld_global_ro, version GLIBC_PRIVATE not defined in file ld64.so.1 with link time reference if 'baselib' is set to /lib we get: /local/home/galak/git/poky/build-p5020/tmp/sysroots/x86_64-linux/usr/sbin/prelink: /sbin/init.sysvinit: Using /lib/ld64.so.1, not /lib64/ld64.so.1 as dynamic linker if 'baselib' is set to /lib64 we get: Assigned virtual address space slots for libraries: /lib64/ld64.so.1 0080f491-0080f49473d0 /lib64/libc.so.6 0080f495-0080f4afe090 /lib64/libdl.so.2 0080f4b1-0080f4b23520 /lib64/libcrypt.so.1 0080f4b1-0080f4b57708 /lib64/libutil.so.1 0080f4b1-0080f4b234a0 Would prelink /lib64/ld-2.13.so Would prelink /lib64/libc-2.13.so Not sure what prelink is doing but it seems to breaking things. Any ideas? --- I'm also concerned that we use /etc/prelink.conf when invoking prelink. Prelinker is being run within the rootfs, so the /etc/prelink.conf being used is the one inside of the image -- NOT the system version. Is this because of psuedo or something else? In the cross prelinker, we pass in the --root=image. This instructs the cross-prelinker to prefix image to most paths. I would suspect that the cross-prelinker rtld emulation is likely setup for the LSB style library paths and may be causing some of the problems. You can run the cross-prelinker's rtld emulation by running the prelink-rtld program located in build/tmp-eglibc/work/x86_64-linux/usr/sbin/prelink-rtld Passing --root=path will setup the sysroot path for reference, adding in --target-paths will allow you to pass further arguments as referenced on the sysroot. So prelink-rtld --root=/foo/bar/build/sysroot/image --target-paths /sbin/init Should give you back an ldd like syntax within the sysroot, for /sbin/init. (without --target-paths, you need to specify the full path to the /sbin/init.. this is useful when running the rtld against items outside of the image.) I'd suggest simply disabling prelink and getting everything to work first.. once it does we can work through any prelinker issues. (Prelink on PPC64 hasn't been tested within the oe-core environment.. so it could very well have issues beyond the ld.so path.) Everything else is working, so prelink is what fails for me (at least for a simple minimal) build. any suggestions on how to try and debug further, who might be more familiar with prelink and what its doing? When I ran readelf -a on ld-2.13.so after prelink was getting weird results, not sure if thats normal or not. I'm the prelink maintainer for Yocto, however I know more about the way the cross-prelinker functionality works then how the ELF specific prelink functions work. I've been relying on the upstream prelink project to manage the individual architecture/ABI prelink standards. My suggestion is to disable cross-prelinking, and revert to the upstream prelink project -- run the binary on the target and see if it fails in the same way. If it does, then we know it's a deeper problem then the cross prelink integration. You can pull down the git repository: git://git.yoctoproject.org/prelink-cross.git The master branch is identical to the upstream SVN branch. The cross_prelink branch is the current state of integration. So running prelink on target seems ok. I used the version from prelink_git.bb. - k I get the following output when running cross_prelink by hand: prelink: /lib64/libc.so.6: Recorded 1 dependencies, now seeing -1 I noticed this as well (in dmesg): prelink-rtld[14492]: segfault at 289986a94 ip 00408de2 sp 7fff65ad3c10 error 4 in prelink-rtld[40+e000] That could explain it.. interesting that prelink didn't see the failure. I'd suggest running w/ -v and see if that will tell you what it was processing at the time. Also collect a core and run me a back trace. (You should create a bug on bugzilla.yoctoproject.org.. add that info and assign it to me.. I'll try to reproduce it or at least trace through the code and see what may have lead to the failure.) --Mark - k ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/9] Various site files: Drop monotone
On Thu, 2011-08-04 at 08:08 -0700, Khem Raj wrote:
On Thursday, August 04, 2011 02:52:22 PM Richard Purdie wrote:
On Wed, 2011-07-27 at 15:56 -0700, Tom Rini wrote:
# links
ac_cv_lib_png_png_create_info_struct=${ac_cv_lib_png_png_create_info_s
truct=yes}
-# mono
-cv_mono_sizeof_sunpath=108
-
Isn't mono different from monotone?
yes its for mono. I think we should keep it since there are many users of mono
from oe.dev world who would want mono in future may be from future meta-mono
Why couldn't the site entry just go in meta-mono too, if that's where
the recipes are living? I don't think it makes much/any sense (for
testability reasons as much as anything else) to have a load of siteinfo
entries lying around that no oe-core recipe actually uses.
p.
___
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
Phil Blundell wrote on 2011-08-04: On Thu, 2011-08-04 at 22:49 +0800, Cui, Dexuan wrote: +BDIR=`readlink -f $BDIR` +if [ -z $BDIR ]; then +PARENTDIR=`dirname $1` +echo 2 Error: the directory $PARENTDIR does not exist? return 1 fi fi Just out of curiosity, could you not just do mkdir -p $BDIR and avoid this whole set of complicated tests? Or is there some reason why it's actually important to know whether the parent directory existed already? Hi Phil, Actually in scripts/oe-setup-builddir, we do have a line mkdir -p $BUILDDIR/conf . The issue is: readlink -f not_existent_dir/build returns empty, so BUILDDIR would be assigned with `pwd` and this is not expected. I don't really know why the test readlink -f is here -- readlink -f is used 3 times in scripts/oe-buildenv-internal. Maybe RP knows the history? I also think we can drop the tests readlink -f since we use mkdir -p? Thanks, -- Dexuan ___ 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 08/04/2011 01:08 AM, Samuel Stirtzel wrote: 2011/8/3 Khem Rajraj.k...@gmail.com: There is a smart script in scripts/ dir that you could use something like this runqemu /var/oe-core/tmp-eglibc/deploy/images/qemuarm/zImage-qemuarm.bin /var/oe-core/tmp-eglibc/deploy/images/qemuarm/console-image-qemuarm.ext2 and it will setup everything (even networking) for you Already tried this one, but for some unknown reasons it doesn't work, I get the following output: - samuel@S-Linux:/var/oe-core/setup-scripts$ 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: sudo runqemu-ifupgid native-sysroot-basedir samuel@S-Linux:/var/oe-core/setup-scripts$ A fix for this problem has been committed to oe-core already. Update and retry - This is all, no QEMU window appears or any other messages, or do I have run something else. Nothing more. It should pop up a window where you will see the new machine booting For remote debugging purpose I wrote a generic script that will set up a tap and bridge interface and restores the network connection after qemu closes. This script can also run QEMU with standard network settings. Basically runqemu and my scripts should do the same thing(?), but since runqemu doesn't work for me I made my own scripts (also it won't need sudo if the standard network option is used). The scripts are attached in this mail, to run the script you could use sh /somedir/generic_qemu_loader.sh --help. This script however may not work on other systems than ubuntu, I share it only for information exchange purpose. If you still want to use it, keep in thought that I am a beginner in shell coding! The difference between the standard network settings and the bridge/tap interfaces is, that the standard network only supports outgoing TCP and UDP connections while the bridge/tap interface can be used to host, for example, a gdbserver. 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
Re: [OE-core] [PATCHv2] gst-plugins: partially sync packaging with OE .dev
Op 4 aug 2011, om 16:37 heeft Saul Wold het volgende geschreven:
On 07/28/2011 03:14 AM, Koen Kooi wrote:
Op 28 jul. 2011, om 11:49 heeft Phil Blundell het volgende
geschreven:
On Thu, 2011-07-28 at 11:44 +0200, Koen Kooi wrote:
+ALLOW_EMPTY = 1
Is that necessary? You seem to be setting ALLOW_EMPTY_${PN}-
meta=1 in
your python code anyway.
In OE classic that was to keep ${PN} alive after all libs and apps
were removed, I'm not sure we need it in OE-core.
Koen,
Are you re-submitting a v2 pf this patch or do you still want it to
go as is?
As is would be fine for me.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/9] Various site files: Drop monotone
On 08/04/2011 08:14 AM, Phil Blundell wrote:
On Thu, 2011-08-04 at 08:08 -0700, Khem Raj wrote:
On Thursday, August 04, 2011 02:52:22 PM Richard Purdie wrote:
On Wed, 2011-07-27 at 15:56 -0700, Tom Rini wrote:
# links
ac_cv_lib_png_png_create_info_struct=${ac_cv_lib_png_png_create_info_s
truct=yes}
-# mono
-cv_mono_sizeof_sunpath=108
-
Isn't mono different from monotone?
yes its for mono. I think we should keep it since there are many users of mono
from oe.dev world who would want mono in future may be from future meta-mono
Why couldn't the site entry just go in meta-mono too, if that's where
the recipes are living? I don't think it makes much/any sense (for
testability reasons as much as anything else) to have a load of siteinfo
entries lying around that no oe-core recipe actually uses.
yes it could. Infact having this variable exported during mono configure
would be better solution.
p.
___
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] do_rootfs failure for core-image-sato on mpc8315e-rdb
| error: Failed dependencies: | hicolor-icon-theme is needed by tasks-0.19-r0.ppc603e | hicolor-icon-theme is needed by connman-gnome-0.5-r6.ppc603e | error: LOOP: | error: removing busybox-1.18.4-r7.ppc603e Requires(hint): busybox-udhcpc from tsort relations. | error: removing busybox-udhcpc-1.18.4-r7.ppc603e Requires(post): /bin/sh from tsort relations. | error: LOOP: | error: removing augeas-0.8.1-r0.ppc603e Requires: libaugeas0 = 0.8.1 from tsort relations. | error: removing libaugeas0-0.8.1-r0.ppc603e Requires(hint): augeas from tsort relations. | error: LOOP: | error: removing busybox-1.18.4-r7.ppc603e Requires(hint): busybox-syslog from tsort relations. | error: removing busybox-syslog-1.18.4-r7.ppc603e Requires(post): /bin/sh from tsort relations. | error: LOOP: | error: removing libudev0-164-r4.ppc603e Requires: udev = 164-r4 from tsort relations. | error: removing udev-164-r4.ppc603e Requires: libudev0 = 164 from tsort relations. | error: LOOP: | error: removing libdbus-1-3-1.4.12-r0.ppc603eERROR: Function 'do_rootfs' failed (see /local/home/galak/git/poky/build/tmp/work/mpc8315e_rdb-poky-linux/core-image-sato-1.0-r0/temp/log.do_rootfs.9312 for further information) | Requires(hint): dbus-1 from tsort relations. | error: removing dbus-1-1.4.12-r0.ppc603e Requires: libdbus-1-3 = 1.4.12 from tsort relations. | error: LOOP: | error: removing bash-dev-4.1-r2.ppc603e Requires(hint): ncurses-dev from tsort relations. | error: removing ncurses-dev-5.9-r1.1.ppc603e Requires(hint): libc6-dev from tsort relations. | error: removing libc6-dev-2.13-r11+svnr14157.ppc603e Requires(hint): bash-dev from tsort relations. | error: LOOP: | error: removing bash-dbg-4.1-r2.ppc603e Requires(hint): eglibc-dbg from tsort relations. | error: removing eglibc-dbg-2.13-r11+svnr14157.ppc603e Requires(hint): bash-dbg from tsort relations. | error: LOOP: | error: removing libecal-1.2-7-2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f-r1.ppc603e Requires(hint): libedata-cal-1.2-7 from tsort relations. | error: removing libedata-cal-1.2-7-2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f-r1.ppc603e Requires: libecal-1.2-7 = 2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f from tsort relations. | error: LOOP: | error: removing libebook-1.2-9-2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f-r1.ppc603e Requires(hint): libedata-book-1.2-2 from tsort relations. | error: removing libedata-book-1.2-2-2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f-r1.ppc603e Requires: libebook-1.2-9 = 2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f from tsort relations. NOTE: package core-image-sato-1.0-r0: task do_rootfs: Failed ERROR: Task 8 (/local/home/galak/git/poky/meta/recipes-sato/images/core-image-sato.bb, do_rootfs) failed with exit code '1' ERROR: '/local/home/galak/git/poky/meta/recipes-sato/images/core-image-sato.bb' failed thoughts? - k ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] do_rootfs failure for core-image-sato on mpc8315e-rdb
On Thu, 2011-08-04 at 10:58 -0500, Kumar Gala wrote: | error: Failed dependencies: | hicolor-icon-theme is needed by tasks-0.19-r0.ppc603e | hicolor-icon-theme is needed by connman-gnome-0.5-r6.ppc603e | error: LOOP: | error: removing busybox-1.18.4-r7.ppc603e Requires(hint): busybox-udhcpc from tsort relations. | error: removing busybox-udhcpc-1.18.4-r7.ppc603e Requires(post): /bin/sh from tsort relations. | error: LOOP: | error: removing augeas-0.8.1-r0.ppc603e Requires: libaugeas0 = 0.8.1 from tsort relations. | error: removing libaugeas0-0.8.1-r0.ppc603e Requires(hint): augeas from tsort relations. | error: LOOP: | error: removing busybox-1.18.4-r7.ppc603e Requires(hint): busybox-syslog from tsort relations. | error: removing busybox-syslog-1.18.4-r7.ppc603e Requires(post): /bin/sh from tsort relations. | error: LOOP: | error: removing libudev0-164-r4.ppc603e Requires: udev = 164-r4 from tsort relations. | error: removing udev-164-r4.ppc603e Requires: libudev0 = 164 from tsort relations. | error: LOOP: | error: removing libdbus-1-3-1.4.12-r0.ppc603eERROR: Function 'do_rootfs' failed (see /local/home/galak/git/poky/build/tmp/work/mpc8315e_rdb-poky-linux/core-image-sato-1.0-r0/temp/log.do_rootfs.9312 for further information) | Requires(hint): dbus-1 from tsort relations. | error: removing dbus-1-1.4.12-r0.ppc603e Requires: libdbus-1-3 = 1.4.12 from tsort relations. | error: LOOP: | error: removing bash-dev-4.1-r2.ppc603e Requires(hint): ncurses-dev from tsort relations. | error: removing ncurses-dev-5.9-r1.1.ppc603e Requires(hint): libc6-dev from tsort relations. | error: removing libc6-dev-2.13-r11+svnr14157.ppc603e Requires(hint): bash-dev from tsort relations. | error: LOOP: | error: removing bash-dbg-4.1-r2.ppc603e Requires(hint): eglibc-dbg from tsort relations. | error: removing eglibc-dbg-2.13-r11+svnr14157.ppc603e Requires(hint): bash-dbg from tsort relations. | error: LOOP: | error: removing libecal-1.2-7-2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f-r1.ppc603e Requires(hint): libedata-cal-1.2-7 from tsort relations. | error: removing libedata-cal-1.2-7-2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f-r1.ppc603e Requires: libecal-1.2-7 = 2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f from tsort relations. | error: LOOP: | error: removing libebook-1.2-9-2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f-r1.ppc603e Requires(hint): libedata-book-1.2-2 from tsort relations. | error: removing libedata-book-1.2-2-2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f-r1.ppc603e Requires: libebook-1.2-9 = 2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f from tsort relations. NOTE: package core-image-sato-1.0-r0: task do_rootfs: Failed ERROR: Task 8 (/local/home/galak/git/poky/meta/recipes-sato/images/core-image-sato.bb, do_rootfs) failed with exit code '1' ERROR: '/local/home/galak/git/poky/meta/recipes-sato/images/core-image-sato.bb' failed thoughts? Was this a recent build from scratch? I suspect Koen's recent icon bbclass change and we probably need to ensure hicolor-icon-theme is added do DEPENDS (instead of RDEPENDS like it used to be). Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] do_rootfs failure for core-image-sato on mpc8315e-rdb
On 8/4/11 10:58 AM, Kumar Gala wrote: | error: Failed dependencies: | hicolor-icon-theme is needed by tasks-0.19-r0.ppc603e | hicolor-icon-theme is needed by connman-gnome-0.5-r6.ppc603e The actual failure is above... the items below are indicating circular dependencies within the resolution. They're tagged as errors for reporting purposes but are non-fatal | error: LOOP: | error: removing busybox-1.18.4-r7.ppc603e Requires(hint): busybox-udhcpc from tsort relations. | error: removing busybox-udhcpc-1.18.4-r7.ppc603e Requires(post): /bin/sh from tsort relations. | error: LOOP: | error: removing augeas-0.8.1-r0.ppc603e Requires: libaugeas0 = 0.8.1 from tsort relations. | error: removing libaugeas0-0.8.1-r0.ppc603e Requires(hint): augeas from tsort relations. | error: LOOP: | error: removing busybox-1.18.4-r7.ppc603e Requires(hint): busybox-syslog from tsort relations. | error: removing busybox-syslog-1.18.4-r7.ppc603e Requires(post): /bin/sh from tsort relations. | error: LOOP: | error: removing libudev0-164-r4.ppc603e Requires: udev = 164-r4 from tsort relations. | error: removing udev-164-r4.ppc603e Requires: libudev0 = 164 from tsort relations. | error: LOOP: | error: removing libdbus-1-3-1.4.12-r0.ppc603eERROR: Function 'do_rootfs' failed (see /local/home/galak/git/poky/build/tmp/work/mpc8315e_rdb-poky-linux/core-image-sato-1.0-r0/temp/log.do_rootfs.9312 for further information) | Requires(hint): dbus-1 from tsort relations. | error: removing dbus-1-1.4.12-r0.ppc603e Requires: libdbus-1-3 = 1.4.12 from tsort relations. | error: LOOP: | error: removing bash-dev-4.1-r2.ppc603e Requires(hint): ncurses-dev from tsort relations. | error: removing ncurses-dev-5.9-r1.1.ppc603e Requires(hint): libc6-dev from tsort relations. | error: removing libc6-dev-2.13-r11+svnr14157.ppc603e Requires(hint): bash-dev from tsort relations. | error: LOOP: | error: removing bash-dbg-4.1-r2.ppc603e Requires(hint): eglibc-dbg from tsort relations. | error: removing eglibc-dbg-2.13-r11+svnr14157.ppc603e Requires(hint): bash-dbg from tsort relations. | error: LOOP: | error: removing libecal-1.2-7-2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f-r1.ppc603e Requires(hint): libedata-cal-1.2-7 from tsort relations. | error: removing libedata-cal-1.2-7-2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f-r1.ppc603e Requires: libecal-1.2-7 = 2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f from tsort relations. | error: LOOP: | error: removing libebook-1.2-9-2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f-r1.ppc603e Requires(hint): libedata-book-1.2-2 from tsort relations. | error: removing libedata-book-1.2-2-2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f-r1.ppc603e Requires: libebook-1.2-9 = 2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f from tsort relations. NOTE: package core-image-sato-1.0-r0: task do_rootfs: Failed ERROR: Task 8 (/local/home/galak/git/poky/meta/recipes-sato/images/core-image-sato.bb, do_rootfs) failed with exit code '1' ERROR: '/local/home/galak/git/poky/meta/recipes-sato/images/core-image-sato.bb' failed thoughts? - 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
Re: [OE-core] do_rootfs failure for core-image-sato on mpc8315e-rdb
On 08/04/2011 09:13 AM, Richard Purdie wrote: On Thu, 2011-08-04 at 10:58 -0500, Kumar Gala wrote: | error: Failed dependencies: | hicolor-icon-theme is needed by tasks-0.19-r0.ppc603e | hicolor-icon-theme is needed by connman-gnome-0.5-r6.ppc603e | error: LOOP: | error: removing busybox-1.18.4-r7.ppc603e Requires(hint): busybox-udhcpc from tsort relations. | error: removing busybox-udhcpc-1.18.4-r7.ppc603e Requires(post): /bin/sh from tsort relations. | error: LOOP: | error: removing augeas-0.8.1-r0.ppc603e Requires: libaugeas0= 0.8.1 from tsort relations. | error: removing libaugeas0-0.8.1-r0.ppc603e Requires(hint): augeas from tsort relations. | error: LOOP: | error: removing busybox-1.18.4-r7.ppc603e Requires(hint): busybox-syslog from tsort relations. | error: removing busybox-syslog-1.18.4-r7.ppc603e Requires(post): /bin/sh from tsort relations. | error: LOOP: | error: removing libudev0-164-r4.ppc603e Requires: udev = 164-r4 from tsort relations. | error: removing udev-164-r4.ppc603e Requires: libudev0= 164 from tsort relations. | error: LOOP: | error: removing libdbus-1-3-1.4.12-r0.ppc603eERROR: Function 'do_rootfs' failed (see /local/home/galak/git/poky/build/tmp/work/mpc8315e_rdb-poky-linux/core-image-sato-1.0-r0/temp/log.do_rootfs.9312 for further information) | Requires(hint): dbus-1 from tsort relations. | error: removing dbus-1-1.4.12-r0.ppc603e Requires: libdbus-1-3= 1.4.12 from tsort relations. | error: LOOP: | error: removing bash-dev-4.1-r2.ppc603e Requires(hint): ncurses-dev from tsort relations. | error: removing ncurses-dev-5.9-r1.1.ppc603e Requires(hint): libc6-dev from tsort relations. | error: removing libc6-dev-2.13-r11+svnr14157.ppc603e Requires(hint): bash-dev from tsort relations. | error: LOOP: | error: removing bash-dbg-4.1-r2.ppc603e Requires(hint): eglibc-dbg from tsort relations. | error: removing eglibc-dbg-2.13-r11+svnr14157.ppc603e Requires(hint): bash-dbg from tsort relations. | error: LOOP: | error: removing libecal-1.2-7-2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f-r1.ppc603e Requires(hint): libedata-cal-1.2-7 from tsort relations. | error: removing libedata-cal-1.2-7-2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f-r1.ppc603e Requires: libecal-1.2-7= 2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f from tsort relations. | error: LOOP: | error: removing libebook-1.2-9-2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f-r1.ppc603e Requires(hint): libedata-book-1.2-2 from tsort relations. | error: removing libedata-book-1.2-2-2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f-r1.ppc603e Requires: libebook-1.2-9= 2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f from tsort relations. NOTE: package core-image-sato-1.0-r0: task do_rootfs: Failed ERROR: Task 8 (/local/home/galak/git/poky/meta/recipes-sato/images/core-image-sato.bb, do_rootfs) failed with exit code '1' ERROR: '/local/home/galak/git/poky/meta/recipes-sato/images/core-image-sato.bb' failed thoughts? Was this a recent build from scratch? I suspect Koen's recent icon bbclass change and we probably need to ensure hicolor-icon-theme is added do DEPENDS (instead of RDEPENDS like it used to be). It seems it's pulled in by gtk-icons.bbclass as an RDEPENDS, should that be changed? Sau! Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] do_rootfs failure for core-image-sato on mpc8315e-rdb
On Thu, 2011-08-04 at 09:26 -0700, Saul Wold wrote: On 08/04/2011 09:13 AM, Richard Purdie wrote: Was this a recent build from scratch? I suspect Koen's recent icon bbclass change and we probably need to ensure hicolor-icon-theme is added do DEPENDS (instead of RDEPENDS like it used to be). It seems it's pulled in by gtk-icons.bbclass as an RDEPENDS, should that be changed? If it's an RDEPENDS that's being injected from a python task (other perhaps than an anonfunc that runs immediately after parsing), it needs to go in DEPENDS as well. It sounds as though that's the case here. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] do_rootfs failure for core-image-sato on mpc8315e-rdb
On Aug 4, 2011, at 11:13 AM, Richard Purdie wrote: On Thu, 2011-08-04 at 10:58 -0500, Kumar Gala wrote: | error: Failed dependencies: | hicolor-icon-theme is needed by tasks-0.19-r0.ppc603e | hicolor-icon-theme is needed by connman-gnome-0.5-r6.ppc603e | error: LOOP: | error: removing busybox-1.18.4-r7.ppc603e Requires(hint): busybox-udhcpc from tsort relations. | error: removing busybox-udhcpc-1.18.4-r7.ppc603e Requires(post): /bin/sh from tsort relations. | error: LOOP: | error: removing augeas-0.8.1-r0.ppc603e Requires: libaugeas0 = 0.8.1 from tsort relations. | error: removing libaugeas0-0.8.1-r0.ppc603e Requires(hint): augeas from tsort relations. | error: LOOP: | error: removing busybox-1.18.4-r7.ppc603e Requires(hint): busybox-syslog from tsort relations. | error: removing busybox-syslog-1.18.4-r7.ppc603e Requires(post): /bin/sh from tsort relations. | error: LOOP: | error: removing libudev0-164-r4.ppc603e Requires: udev = 164-r4 from tsort relations. | error: removing udev-164-r4.ppc603e Requires: libudev0 = 164 from tsort relations. | error: LOOP: | error: removing libdbus-1-3-1.4.12-r0.ppc603eERROR: Function 'do_rootfs' failed (see /local/home/galak/git/poky/build/tmp/work/mpc8315e_rdb-poky-linux/core-image-sato-1.0-r0/temp/log.do_rootfs.9312 for further information) | Requires(hint): dbus-1 from tsort relations. | error: removing dbus-1-1.4.12-r0.ppc603e Requires: libdbus-1-3 = 1.4.12 from tsort relations. | error: LOOP: | error: removing bash-dev-4.1-r2.ppc603e Requires(hint): ncurses-dev from tsort relations. | error: removing ncurses-dev-5.9-r1.1.ppc603e Requires(hint): libc6-dev from tsort relations. | error: removing libc6-dev-2.13-r11+svnr14157.ppc603e Requires(hint): bash-dev from tsort relations. | error: LOOP: | error: removing bash-dbg-4.1-r2.ppc603e Requires(hint): eglibc-dbg from tsort relations. | error: removing eglibc-dbg-2.13-r11+svnr14157.ppc603e Requires(hint): bash-dbg from tsort relations. | error: LOOP: | error: removing libecal-1.2-7-2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f-r1.ppc603e Requires(hint): libedata-cal-1.2-7 from tsort relations. | error: removing libedata-cal-1.2-7-2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f-r1.ppc603e Requires: libecal-1.2-7 = 2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f from tsort relations. | error: LOOP: | error: removing libebook-1.2-9-2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f-r1.ppc603e Requires(hint): libedata-book-1.2-2 from tsort relations. | error: removing libedata-book-1.2-2-2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f-r1.ppc603e Requires: libebook-1.2-9 = 2.30+git1+7337d11aed576e7caaa12b4e881ad8d33668799f from tsort relations. NOTE: package core-image-sato-1.0-r0: task do_rootfs: Failed ERROR: Task 8 (/local/home/galak/git/poky/meta/recipes-sato/images/core-image-sato.bb, do_rootfs) failed with exit code '1' ERROR: '/local/home/galak/git/poky/meta/recipes-sato/images/core-image-sato.bb' failed thoughts? Was this a recent build from scratch? I suspect Koen's recent icon bbclass change and we probably need to ensure hicolor-icon-theme is added do DEPENDS (instead of RDEPENDS like it used to be). Yes, recent as of this morning. - k ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] bitbake.conf/powerpc64: Set baselib to 'lib64' for ppc64
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
meta/conf/bitbake.conf |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 6f0b42c..1d83459 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -7,7 +7,9 @@
#
# Used by multilib code to change the library paths
-baselib = lib
+baselib = ${BASELIB}
+BASELIB = lib
+BASELIB_powerpc64 = lib64
# Path prefixes
export base_prefix =
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] gcc: use ${base_lib} to match gcc default configuration
Rather than tweaking MULTILIB_DIRNAMES MULTILIB_OSDIRNAMES like is
done for x86-64 via 64bithack.patch. We can just go with gcc defaults
and utilize ${base_lib} for where to find gcc libs.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
.../gcc/gcc-cross-intermediate.inc |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-devtools/gcc/gcc-cross-intermediate.inc
b/meta/recipes-devtools/gcc/gcc-cross-intermediate.inc
index df5958a..7b1bb38 100644
--- a/meta/recipes-devtools/gcc/gcc-cross-intermediate.inc
+++ b/meta/recipes-devtools/gcc/gcc-cross-intermediate.inc
@@ -34,7 +34,7 @@ do_compile () {
do_install () {
oe_runmake 'DESTDIR=${D}' install
install -d ${D}${target_base_libdir}/
- mv ${D}${exec_prefix}/${TARGET_SYS}/lib/* ${D}${target_base_libdir}/
+ mv ${D}${exec_prefix}/${TARGET_SYS}/${baselib}/*
${D}${target_base_libdir}/
# We don't really need this (here shares/ contains man/, info/,
locale/).
rm -rf ${D}${datadir}/
--
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] bitbake.conf/powerpc64: Set baselib to 'lib64' for ppc64
On 08/04/2011 11:51 AM, Kumar Gala wrote:
Signed-off-by: Kumar Galaga...@kernel.crashing.org
---
meta/conf/bitbake.conf |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 6f0b42c..1d83459 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -7,7 +7,9 @@
#
# Used by multilib code to change the library paths
-baselib = lib
+baselib = ${BASELIB}
+BASELIB = lib
Should the be ?=
+BASELIB_powerpc64 = lib64
And this located in the arch-powerpc64 file?
Sau!
# Path prefixes
export base_prefix =
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] bitbake.conf/powerpc64: Set baselib to 'lib64' for ppc64
On Aug 4, 2011, at 2:09 PM, Saul Wold wrote:
On 08/04/2011 11:51 AM, Kumar Gala wrote:
Signed-off-by: Kumar Galaga...@kernel.crashing.org
---
meta/conf/bitbake.conf |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 6f0b42c..1d83459 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -7,7 +7,9 @@
#
# Used by multilib code to change the library paths
-baselib = lib
+baselib = ${BASELIB}
+BASELIB = lib
Should the be ?=
+BASELIB_powerpc64 = lib64
And this located in the arch-powerpc64 file?
Sau!
This is what Richard recommend (that we do this just in bitbake.conf). I don't
think this can live in arch-powerpc64 and things work properly for it to be
picked up everywhere it needs be.
- k
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Howto pin u-boot to a version supplied by oe-core
On Thursday, August 04, 2011 03:34:17 AM Khem Raj wrote: PREFERRED_VERSION_pn-u-boot = v2011.03+git% Works perfect: Both 2011.03 and 2011.06 are running fine. Thanks ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 00/10] Commits to enable x32 infrastructure
From: Nitin A Kamble nitin.a.kam...@intel.com Here are commits to enable infrastructure for use of x32 layer. The kernel fixes from Bruce are for getting linux-korg recipe to work. The following changes since commit 5561aaad28ed6db6d962f88db32814043044731f: eglibc: Fix patch merge breakage (2011-08-04 15:41:19 +0100) 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 Bruce Ashfield (3): kern-tools: extend arbitrary repository support linux-yocto: process the existing branch for configuration linux-yocto: pass KMACHINE to updateme, not MACHINE Nitin A Kamble (7): glibc: bring back the needed support for glibc recipes toolchain-scripts other classes: add TARGET_LD_ARCH TARGET_AS_ARCH vars kernel,module-base.bbclass: fix KERNEL_LD KERNEL_AR vars siteinfo.bbclass: add entries for new x86_64 ABI targets insane.bbclass: add entries for linux-gnuABI x86 tune inc files: add x32 abi tune parameters local.conf.sample: make BBMASK assignment weak meta-yocto/conf/local.conf.sample |2 +- meta/classes/allarch.bbclass |2 + meta/classes/cross-canadian.bbclass|2 + meta/classes/cross.bbclass |2 + meta/classes/crosssdk.bbclass |2 + meta/classes/insane.bbclass|9 + meta/classes/kernel-yocto.bbclass | 11 +- meta/classes/kernel.bbclass|2 +- meta/classes/module-base.bbclass |4 +- meta/classes/native.bbclass| 10 -- meta/classes/nativesdk.bbclass |4 ++ meta/classes/siteinfo.bbclass | 14 - meta/classes/toolchain-scripts.bbclass |9 +++-- meta/conf/bitbake.conf | 23 ++ meta/conf/distro/include/tclibc-glibc.inc | 32 meta/conf/distro/include/tcmode-default.inc|5 +++ meta/conf/machine/include/ia32/arch-ia32.inc | 23 -- meta/conf/machine/include/tune-core2.inc |4 ++ meta/conf/machine/include/tune-x86_64.inc |2 +- .../kern-tools/kern-tools-native_git.bb|2 +- 20 files changed, 132 insertions(+), 32 deletions(-) create mode 100644 meta/conf/distro/include/tclibc-glibc.inc -- 1.7.6 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 01/10] kern-tools: extend arbitrary repository support
From: Bruce Ashfield bruce.ashfi...@windriver.com
Updating the kern-tools SRCREV to pickup better support for
non-yocto repository support.
59859ca createme: use branch name when creating meta data
91b4275 configme: determine meta branch based on directories, not branch
naming
f5a915c kgit-meta: make branch creation and renaming more robust
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
.../kern-tools/kern-tools-native_git.bb|2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
index 1fbb1f7..7ede52a 100644
--- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
+++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM =
file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d8
DEPENDS = git-native guilt-native
-SRCREV = f5a915c277a37ba5949b4c0778356189e7dd9ec0
+SRCREV = cdcb97cfea5f98003b2e0fb1a77b6d0d016a69e7
PR = r10
PV = 0.1+git${SRCPV}
--
1.7.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 02/10] linux-yocto: process the existing branch for configuration
From: Bruce Ashfield bruce.ashfi...@windriver.com
When building an external tree or bootstrapping a BSP the
external branch may not have been checked out. The tools now ensure
that the tree is ready for configuration, so we no longer need to
force the checkout of the external branch.
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/classes/kernel-yocto.bbclass |9 +
1 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/meta/classes/kernel-yocto.bbclass
b/meta/classes/kernel-yocto.bbclass
index a374df1..8df5f31 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -87,14 +87,7 @@ do_kernel_configme() {
echo [INFO] doing kernel configme
kbranch=${KBRANCH}
- if [ -n ${YOCTO_KERNEL_EXTERNAL_BRANCH} ]; then
- # switch from a generic to a specific branch
- kbranch=${YOCTO_KERNEL_EXTERNAL_BRANCH}
- cd ${S}
- git checkout ${kbranch}
- else
- cd ${S}
- fi
+ cd ${S}
configme --reconfig --output ${B} ${kbranch} ${MACHINE}
if [ $? -ne 0 ]; then
--
1.7.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 03/10] linux-yocto: pass KMACHINE to updateme, not MACHINE
From: Bruce Ashfield bruce.ashfi...@windriver.com
To support the mapping of any oe/yocto MACHINE to a kernel
branch that may not share that naming structure we have
KMACHINE and KBRANCH. To allow the mapping to work, we
actually have to pass KMACHINE into updateme and not MACHINE.
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/classes/kernel-yocto.bbclass |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/classes/kernel-yocto.bbclass
b/meta/classes/kernel-yocto.bbclass
index 8df5f31..e242165 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -28,7 +28,7 @@ do_patch() {
addon_features=$addon_features --feature $feat
done
fi
- updateme --branch ${kbranch} ${addon_features} ${ARCH} ${MACHINE}
${WORKDIR}
+ updateme --branch ${kbranch} ${addon_features} ${ARCH} ${KMACHINE}
${WORKDIR}
if [ $? -ne 0 ]; then
echo ERROR. Could not update ${kbranch}
exit 1
--
1.7.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 04/10] glibc: bring back the needed support for glibc recipes
From: Nitin A Kamble nitin.a.kam...@intel.com
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
meta/conf/distro/include/tclibc-glibc.inc | 32 +++
meta/conf/distro/include/tcmode-default.inc |5
2 files changed, 37 insertions(+), 0 deletions(-)
create mode 100644 meta/conf/distro/include/tclibc-glibc.inc
diff --git a/meta/conf/distro/include/tclibc-glibc.inc
b/meta/conf/distro/include/tclibc-glibc.inc
new file mode 100644
index 000..823195c
--- /dev/null
+++ b/meta/conf/distro/include/tclibc-glibc.inc
@@ -0,0 +1,32 @@
+#
+# glibc specific configuration
+#
+
+LIBCEXTENSION = ${@['', '-gnu'][(d.getVar('ABIEXTENSION', True) or '') !=
'']}
+
+# Add glibc to the overrides.
+OVERRIDES =. libc-glibc:
+
+PREFERRED_PROVIDER_virtual/libiconv ?= glibc
+PREFERRED_PROVIDER_virtual/libiconv-nativesdk ?= glibc-nativesdk
+PREFERRED_PROVIDER_virtual/libintl ?= glibc
+PREFERRED_PROVIDER_virtual/libc ?= glibc
+PREFERRED_PROVIDER_virtual/libc-nativesdk ?= glibc-nativesdk
+PREFERRED_PROVIDER_virtual/libc-locale ?= glibc-locale
+
+CXXFLAGS += -fvisibility-inlines-hidden
+
+LIBC_DEPENDENCIES = \
+libsegfault \
+glibc \
+glibc-dbg \
+glibc-dev \
+glibc-utils \
+glibc-thread-db \
+glibc-localedata-i18n \
+glibc-gconv-ibm850 \
+glibc-gconv-cp1252 \
+glibc-gconv-iso8859-1 \
+glibc-gconv-iso8859-15 \
+locale-base-en-gb \
+
diff --git a/meta/conf/distro/include/tcmode-default.inc
b/meta/conf/distro/include/tcmode-default.inc
index 0d0af38..5f66c9e 100644
--- a/meta/conf/distro/include/tcmode-default.inc
+++ b/meta/conf/distro/include/tcmode-default.inc
@@ -48,6 +48,11 @@ PREFERRED_VERSION_binutils-crosssdk ?= ${BINUVERSION}
PREFERRED_VERSION_binutils-cross-canadian ?= ${BINUVERSION}
PREFERRED_VERSION_linux-libc-headers ?= ${LINUXLIBCVERSION}
PREFERRED_VERSION_linux-libc-headers-nativesdk ?= ${LINUXLIBCVERSION}
+PREFERRED_VERSION_glibc ?= ${GLIBCVERSION}
+PREFERRED_VERSION_glibc-locale ?= ${GLIBCVERSION}
+PREFERRED_VERSION_glibc-nativesdk ?= ${GLIBCVERSION}
+PREFERRED_VERSION_glibc-initial ?= ${GLIBCVERSION}
+PREFERRED_VERSION_glibc-initial-nativesdk ?= ${GLIBCVERSION}
PREFERRED_VERSION_eglibc ?= ${EGLIBCVERSION}
PREFERRED_VERSION_eglibc-locale?= ${EGLIBCVERSION}
PREFERRED_VERSION_eglibc-nativesdk ?= ${EGLIBCVERSION}
--
1.7.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 06/10] kernel, module-base.bbclass: fix KERNEL_LD KERNEL_AR vars
From: Nitin A Kamble nitin.a.kam...@intel.com
KERNEL_LD was using ${LD} in it's definition, which is not correct for
different ABIs such as x32 or i386 on x86_64 machine.
Same with KERNEL_AR var.
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
meta/classes/kernel.bbclass |2 +-
meta/classes/module-base.bbclass |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index f2f05b1..7dc9cc6 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -47,7 +47,7 @@ TARGET_LD_KERNEL_ARCH ?=
HOST_LD_KERNEL_ARCH ?= ${TARGET_LD_KERNEL_ARCH}
KERNEL_CC = ${CCACHE}${HOST_PREFIX}gcc${KERNEL_CCSUFFIX}
${HOST_CC_KERNEL_ARCH}${TOOLCHAIN_OPTIONS}
-KERNEL_LD = ${LD}${KERNEL_LDSUFFIX}
${HOST_LD_KERNEL_ARCH}${TOOLCHAIN_OPTIONS}
+KERNEL_LD = ${HOST_PREFIX}ld${KERNEL_LDSUFFIX}
${HOST_LD_KERNEL_ARCH}${TOOLCHAIN_OPTIONS}
# Where built kernel lies in the kernel tree
KERNEL_OUTPUT ?= arch/${ARCH}/boot/${KERNEL_IMAGETYPE}
diff --git a/meta/classes/module-base.bbclass b/meta/classes/module-base.bbclass
index 1a39cc1..9379bf8 100644
--- a/meta/classes/module-base.bbclass
+++ b/meta/classes/module-base.bbclass
@@ -21,8 +21,8 @@ TARGET_AR_KERNEL_ARCH ?=
HOST_AR_KERNEL_ARCH ?= ${TARGET_AR_KERNEL_ARCH}
KERNEL_CC = ${CCACHE}${HOST_PREFIX}gcc${KERNEL_CCSUFFIX}
${HOST_CC_KERNEL_ARCH}
-KERNEL_LD = ${LD}${KERNEL_LDSUFFIX} ${HOST_LD_KERNEL_ARCH}
-KERNEL_AR = ${AR}${KERNEL_ARSUFFIX} ${HOST_AR_KERNEL_ARCH}
+KERNEL_LD = ${HOST_PREFIX}ld${KERNEL_LDSUFFIX} ${HOST_LD_KERNEL_ARCH}
+KERNEL_AR = ${HOST_PREFIX}ar${KERNEL_ARSUFFIX} ${HOST_AR_KERNEL_ARCH}
# kernel modules are generally machine specific
PACKAGE_ARCH = ${MACHINE_ARCH}
--
1.7.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 07/10] siteinfo.bbclass: add entries for new x86_64 ABI targets
From: Nitin A Kamble nitin.a.kam...@intel.com
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
meta/classes/siteinfo.bbclass | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/meta/classes/siteinfo.bbclass b/meta/classes/siteinfo.bbclass
index 9dacd58..daa7946 100644
--- a/meta/classes/siteinfo.bbclass
+++ b/meta/classes/siteinfo.bbclass
@@ -42,12 +42,15 @@ def siteinfo_data(d):
sh4: endian-little bit-32 sh-common,
sparc: endian-big bit-32,
viac3: endian-little bit-32 ix86-common,
-x86_64: endian-little bit-64,
+x86_64: endian-little, # bitinfo specified in targetinfo
}
osinfo = {
darwin: common-darwin,
darwin9: common-darwin,
linux: common-linux common-glibc,
+linux-gnu32: common-linux common-glibc,
+linux-gnux32: common-linux common-glibc,
+linux-gnu64: common-linux common-glibc,
linux-gnueabi: common-linux common-glibc,
linux-gnuspe: common-linux common-glibc,
linux-uclibc: common-linux common-uclibc,
@@ -68,6 +71,15 @@ def siteinfo_data(d):
powerpc-linux-uclibcspe: powerpc-linux powerpc32-linux
powerpc-linux-uclibc,
powerpc64-linux-gnuspe: powerpc-linux powerpc64-linux,
powerpc64-linux: powerpc-linux,
+x86_64-cygwin: bit-64,
+x86_64-darvin: bit-64,
+x86_64-darvin9: bit-64,
+x86_64-linux: bit-64,
+x86_64-linux-uclibc: bit-64,
+x86_64-linux-gnu32: bit-32 ix86-common,
+x86_64-linux-gnux32: bit-32 ix86-common,
+x86_64-linux-gnu64: bit-64 x86_64-linux,
+x86_64-mingw32: bit-64,
}
hostarch = d.getVar(HOST_ARCH, True)
--
1.7.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 08/10] insane.bbclass: add entries for linux-gnuABI
From: Nitin A Kamble nitin.a.kam...@intel.com
for x86_64 multiple ABIs now have these new names for the TARGET_OS.
Add entries for:
linux-gnu32, linux-gnux32, linux-gnu64
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
meta/classes/insane.bbclass |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 5fb0d98..15e7fc7 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -90,6 +90,15 @@ def package_qa_get_machine_dict():
microblaze: (47787, 0,0, False,
32),
microblazeel: (47787, 0,0, True,
32),
},
+linux-gnu32 : {
+x86_64: (62, 0,0, True,
32),
+ },
+linux-gnux32 : {
+x86_64: (62, 0,0, True,
32),
+ },
+linux-gnu64 : {
+x86_64: (62, 0,0, True,
64),
+ },
}
--
1.7.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 10/10] local.conf.sample: make BBMASK assignment weak
From: Nitin A Kamble nitin.a.kam...@intel.com So that it can be overridden by layers if needed. Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com --- meta-yocto/conf/local.conf.sample |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/meta-yocto/conf/local.conf.sample b/meta-yocto/conf/local.conf.sample index 3e71b0a..4acec37 100644 --- a/meta-yocto/conf/local.conf.sample +++ b/meta-yocto/conf/local.conf.sample @@ -39,7 +39,7 @@ DISTRO ?= poky # BBMASK is a regular expression that can be used to tell BitBake to ignore # certain recipes. -BBMASK = +BBMASK ?= # EXTRA_IMAGE_FEATURES allows extra packages to be added to the generated images # (Some of these are automatically added to certain image types) -- 1.7.6 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 09/10] x86 tune inc files: add x32 abi tune parameters
From: Nitin A Kamble nitin.a.kam...@intel.com
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
meta/conf/machine/include/ia32/arch-ia32.inc | 23 ---
meta/conf/machine/include/tune-core2.inc |4
meta/conf/machine/include/tune-x86_64.inc|2 +-
3 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/meta/conf/machine/include/ia32/arch-ia32.inc
b/meta/conf/machine/include/ia32/arch-ia32.inc
index 2709440..fb527da 100644
--- a/meta/conf/machine/include/ia32/arch-ia32.inc
+++ b/meta/conf/machine/include/ia32/arch-ia32.inc
@@ -6,17 +6,29 @@ DEFAULTTUNE ?= x86
TARGET_FPU ?=
X86ARCH32 ?= i586
X86ARCH64 ?= x86_64
+X86ARCHX32 ?= x86_64
# ELF32 ABI
TUNEVALID[m32] = IA32 ELF32 standard ABI
-TUNECONFLICTS[m32] = m64
+TUNECONFLICTS[m32] = m64 mx32
TUNE_ARCH .= ${@bb.utils.contains(TUNE_FEATURES, m32, ${X86ARCH32},
,d)}
+ABIEXTENSION .= ${@bb.utils.contains(TUNE_FEATURES, m32, 32, ,d)}
TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, m32, -m32, , d)}
+# x32 ABI
+TUNEVALID[mx32] = IA32e (x86_64) ELF32 standard ABI
+TUNECONFLICTS[mx32] = m64 m32
+TUNE_ARCH .= ${@bb.utils.contains(TUNE_FEATURES, mx32, ${X86ARCHX32},
,d)}
+ABIEXTENSION .= ${@bb.utils.contains(TUNE_FEATURES, mx32, x32, ,d)}
+TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, mx32, -mx32, , d)}
+TUNE_LDARGS += ${@bb.utils.contains(TUNE_FEATURES, mx32, -m
elf32_x86_64, , d)}
+TUNE_ASARGS += ${@bb.utils.contains(TUNE_FEATURES, mx32, -x32, , d)}
+
# ELF64 ABI
TUNEVALID[m64] = IA32e (x86_64) ELF64 standard ABI
-TUNECONFLICT[m64] = m32
+TUNECONFLICT[m64] = m32 mx32
TUNE_ARCH .= ${@bb.utils.contains(TUNE_FEATURES, m64, ${X86ARCH64},
,d)}
+ABIEXTENSION .= ${@bb.utils.contains(TUNE_FEATURES, m64, 64, ,d)}
TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, m64, -m64, , d)}
TUNE_PKGARCH ?= ${@bb.utils.contains(TUNE_FEATURES, m32, x86, x86_64,
d)}
@@ -30,4 +42,9 @@ PACKAGE_EXTRA_ARCHS_tune-x86 = x86
AVAILTUNES += x86-64
TUNE_FEATURES_tune-x86-64 ?= m64
BASE_LIB_tune-x86-64 ?= lib64
-PACKAGE_EXTRA_ARCHS_tune-x86-64 = x86_64
+PACKAGE_EXTRA_ARCHS_tune-x86-64 = x86-64
+
+AVAILTUNES += x86-64-x32
+TUNE_FEATURES_tune-x86-64-x32 ?= mx32
+BASE_LIB_tune-x86-64-x32 ?= lib
+PACKAGE_EXTRA_ARCHS_tune-x86-64-x32 = x86-64-x32
diff --git a/meta/conf/machine/include/tune-core2.inc
b/meta/conf/machine/include/tune-core2.inc
index 25c2226..8a4de3e 100644
--- a/meta/conf/machine/include/tune-core2.inc
+++ b/meta/conf/machine/include/tune-core2.inc
@@ -18,3 +18,7 @@ TUNE_FEATURES_tune-core2-64 ?= ${TUNE_FEATURES_tune-x86-64}
core2
BASE_LIB_tune-core2-64 ?= lib64
PACKAGE_EXTRA_ARCHS_tune-core2-64 = ${PACKAGE_EXTRA_ARCHS_tune-x86-64}
core2-64
+AVAILTUNES += core2-x32
+TUNE_FEATURES_tune-core2-x32 ?= ${TUNE_FEATURES_tune-x86-64-x32} core2
+BASE_LIB_tune-core2-x32 ?= lib
+PACKAGE_EXTRA_ARCHS_tune-core2-x32 = ${PACKAGE_EXTRA_ARCHS_tune-x86-64-x32}
core2-x32
diff --git a/meta/conf/machine/include/tune-x86_64.inc
b/meta/conf/machine/include/tune-x86_64.inc
index 04b0f96..50f20ba 100644
--- a/meta/conf/machine/include/tune-x86_64.inc
+++ b/meta/conf/machine/include/tune-x86_64.inc
@@ -1,3 +1,3 @@
require conf/machine/include/ia32/arch-ia32.inc
-DEFAULTTUNE = x86-64
+DEFAULTTUNE ?= x86-64
--
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] [PATCH 06/10] kernel, module-base.bbclass: fix KERNEL_LD KERNEL_AR vars
On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kam...@intel.com wrote:
From: Nitin A Kamble nitin.a.kam...@intel.com
KERNEL_LD was using ${LD} in it's definition, which is not correct for
different ABIs such as x32 or i386 on x86_64 machine.
Same with KERNEL_AR var.
Why is ar an issue? That doesn't have any unusual args, does it?
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 04/10] glibc: bring back the needed support for glibc recipes
On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com This commit message is very terse. Why is this change necessary? p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 09/10] x86 tune inc files: add x32 abi tune parameters
On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kam...@intel.com wrote:
# ELF32 ABI
TUNEVALID[m32] = IA32 ELF32 standard ABI
-TUNECONFLICTS[m32] = m64
+TUNECONFLICTS[m32] = m64 mx32
TUNE_ARCH .= ${@bb.utils.contains(TUNE_FEATURES, m32, ${X86ARCH32},
,d)}
+ABIEXTENSION .= ${@bb.utils.contains(TUNE_FEATURES, m32, 32, ,d)}
TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, m32, -m32, , d)}
This is going to cause TARGET_OS to change for everyone using the i586
ABI, right? That doesn't seem like it is either necessary or desirable,
and it isn't mentioned in the checkin comment either.
# ELF64 ABI
TUNEVALID[m64] = IA32e (x86_64) ELF64 standard ABI
-TUNECONFLICT[m64] = m32
+TUNECONFLICT[m64] = m32 mx32
TUNE_ARCH .= ${@bb.utils.contains(TUNE_FEATURES, m64, ${X86ARCH64},
,d)}
+ABIEXTENSION .= ${@bb.utils.contains(TUNE_FEATURES, m64, 64, ,d)}
TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, m64, -m64, , d)}
... and likewise this for anybody using the x86-64 ABI.
-PACKAGE_EXTRA_ARCHS_tune-x86-64 = x86_64
+PACKAGE_EXTRA_ARCHS_tune-x86-64 = x86-64
That change might well be fine, but again it isn't mentioned in the
checkin message.
diff --git a/meta/conf/machine/include/tune-x86_64.inc
b/meta/conf/machine/include/tune-x86_64.inc
index 04b0f96..50f20ba 100644
--- a/meta/conf/machine/include/tune-x86_64.inc
+++ b/meta/conf/machine/include/tune-x86_64.inc
@@ -1,3 +1,3 @@
require conf/machine/include/ia32/arch-ia32.inc
-DEFAULTTUNE = x86-64
+DEFAULTTUNE ?= x86-64
This one is also not mentioned in the checkin message and looks a bit
more dubious to me. Why is this required?
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libc-package bbclass: fix binary localedata dependency code
On Wed, 2011-08-03 at 08:19 +0200, Koen Kooi wrote:
Op 2 aug. 2011, om 17:01 heeft Phil Blundell het volgende geschreven:
It does look a bit weird. That code was introduced in 561d8754,
ostensibly as a merger of the eglibc and glibc equivalents. But, the
original code from glibc-package.bbclass did:
def output_locale_binary_rdepends(name, pkgname, locale, encoding):
m = re.match((.*)\.(.*), name)
if m:
glibc_name = %s.%s % (m.group(1),
m.group(2).lower().replace(-,))
else:
glibc_name = name
bb.data.setVar('RDEPENDS_%s' % pkgname,
legitimize_package_name('glibc-binary-localedata-%s' % glibc_name), d)
... i.e. it was using the . separator both for splitting and joining,
which seems reasonable. But somehow when it showed up in
libc-package.bbclass it had gotten transmogrified so that it split on
_ but joined with . as you showed below. That seems bogus to me.
I'm not sure whether your original locale problem is still an issue, but
I am still fairly convinced that the change to the regex in the code
above was incorrect. Unless the author of 561d8754 wants to speak up in
its defence soon, I will submit a patch to change it back to using ..
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 06/10] kernel, module-base.bbclass: fix KERNEL_LD KERNEL_AR vars
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
Phil Blundell
Sent: Thursday, August 04, 2011 2:50 PM
To: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [PATCH 06/10] kernel, module-base.bbclass: fix
KERNEL_LD KERNEL_AR vars
On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kam...@intel.com wrote:
From: Nitin A Kamble nitin.a.kam...@intel.com
KERNEL_LD was using ${LD} in it's definition, which is not correct
for
different ABIs such as x32 or i386 on x86_64 machine.
Same with KERNEL_AR var.
Why is ar an issue? That doesn't have any unusual args, does it?
p.
No special args for ar, but The change makes definition of KERNEL_AR consistent
with other definitions like KERNEL_CC KERNEL_LD.
Nitin
___
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 04/10] glibc: bring back the needed support for glibc recipes
-Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Phil Blundell Sent: Thursday, August 04, 2011 2:51 PM To: Patches and discussions about the oe-core layer Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed support for glibc recipes On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com This commit message is very terse. Why is this change necessary? Because meta-x32 layer has glibc, which needs these support files. I will update the commit message in the tree. Thanks, Nitin p. ___ 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 09/10] x86 tune inc files: add x32 abi tune parameters
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
Phil Blundell
Sent: Thursday, August 04, 2011 2:57 PM
To: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [PATCH 09/10] x86 tune inc files: add x32 abi
tune parameters
On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kam...@intel.com wrote:
# ELF32 ABI
TUNEVALID[m32] = IA32 ELF32 standard ABI
-TUNECONFLICTS[m32] = m64
+TUNECONFLICTS[m32] = m64 mx32
TUNE_ARCH .= ${@bb.utils.contains(TUNE_FEATURES, m32,
${X86ARCH32}, ,d)}
+ABIEXTENSION .= ${@bb.utils.contains(TUNE_FEATURES, m32, 32,
,d)}
TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, m32, -m32,
, d)}
This is going to cause TARGET_OS to change for everyone using the i586
ABI, right? That doesn't seem like it is either necessary or
desirable,
and it isn't mentioned in the checkin comment either.
Correct, this will change the TARGET_OS from linux_gnu to linux_gnu32. And it
is also applicable for x86-64 machine set with x86 tune. This change is be
needed if multiple tunes are built from the same build directory. If such
situation is not important then the ABIEXTENSION part can be dropped.
# ELF64 ABI
TUNEVALID[m64] = IA32e (x86_64) ELF64 standard ABI
-TUNECONFLICT[m64] = m32
+TUNECONFLICT[m64] = m32 mx32
TUNE_ARCH .= ${@bb.utils.contains(TUNE_FEATURES, m64,
${X86ARCH64}, ,d)}
+ABIEXTENSION .= ${@bb.utils.contains(TUNE_FEATURES, m64, 64,
,d)}
TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, m64, -m64,
, d)}
... and likewise this for anybody using the x86-64 ABI.
This is similar to above.
-PACKAGE_EXTRA_ARCHS_tune-x86-64 = x86_64
+PACKAGE_EXTRA_ARCHS_tune-x86-64 = x86-64
That change might well be fine, but again it isn't mentioned in the
checkin message.
This is making this consistent with other PACKAGE_EXTRA_ARCHS_tune convention
elsewhere. I will update the commit message for this.
diff --git a/meta/conf/machine/include/tune-x86_64.inc
b/meta/conf/machine/include/tune-x86_64.inc
index 04b0f96..50f20ba 100644
--- a/meta/conf/machine/include/tune-x86_64.inc
+++ b/meta/conf/machine/include/tune-x86_64.inc
@@ -1,3 +1,3 @@
require conf/machine/include/ia32/arch-ia32.inc
-DEFAULTTUNE = x86-64
+DEFAULTTUNE ?= x86-64
This one is also not mentioned in the checkin message and looks a bit
more dubious to me. Why is this required?
It was required at one point when multilist support was quiet unstable. The
reason it is done because the arch-ia32.inc file is included for both x86,
tune-core, x86-64 and setting this hard assignment, was breaking x86 or x32
targets. Not sure if it is still needed, I will check it.
p.
___
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 09/10] x86 tune inc files: add x32 abi tune parameters
On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kam...@intel.com wrote:
# ELF32 ABI
TUNEVALID[m32] = IA32 ELF32 standard ABI
-TUNECONFLICTS[m32] = m64
+TUNECONFLICTS[m32] = m64 mx32
TUNE_ARCH .= ${@bb.utils.contains(TUNE_FEATURES, m32,
${X86ARCH32}, ,d)}
+ABIEXTENSION .= ${@bb.utils.contains(TUNE_FEATURES, m32,
32,
,d)}
TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, m32, -
m32,
, d)}
This is going to cause TARGET_OS to change for everyone using the
i586
ABI, right? That doesn't seem like it is either necessary or
desirable,
and it isn't mentioned in the checkin comment either.
Correct, this will change the TARGET_OS from linux_gnu to linux_gnu32.
And it is also applicable for x86-64 machine set with x86 tune. This
change is be needed if multiple tunes are built from the same build
directory. If such situation is not important then the ABIEXTENSION
part can be dropped.
# ELF64 ABI
TUNEVALID[m64] = IA32e (x86_64) ELF64 standard ABI
-TUNECONFLICT[m64] = m32
+TUNECONFLICT[m64] = m32 mx32
TUNE_ARCH .= ${@bb.utils.contains(TUNE_FEATURES, m64,
${X86ARCH64}, ,d)}
+ABIEXTENSION .= ${@bb.utils.contains(TUNE_FEATURES, m64,
64,
,d)}
TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, m64, -
m64,
, d)}
... and likewise this for anybody using the x86-64 ABI.
This is similar to above.
-PACKAGE_EXTRA_ARCHS_tune-x86-64 = x86_64
+PACKAGE_EXTRA_ARCHS_tune-x86-64 = x86-64
That change might well be fine, but again it isn't mentioned in the
checkin message.
This is making this consistent with other PACKAGE_EXTRA_ARCHS_tune
convention elsewhere. I will update the commit message for this.
diff --git a/meta/conf/machine/include/tune-x86_64.inc
b/meta/conf/machine/include/tune-x86_64.inc
index 04b0f96..50f20ba 100644
--- a/meta/conf/machine/include/tune-x86_64.inc
+++ b/meta/conf/machine/include/tune-x86_64.inc
@@ -1,3 +1,3 @@
require conf/machine/include/ia32/arch-ia32.inc
-DEFAULTTUNE = x86-64
+DEFAULTTUNE ?= x86-64
This one is also not mentioned in the checkin message and looks a bit
more dubious to me. Why is this required?
It was required at one point when multilist support was quiet unstable.
The reason it is done because the arch-ia32.inc file is included for
both x86, tune-core, x86-64 and setting this hard assignment, was
breaking x86 or x32 targets. Not sure if it is still needed, I will
check it.
Just checked, this is needed, when qemux86-64 machine is configured with x32
abi, when a different default tune is used.
Nitin
p.
___
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] libc-package bbclass: fix binary localedata dependency code
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
Phil Blundell
Sent: Thursday, August 04, 2011 3:00 PM
To: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [PATCH] libc-package bbclass: fix binary
localedata dependency code
On Wed, 2011-08-03 at 08:19 +0200, Koen Kooi wrote:
Op 2 aug. 2011, om 17:01 heeft Phil Blundell het volgende geschreven:
It does look a bit weird. That code was introduced in 561d8754,
ostensibly as a merger of the eglibc and glibc equivalents. But,
the
original code from glibc-package.bbclass did:
def output_locale_binary_rdepends(name, pkgname, locale,
encoding):
m = re.match((.*)\.(.*), name)
if m:
glibc_name = %s.%s % (m.group(1),
m.group(2).lower().replace(-,))
else:
glibc_name = name
bb.data.setVar('RDEPENDS_%s' % pkgname,
legitimize_package_name('glibc-binary-localedata-%s' % glibc_name), d)
... i.e. it was using the . separator both for splitting and
joining,
which seems reasonable. But somehow when it showed up in
libc-package.bbclass it had gotten transmogrified so that it split
on
_ but joined with . as you showed below. That seems bogus to
me.
I'm not sure whether your original locale problem is still an issue,
but
I am still fairly convinced that the change to the regex in the code
above was incorrect. Unless the author of 561d8754 wants to speak up
in
its defence soon, I will submit a patch to change it back to using ..
p.
Phil,
Feel free to do the right thing. :) I am out of context here, and need to
dig this further to understand the situation better.
Nitin
___
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 04/10] glibc: bring back the needed support for glibc recipes
-Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Phil Blundell Sent: Thursday, August 04, 2011 3:10 PM To: Patches and discussions about the oe-core layer Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed support for glibc recipes On Thu, 2011-08-04 at 15:04 -0700, Kamble, Nitin A wrote: -Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Phil Blundell Sent: Thursday, August 04, 2011 2:51 PM To: Patches and discussions about the oe-core layer Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed support for glibc recipes On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com This commit message is very terse. Why is this change necessary? Because meta-x32 layer has glibc, which needs these support files. I will update the commit message in the tree. Can't the tclibc-glibc file go in meta-x32 as well, then? It can go in the meta-x32 layer, but I think better place for this support file is in the meta layer. It would help avoid duplication of the code in multiple layers. p. ___ 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 04/10] glibc: bring back the needed support for glibc recipes
On Thu, Aug 4, 2011 at 3:04 PM, Kamble, Nitin A nitin.a.kam...@intel.com wrote: -Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Phil Blundell Sent: Thursday, August 04, 2011 2:51 PM To: Patches and discussions about the oe-core layer Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed support for glibc recipes On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com This commit message is very terse. Why is this change necessary? Because meta-x32 layer has glibc, which needs these support files. I will update the commit message in the tree. Can x32 not use eglibc? -- Tom ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 07/10] siteinfo.bbclass: add entries for new x86_64 ABI targets
On Thu, Aug 4, 2011 at 8:01 AM, nitin.a.kam...@intel.com wrote:
From: Nitin A Kamble nitin.a.kam...@intel.com
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
meta/classes/siteinfo.bbclass | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/meta/classes/siteinfo.bbclass b/meta/classes/siteinfo.bbclass
index 9dacd58..daa7946 100644
--- a/meta/classes/siteinfo.bbclass
+++ b/meta/classes/siteinfo.bbclass
@@ -42,12 +42,15 @@ def siteinfo_data(d):
sh4: endian-little bit-32 sh-common,
sparc: endian-big bit-32,
viac3: endian-little bit-32 ix86-common,
- x86_64: endian-little bit-64,
+ x86_64: endian-little, # bitinfo specified in targetinfo
}
osinfo = {
darwin: common-darwin,
darwin9: common-darwin,
linux: common-linux common-glibc,
+ linux-gnu32: common-linux common-glibc,
+ linux-gnux32: common-linux common-glibc,
+ linux-gnu64: common-linux common-glibc,
linux-gnueabi: common-linux common-glibc,
linux-gnuspe: common-linux common-glibc,
linux-uclibc: common-linux common-uclibc,
@@ -68,6 +71,15 @@ def siteinfo_data(d):
powerpc-linux-uclibcspe: powerpc-linux powerpc32-linux
powerpc-linux-uclibc,
powerpc64-linux-gnuspe: powerpc-linux powerpc64-linux,
powerpc64-linux: powerpc-linux,
+ x86_64-cygwin: bit-64,
+ x86_64-darvin: bit-64,
+ x86_64-darvin9: bit-64,
You still haven't fixed this typo. It's darWin not darVin.
--
Tom
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 10/10] local.conf.sample: make BBMASK assignment weak
On Thu, Aug 4, 2011 at 8:01 AM, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com So that it can be overridden by layers if needed. Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com --- meta-yocto/conf/local.conf.sample | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/meta-yocto/conf/local.conf.sample b/meta-yocto/conf/local.conf.sample index 3e71b0a..4acec37 100644 --- a/meta-yocto/conf/local.conf.sample +++ b/meta-yocto/conf/local.conf.sample @@ -39,7 +39,7 @@ DISTRO ?= poky # BBMASK is a regular expression that can be used to tell BitBake to ignore # certain recipes. -BBMASK = +BBMASK ?= # EXTRA_IMAGE_FEATURES allows extra packages to be added to the generated images # (Some of these are automatically added to certain image types) In oe.dev we just dropped this from local.conf iirc since a real assignmnet was overriding a useful setting we provided. IMHO, we should do the same here (or at least comment it out). -- Tom ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 07/10] siteinfo.bbclass: add entries for new x86_64 ABI targets
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
Tom Rini
Sent: Thursday, August 04, 2011 3:52 PM
To: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [PATCH 07/10] siteinfo.bbclass: add entries for
new x86_64 ABI targets
On Thu, Aug 4, 2011 at 8:01 AM, nitin.a.kam...@intel.com wrote:
From: Nitin A Kamble nitin.a.kam...@intel.com
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
meta/classes/siteinfo.bbclass | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/meta/classes/siteinfo.bbclass
b/meta/classes/siteinfo.bbclass
index 9dacd58..daa7946 100644
--- a/meta/classes/siteinfo.bbclass
+++ b/meta/classes/siteinfo.bbclass
@@ -42,12 +42,15 @@ def siteinfo_data(d):
sh4: endian-little bit-32 sh-common,
sparc: endian-big bit-32,
viac3: endian-little bit-32 ix86-common,
- x86_64: endian-little bit-64,
+ x86_64: endian-little, # bitinfo specified in targetinfo
}
osinfo = {
darwin: common-darwin,
darwin9: common-darwin,
linux: common-linux common-glibc,
+ linux-gnu32: common-linux common-glibc,
+ linux-gnux32: common-linux common-glibc,
+ linux-gnu64: common-linux common-glibc,
linux-gnueabi: common-linux common-glibc,
linux-gnuspe: common-linux common-glibc,
linux-uclibc: common-linux common-uclibc,
@@ -68,6 +71,15 @@ def siteinfo_data(d):
powerpc-linux-uclibcspe: powerpc-linux powerpc32-linux
powerpc-linux-uclibc,
powerpc64-linux-gnuspe: powerpc-linux powerpc64-linux,
powerpc64-linux: powerpc-linux,
+ x86_64-cygwin: bit-64,
+ x86_64-darvin: bit-64,
+ x86_64-darvin9: bit-64,
You still haven't fixed this typo. It's darWin not darVin.
Got it. Thanks for catching this again :)
Nitin
--
Tom
___
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 10/10] local.conf.sample: make BBMASK assignment weak
-Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Tom Rini Sent: Thursday, August 04, 2011 3:53 PM To: Patches and discussions about the oe-core layer Subject: Re: [OE-core] [PATCH 10/10] local.conf.sample: make BBMASK assignment weak On Thu, Aug 4, 2011 at 8:01 AM, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com So that it can be overridden by layers if needed. Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com --- meta-yocto/conf/local.conf.sample | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/meta-yocto/conf/local.conf.sample b/meta- yocto/conf/local.conf.sample index 3e71b0a..4acec37 100644 --- a/meta-yocto/conf/local.conf.sample +++ b/meta-yocto/conf/local.conf.sample @@ -39,7 +39,7 @@ DISTRO ?= poky # BBMASK is a regular expression that can be used to tell BitBake to ignore # certain recipes. -BBMASK = +BBMASK ?= # EXTRA_IMAGE_FEATURES allows extra packages to be added to the generated images # (Some of these are automatically added to certain image types) In oe.dev we just dropped this from local.conf iirc since a real assignmnet was overriding a useful setting we provided. IMHO, we should do the same here (or at least comment it out). I agree. We should comment it out. -- Tom ___ 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 04/10] glibc: bring back the needed support for glibc recipes
-Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Tom Rini Sent: Thursday, August 04, 2011 3:50 PM To: Patches and discussions about the oe-core layer Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed support for glibc recipes On Thu, Aug 4, 2011 at 3:47 PM, Kamble, Nitin A nitin.a.kam...@intel.com wrote: -Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Phil Blundell Sent: Thursday, August 04, 2011 3:10 PM To: Patches and discussions about the oe-core layer Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed support for glibc recipes On Thu, 2011-08-04 at 15:04 -0700, Kamble, Nitin A wrote: -Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Phil Blundell Sent: Thursday, August 04, 2011 2:51 PM To: Patches and discussions about the oe-core layer Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed support for glibc recipes On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com This commit message is very terse. Why is this change necessary? Because meta-x32 layer has glibc, which needs these support files. I will update the commit message in the tree. Can't the tclibc-glibc file go in meta-x32 as well, then? It can go in the meta-x32 layer, but I think better place for this support file is in the meta layer. It would help avoid duplication of the code in multiple layers. Part of the answer here is that obsolete / etc things don't belong in the core, but in other layers that need them. My read on things is that we've removed glibc in favor of eglibc... With high demand I will move the glibc file in the meta-x32 layer. I was trying to do what felt right at 1st, but I wasn't aware that eglibc is favored so much over glibc. -- Tom ___ 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 04/10] glibc: bring back the needed support for glibc recipes
-Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Tom Rini Sent: Thursday, August 04, 2011 3:49 PM To: Patches and discussions about the oe-core layer Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed support for glibc recipes On Thu, Aug 4, 2011 at 3:04 PM, Kamble, Nitin A nitin.a.kam...@intel.com wrote: -Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Phil Blundell Sent: Thursday, August 04, 2011 2:51 PM To: Patches and discussions about the oe-core layer Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed support for glibc recipes On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com This commit message is very terse. Why is this change necessary? Because meta-x32 layer has glibc, which needs these support files. I will update the commit message in the tree. Can x32 not use eglibc? Not yet, x32 work is done on the glibc tip, and eglibc is not there to pick up the work. Nitin -- Tom ___ 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 04/10] glibc: bring back the needed support for glibc recipes
On 08/04/2011 08:01 AM, nitin.a.kam...@intel.com wrote:
From: Nitin A Kamblenitin.a.kam...@intel.com
Signed-off-by: Nitin A Kamblenitin.a.kam...@intel.com
---
meta/conf/distro/include/tclibc-glibc.inc | 32 +++
meta/conf/distro/include/tcmode-default.inc |5
2 files changed, 37 insertions(+), 0 deletions(-)
create mode 100644 meta/conf/distro/include/tclibc-glibc.inc
diff --git a/meta/conf/distro/include/tclibc-glibc.inc
b/meta/conf/distro/include/tclibc-glibc.inc
new file mode 100644
index 000..823195c
--- /dev/null
+++ b/meta/conf/distro/include/tclibc-glibc.inc
@@ -0,0 +1,32 @@
+#
+# glibc specific configuration
+#
+
+LIBCEXTENSION = ${@['', '-gnu'][(d.getVar('ABIEXTENSION', True) or '') !=
'']}
why is this specific to glibc and not eglibc ?
since glibc is deleted from metadata this file should go away too
if its for external toolchains then they could use tclibc-eglibc.inc
or tclibc-uclibc.inc as needed.
I am in favour of generally using linux-gnu extention for eglibc/glibc
based systems.
+
+# Add glibc to the overrides.
+OVERRIDES =. libc-glibc:
+
+PREFERRED_PROVIDER_virtual/libiconv ?= glibc
+PREFERRED_PROVIDER_virtual/libiconv-nativesdk ?= glibc-nativesdk
+PREFERRED_PROVIDER_virtual/libintl ?= glibc
+PREFERRED_PROVIDER_virtual/libc ?= glibc
+PREFERRED_PROVIDER_virtual/libc-nativesdk ?= glibc-nativesdk
+PREFERRED_PROVIDER_virtual/libc-locale ?= glibc-locale
+
+CXXFLAGS += -fvisibility-inlines-hidden
+
+LIBC_DEPENDENCIES = \
+libsegfault \
+glibc \
+glibc-dbg \
+glibc-dev \
+glibc-utils \
+glibc-thread-db \
+glibc-localedata-i18n \
+glibc-gconv-ibm850 \
+glibc-gconv-cp1252 \
+glibc-gconv-iso8859-1 \
+glibc-gconv-iso8859-15 \
+locale-base-en-gb \
+
diff --git a/meta/conf/distro/include/tcmode-default.inc
b/meta/conf/distro/include/tcmode-default.inc
index 0d0af38..5f66c9e 100644
--- a/meta/conf/distro/include/tcmode-default.inc
+++ b/meta/conf/distro/include/tcmode-default.inc
@@ -48,6 +48,11 @@ PREFERRED_VERSION_binutils-crosssdk ?= ${BINUVERSION}
PREFERRED_VERSION_binutils-cross-canadian ?= ${BINUVERSION}
PREFERRED_VERSION_linux-libc-headers ?= ${LINUXLIBCVERSION}
PREFERRED_VERSION_linux-libc-headers-nativesdk ?= ${LINUXLIBCVERSION}
+PREFERRED_VERSION_glibc ?= ${GLIBCVERSION}
+PREFERRED_VERSION_glibc-locale ?= ${GLIBCVERSION}
+PREFERRED_VERSION_glibc-nativesdk ?= ${GLIBCVERSION}
+PREFERRED_VERSION_glibc-initial ?= ${GLIBCVERSION}
+PREFERRED_VERSION_glibc-initial-nativesdk ?= ${GLIBCVERSION}
PREFERRED_VERSION_eglibc ?= ${EGLIBCVERSION}
PREFERRED_VERSION_eglibc-locale?= ${EGLIBCVERSION}
PREFERRED_VERSION_eglibc-nativesdk ?= ${EGLIBCVERSION}
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 04/10] glibc: bring back the needed support for glibc recipes
On 08/04/2011 03:58 PM, Kamble, Nitin A wrote: -Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Tom Rini Sent: Thursday, August 04, 2011 3:49 PM To: Patches and discussions about the oe-core layer Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed support for glibc recipes On Thu, Aug 4, 2011 at 3:04 PM, Kamble, Nitin A nitin.a.kam...@intel.com wrote: -Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Phil Blundell Sent: Thursday, August 04, 2011 2:51 PM To: Patches and discussions about the oe-core layer Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed support for glibc recipes On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kam...@intel.com wrote: From: Nitin A Kamblenitin.a.kam...@intel.com Signed-off-by: Nitin A Kamblenitin.a.kam...@intel.com This commit message is very terse. Why is this change necessary? Because meta-x32 layer has glibc, which needs these support files. I will update the commit message in the tree. Can x32 not use eglibc? Not yet, x32 work is done on the glibc tip, and eglibc is not there to pick up the work. glibc tip is pulled into eglibc svn trunk very frequently. So an eglibc_svn.bb recipe can get you what you want. Nitin -- Tom ___ 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 04/10] glibc: bring back the needed support for glibc recipes
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
Khem Raj
Sent: Thursday, August 04, 2011 4:19 PM
To: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed
support for glibc recipes
On 08/04/2011 08:01 AM, nitin.a.kam...@intel.com wrote:
From: Nitin A Kamblenitin.a.kam...@intel.com
Signed-off-by: Nitin A Kamblenitin.a.kam...@intel.com
---
meta/conf/distro/include/tclibc-glibc.inc | 32
+++
meta/conf/distro/include/tcmode-default.inc |5
2 files changed, 37 insertions(+), 0 deletions(-)
create mode 100644 meta/conf/distro/include/tclibc-glibc.inc
diff --git a/meta/conf/distro/include/tclibc-glibc.inc
b/meta/conf/distro/include/tclibc-glibc.inc
new file mode 100644
index 000..823195c
--- /dev/null
+++ b/meta/conf/distro/include/tclibc-glibc.inc
@@ -0,0 +1,32 @@
+#
+# glibc specific configuration
+#
+
+LIBCEXTENSION = ${@['', '-gnu'][(d.getVar('ABIEXTENSION', True) or
'') != '']}
why is this specific to glibc and not eglibc ?
I think that is for multilib. I did not do any changes to the tclibc-glibc.inc
files. I just got back the last version before deletion.
since glibc is deleted from metadata this file should go away too
if its for external toolchains then they could use tclibc-eglibc.inc
or tclibc-uclibc.inc as needed.
I am in favour of generally using linux-gnu extention for eglibc/glibc
based systems.
+
+# Add glibc to the overrides.
+OVERRIDES =. libc-glibc:
+
+PREFERRED_PROVIDER_virtual/libiconv ?= glibc
+PREFERRED_PROVIDER_virtual/libiconv-nativesdk ?= glibc-nativesdk
+PREFERRED_PROVIDER_virtual/libintl ?= glibc
+PREFERRED_PROVIDER_virtual/libc ?= glibc
+PREFERRED_PROVIDER_virtual/libc-nativesdk ?= glibc-nativesdk
+PREFERRED_PROVIDER_virtual/libc-locale ?= glibc-locale
+
+CXXFLAGS += -fvisibility-inlines-hidden
+
+LIBC_DEPENDENCIES = \
+libsegfault \
+glibc \
+glibc-dbg \
+glibc-dev \
+glibc-utils \
+glibc-thread-db \
+glibc-localedata-i18n \
+glibc-gconv-ibm850 \
+glibc-gconv-cp1252 \
+glibc-gconv-iso8859-1 \
+glibc-gconv-iso8859-15 \
+locale-base-en-gb \
+
diff --git a/meta/conf/distro/include/tcmode-default.inc
b/meta/conf/distro/include/tcmode-default.inc
index 0d0af38..5f66c9e 100644
--- a/meta/conf/distro/include/tcmode-default.inc
+++ b/meta/conf/distro/include/tcmode-default.inc
@@ -48,6 +48,11 @@ PREFERRED_VERSION_binutils-crosssdk ?=
${BINUVERSION}
PREFERRED_VERSION_binutils-cross-canadian ?= ${BINUVERSION}
PREFERRED_VERSION_linux-libc-headers ?= ${LINUXLIBCVERSION}
PREFERRED_VERSION_linux-libc-headers-nativesdk ?=
${LINUXLIBCVERSION}
+PREFERRED_VERSION_glibc ?= ${GLIBCVERSION}
+PREFERRED_VERSION_glibc-locale ?= ${GLIBCVERSION}
+PREFERRED_VERSION_glibc-nativesdk ?= ${GLIBCVERSION}
+PREFERRED_VERSION_glibc-initial ?= ${GLIBCVERSION}
+PREFERRED_VERSION_glibc-initial-nativesdk ?= ${GLIBCVERSION}
PREFERRED_VERSION_eglibc ?= ${EGLIBCVERSION}
PREFERRED_VERSION_eglibc-locale?= ${EGLIBCVERSION}
PREFERRED_VERSION_eglibc-nativesdk ?= ${EGLIBCVERSION}
___
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 1/1] apr-util: disable pqsql support to avoid configure error
The pqsql config script will check host path and add host paths to compiler and
linker options:
adding -I/usr/include/postgresql to CPPFLAGS
adding -L/usr/lib to LDFLAGS
Disable pqsql support since we didn't use this feature in other recipes.
Signed-off-by: Mei Lei lei@intel.com
---
meta/recipes-support/apr/apr-util_1.3.12.bb |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-support/apr/apr-util_1.3.12.bb
b/meta/recipes-support/apr/apr-util_1.3.12.bb
index 6635202..800e67e 100644
--- a/meta/recipes-support/apr/apr-util_1.3.12.bb
+++ b/meta/recipes-support/apr/apr-util_1.3.12.bb
@@ -7,7 +7,7 @@ LICENSE = Apache-2.0
LIC_FILES_CHKSUM = file://LICENSE;md5=519e0a18e03f7c023070568c14b077bb \
file://include/apu_version.h;endline=17;md5=806685a84e71f10c80144c48eb35df42
-PR = r0
+PR = r1
SRC_URI = ${APACHE_MIRROR}/apr/${BPN}-${PV}.tar.gz \
file://configfix.patch \
@@ -18,6 +18,7 @@ SRC_URI[sha256sum] =
815b6fc82950f61050a5e711a7f3c20fd9b6ffcc7a4cacfe9f291fb241
EXTRA_OECONF = --with-apr=${STAGING_BINDIR_CROSS}/apr-1-config \
--without-odbc \
+ --without-pgsql \
--with-dbm=gdbm \
--with-gdbm=${STAGING_DIR_HOST}${prefix} \
--without-sqlite2 \
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1]apr-util: disable pqsql support to avoid configure error
The pqsql config script will check host path and add host paths to compiler and linker options: adding -I/usr/include/postgresql to CPPFLAGS adding -L/usr/lib to LDFLAGS Disable pqsql support since we didn't use this feature in other recipes. Thanks, Lei The following changes since commit 8a731122e7811275f20065ba27645b97fadf362d: Richard Purdie (1): eglibc: Fix patch merge breakage are available in the git repository at: git://git.pokylinux.org/poky-contrib lmei3/apr-util http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=lmei3/apr-util Mei Lei (1): apr-util: disable pqsql support to avoid configure error meta/recipes-support/apr/apr-util_1.3.12.bb |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core] gstreamer-ti, questions
On Thu, Aug 4, 2011 at 8:04 PM, Joel A Fernandes agnel.j...@gmail.com wrote: On Thu, Aug 4, 2011 at 2:44 AM, Koen Kooi k...@dominion.thruhere.net wrote: Op 3 aug. 2011, om 18:28 heeft Enrico Butera het volgende geschreven: I've started importing bb files from oe classic into meta-texasinstruments, i still not have a clean build of everything but here are some basic questions: - cross compiler binaries: in classic oe there were sysroots/i686-linux/usr/armv7a/bin/arm-angstrom-linux-gnueabi-[gcc,ld...] and sysroots/i686-linux/usr/armv7a/arm-angstrom-linux-gnueabi/bin/[gcc,ld...], some ti tools use one, some the other. Now there is only usr/bin/armv7a. and this confuses some ti tools. The question is: what is the proper way to handle this? patch gcc install to have a similar layout to classic oe? patch ti tools to fix them? Joel was running into similar problems with https://github.com/joelagnel/meta-texasinstruments/commits/master can you guys have a look at it together? I think its cleaner to have the toolchain to define symlinks in /bin I've done this in the gcc-cross recipe in do_install (which is hopefully the right place to do it) http://www.hackerbliss.org/joel/cgit/cgit.cgi/oe-core/commit/?id=2878a712aabf839cb4c6e84961b6e8deafacf824 Now ti-codec-engine codecs, extensions and server builds but the 'apps' fails to build with a linker error. Here's the compiler log: [..] # # lnkv5T bin/ti_platforms_evm3530/app_remote.xv5T ... /home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-eglibc/sysroots/i686-linux/usr/bin/armv7a-angstrom-linux-gnueabi/arm-angstrom-linux-gnueabi-gcc -o bin/ti_platforms_evm3530/app_remote.xv5T package/cfg/bin/ti_platforms_evm3530/app_remote/main_native.ov5T package/cfg/bin/ti_platforms_evm3530/app_remote_xv5T.ov5T package/cfg/bin/ti_platforms_evm3530/app_remote/app.ov5T package/cfg/bin/ti_platforms_evm3530/app_remote_xv5T.xdl -L/home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-eglibc/sysroots/i686-linux/usr/bin/armv7a-angstrom-linux-gnueabi/arm-angstrom-linux-gnueabi/lib -lpthread Interestingly the path: /home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-eglibc/sysroots/i686-linux/usr/bin/armv7a-angstrom-linux-gnueabi/arm-angstrom-linux-gnueabi/lib doesn't exist, which explains the symbol errors. libgcc contains the symbol `__aeabi_uidivmod' Does this point to another problem with the toolchain? How would we fix this? thanks, Joel ___ 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 bbclass: only add runtime dependencies on hicolor-icon-theme when installing icons
On 08/01/2011 04:08 AM, Koen Kooi wrote:
Tested with gnome-icon-theme and libsoup recipes on angstrom.
But you did not test it against anything in oe-core, it has broken the
build for connman-gnome and oprofileui, which use this bbclass.
The oe-core gnome-icon-theme does not include this class.
Please correct this.
Processing task-base-extended...
| error: Failed dependencies:
| hicolor-icon-theme is needed by tasks-0.19-r0.armv5te
| hicolor-icon-theme is needed by connman-gnome-0.5-r6.armv5te
| hicolor-icon-theme is needed by
oprofileui-server-0.0+git1+0c3c32fa754c1d0b70e65767ea7048914f776396-r4.armv5te
Thanks
Sau!
Signed-off-by: Koen Kooik...@openembedded.org
---
meta/classes/gtk-icon-cache.bbclass |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/meta/classes/gtk-icon-cache.bbclass
b/meta/classes/gtk-icon-cache.bbclass
index dcabaf5..d9b5d1b 100644
--- a/meta/classes/gtk-icon-cache.bbclass
+++ b/meta/classes/gtk-icon-cache.bbclass
@@ -1,5 +1,4 @@
FILES_${PN} += ${datadir}/icons/hicolor
-RDEPENDS += hicolor-icon-theme
# This could run on the host as icon cache files are architecture independent,
# but there is no gtk-update-icon-cache built natively.
@@ -34,7 +33,12 @@ python populate_packages_append () {
icon_dir = '%s/%s/%s/icons' % (pkgdest, pkg,
bb.data.getVar('datadir', d, 1))
if not os.path.exists(icon_dir):
continue
-
+
+ bb.note(adding hicolor-icon-theme dependency to %s % pkg)
+ rdepends = bb.data.getVar('RDEPENDS', d, 1)
+ rdepends += hicolor-icon-theme
+ bb.data.setVar('RDEPENDS', rdepends, d)
+
bb.note(adding gtk-icon-cache postinst and postrm scripts to
%s % pkg)
postinst = bb.data.getVar('pkg_postinst_%s' % pkg, d, 1) or
bb.data.getVar('pkg_postinst', d, 1)
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core] gstreamer-ti, questions
On Thursday, August 04, 2011 08:59:23 PM Joel A Fernandes wrote: Here's the compiler log: [..] # # lnkv5T bin/ti_platforms_evm3530/app_remote.xv5T ... /home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-egli bc/sysroots/i686-linux/usr/bin/armv7a-angstrom-linux-gnueabi/arm-angstro m-linux-gnueabi-gcc -o bin/ti_platforms_evm3530/app_remote.xv5T package/cfg/bin/ti_platforms_evm3530/app_remote/main_native.ov5T package/cfg/bin/ti_platforms_evm3530/app_remote_xv5T.ov5T package/cfg/bin/ti_platforms_evm3530/app_remote/app.ov5T package/cfg/bin/ti_platforms_evm3530/app_remote_xv5T.xdl -L/home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-eg libc/sysroots/i686-linux/usr/bin/armv7a-angstrom-linux-gnueabi/arm-angst rom-linux-gnueabi/lib -lpthread Interestingly the path: /home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-eglibc/s ysroots/i686-linux/usr/bin/armv7a-angstrom-linux-gnueabi/arm-angstrom-linux- gnueabi/lib doesn't exist, which explains the symbol errors. libgcc contains the symbol `__aeabi_uidivmod' Does this point to another problem with the toolchain? I doubt that How would we fix this? make sure libgcc is linked in. It seems the linker commandline is customized ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] erratic failure of pseudo
On Wed Aug 3 05:57:55, James Limbouris wrote: On Tue Aug 2 16:40:09, Mark Hatle wrote: On 8/2/11 5:11 AM, Richard Purdie wrote: On Tue, 2011-08-02 at 07:28 +, James Limbouris wrote: Hi, I've just switched to oe-core from -dev, and I'm finding that my root images are showing incorrect permissions on files, randomly. From one build to the next, different subsets of files and folders end up owned by 1000:1000, instead of root:root. They aren't strictly grouped by package - just random files, different every time. Has anyone else noticed this behaviour? Does anyone have any advice on how to go about debugging? It might help to look at the pseudo db, and see if the permissions are in there - can anyone tell me where it is? I find an empty pseudo folder in the work folder after do_rm_work, but it is not there if I do a bitbake -c build image-xxx. I'd work backwards with this. Check the owners of the files in the packages, then that either points at the packages themselves or the rootfs step. I'd also disable rm_work whilst debugging this since it deletes a lot of the info you might want to use to debug it... There is the PSEUDO_DEBUG=x environmental variable which can help with pseudo debugging too... First, are you using the oe-init-build-env script to setup your environment? If not, are you using the scripts/bitbake wrapper when calling bitbake? If you do not use the wrapper, pseudo is not active and you will get the build uid/gid embedded in the packages (or you will get failures.) Assuming you are using the wrapper... Each package has it's own pseudo database. The final image does as well. As Richard said, start with which file or directories appear to be incorrect. Back up to the package itself and see if they are incorrect in the package. If they are then focus on the work directory of the package. PSEUDO_DEBUG is simply a number starting with '1'. The larger the number the more verbose the debug output will be. Inside of the work directory, i.e. buld/tmp-eglibc/work/i586-oe-linux/zlib-1.2.5-r0, will be a pseudo directory. There is a pseudo.log file here. Inside of the files any un-owned directories that pseudo becomes aware of will be listed. It's pretty typical for there to be one or two directories listed here, normally this is not a problem. If the directories you are having issues with are listed that could be the cause... (If so please let us know by sending a bug report with the package and directories that are having the issues..) The files.db is the database of all of the files. This is an sqlite3 database. The contents of the primary table (file) is: files ( id INTEGER PRIMARY KEY, path VARCHAR, dev INTEGER, ino INTEGER, uid INTEGER, gid INTEGER, mode INTEGER, rdev INTEGER , deleting INTEGER) Use sql commands to find the path you are concerned with and see if it's in the list. Note, not all paths are listed. Some filesystem operations only work based on inode.. In that case the entry is NAMELESS FILE [for the path], and the inode is filed in. Finally, what filesystem are you using? There are a few filesystems like clearcase that do not have consistent inodes. Pseudo uses inodes to verify that the file is the same and has not moved from one instance to the next. (If the inode isn't set it falls back to filename only.) --Mark Cheers, Richard ___ Openembedded-core mailing list Openembedded-core at lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core Hi, Thanks for the detailed hints. I've tracked the problem down to PSEUDO_LOCALSTATEDIR being set incorrectly. If I do a 'bitbake -e xxx-image env.txt' I get a nice long file, with PSEUDO_LOCALSTATEDIR etc all set correctly from openembedded-core/meta/conf/bitbake.conf. However, when I look at run.do_rootfs, there are no pseudo related environment variables. Printing the env from within the script shows that PSEUDO_LOCALSTATEDIR is set to tmp-eglibc/sysroots/i686-linux/var/pseudo/ - so all of my packages have been using the same pseudo db. When a package is rebuilt, lots of inode mismatches etc occur, and some of the files come out corrupt. When building, I use: export SCRIPTS_BASE_VERSION=2 export BBFETCH2=True export BUILDDIR=$PWD/build export PATH=$PWD/sources/openembedded-core/scripts:$PWD/sources/bitbake/bin:$PATH export BB_ENV_EXTRAWHITE=TCLIBC TCMODE GIT_PROXY_COMMAND http_proxy ftp_proxy https_proxy all_proxy ALL_PROXY no_proxy SSH_AGENT_PID SSH_AUTH_SOCK BB_SRCREV_POLICY SDKMACHINE BB_NUMBER_THREADS export BBPATH=$PWD:$PWD/sources/openembedded-core/meta as a preliminary, and then bitbake (which does call the wrapper.) I'm stuck now - I can't work out how the environment from bitbake.conf usually reaches the run.do_* scripts. Regards James Limbouris Hi, I've tried
Re: [OE-core] [oe-core] gstreamer-ti, questions
On Thu, Aug 4, 2011 at 9:41 PM, Khem Raj raj.k...@gmail.com wrote: On Thursday, August 04, 2011 08:59:23 PM Joel A Fernandes wrote: Here's the compiler log: [..] # # lnkv5T bin/ti_platforms_evm3530/app_remote.xv5T ... /home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-egli bc/sysroots/i686-linux/usr/bin/armv7a-angstrom-linux-gnueabi/arm-angstro m-linux-gnueabi-gcc -o bin/ti_platforms_evm3530/app_remote.xv5T package/cfg/bin/ti_platforms_evm3530/app_remote/main_native.ov5T package/cfg/bin/ti_platforms_evm3530/app_remote_xv5T.ov5T package/cfg/bin/ti_platforms_evm3530/app_remote/app.ov5T package/cfg/bin/ti_platforms_evm3530/app_remote_xv5T.xdl -L/home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-eg libc/sysroots/i686-linux/usr/bin/armv7a-angstrom-linux-gnueabi/arm-angst rom-linux-gnueabi/lib -lpthread Interestingly the path: /home/joel/angstrom-oe/setup-scripts-core/build/tmp-angstrom_2010_x-eglibc/s ysroots/i686-linux/usr/bin/armv7a-angstrom-linux-gnueabi/arm-angstrom-linux- gnueabi/lib doesn't exist, which explains the symbol errors. libgcc contains the symbol `__aeabi_uidivmod' Does this point to another problem with the toolchain? I doubt that How would we fix this? make sure libgcc is linked in. It seems the linker commandline is customized Thanks, the issue seems to be with a linker script generated by an older xdctools (3.20) which is said to be fixed in 3.21 [1]. I will try this tomorrow morning. Regards, Joel [1] http://www.eclipse.org/forums/index.php?t=treeth=197704S=bf2c36fb547f9973f300fdf573c34d81 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 01/10] kern-tools: extend arbitrary repository support
On Thu, Aug 4, 2011 at 11:01 AM, nitin.a.kam...@intel.com wrote:
From: Bruce Ashfield bruce.ashfi...@windriver.com
Updating the kern-tools SRCREV to pickup better support for
non-yocto repository support.
59859ca createme: use branch name when creating meta data
91b4275 configme: determine meta branch based on directories, not branch
naming
f5a915c kgit-meta: make branch creation and renaming more robust
This one still needs a bit more testing. I'll be sending a pull request when
I'm happy with it on Friday. So let's wait a just a bit longer for this.
Bruce
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
.../kern-tools/kern-tools-native_git.bb | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
index 1fbb1f7..7ede52a 100644
--- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
+++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM =
file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d8
DEPENDS = git-native guilt-native
-SRCREV = f5a915c277a37ba5949b4c0778356189e7dd9ec0
+SRCREV = cdcb97cfea5f98003b2e0fb1a77b6d0d016a69e7
PR = r10
PV = 0.1+git${SRCPV}
--
1.7.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
--
Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 03/10] linux-yocto: pass KMACHINE to updateme, not MACHINE
On Thu, Aug 4, 2011 at 11:01 AM, nitin.a.kam...@intel.com wrote:
From: Bruce Ashfield bruce.ashfi...@windriver.com
To support the mapping of any oe/yocto MACHINE to a kernel
branch that may not share that naming structure we have
KMACHINE and KBRANCH. To allow the mapping to work, we
actually have to pass KMACHINE into updateme and not MACHINE.
This has also been rebased. I'll include this in my pull request tomorrow. I'm
still doing regression testing on this change.
Bruce
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/classes/kernel-yocto.bbclass | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/classes/kernel-yocto.bbclass
b/meta/classes/kernel-yocto.bbclass
index 8df5f31..e242165 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -28,7 +28,7 @@ do_patch() {
addon_features=$addon_features --feature $feat
done
fi
- updateme --branch ${kbranch} ${addon_features} ${ARCH} ${MACHINE}
${WORKDIR}
+ updateme --branch ${kbranch} ${addon_features} ${ARCH} ${KMACHINE}
${WORKDIR}
if [ $? -ne 0 ]; then
echo ERROR. Could not update ${kbranch}
exit 1
--
1.7.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
--
Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
