[OE-core] [PATCH 1/1] SRC_URI, S: use BPN instead of PN for multilib case
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.
Signed-off-by: Yu Ke
---
.../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(-)
diff --git a/meta-demoapps/recipes-connectivity/farsight/farsight2_0.0.9.bb
b/meta-demoapps/recipes-connectivity/farsight/farsight2_0.0.9.bb
index 483a767..a7bdc97 100644
--- a/meta-demoapps/recipes-connectivity/farsight/farsight2_0.0.9.bb
+++ b/meta-demoapps/recipes-connectivity/farsight/farsight2_0.0.9.bb
@@ -1,6 +1,6 @@
DESCRIPTION = "FarSight is an audio/video conferencing framework specifically
designed for Instant Messengers."
HOMEPAGE = "http://farsight.sf.net";
-SRC_URI = "http://farsight.freedesktop.org/releases/farsight2/${P}.tar.gz";
+SRC_URI =
"http://farsight.freedesktop.org/releases/farsight2/${BPN}-${PV}.tar.gz";
LICENSE = "GPLv2.1"
DEPENDS = "libnice glib-2.0 libxml2 zlib dbus gstreamer gst-plugins-base"
diff --git a/meta-demoapps/recipes-connectivity/loudmouth/loudmouth_1.4.0.bb
b/meta-demoapps/recipes-connectivity/loudmouth/loudmouth_1.4.0.bb
index e20c417..b6af11d 100644
--- a/meta-demoapps/recipes-connectivity/loudmouth/loudmouth_1.4.0.bb
+++ b/meta-demoapps/recipes-connectivity/loudmouth/loudmouth_1.4.0.bb
@@ -5,6 +5,6 @@ LICENSE = "LGPL"
DEPENDS = "glib-2.0 gnutls libcheck"
PR = "r2"
-SRC_URI = "http://ftp.imendio.com/pub/imendio/${PN}/src/${PN}-${PV}.tar.bz2";
+SRC_URI = "http://ftp.imendio.com/pub/imendio/${BPN}/src/${BPN}-${PV}.tar.bz2";
inherit autotools pkgconfig
diff --git
a/meta-demoapps/recipes-connectivity/opensync/libopensync-plugin_0.36.inc
b/meta-demoapps/recipes-connectivity/opensync/libopensync-plugin_0.36.inc
index 147fcfb..cde4779 100644
--- a/meta-demoapps/recipes-connectivity/opensync/libopensync-plugin_0.36.inc
+++ b/meta-demoapps/recipes-connectivity/opensync/libopensync-plugin_0.36.inc
@@ -2,7 +2,7 @@ DEPENDS = "libopensync (>= 0.36)"
DESCRIPTION ?= "OpenSy
[OE-core] [PATCH 0/1] replace PN with BPN in SRC_URI and S for multilib
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
Re: [OE-core] [RFC BUG #1236 2/2] eglibc: Modify ldd script according to multilib config.
> -Original Message- > From: openembedded-core-boun...@lists.openembedded.org > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of > Phil Blundell > Sent: Friday, July 29, 2011 11:38 PM > To: Patches and discussions about the oe-core layer > Subject: Re: [OE-core] [RFC BUG #1236 2/2] eglibc: Modify ldd script according > to multilib config. > > On Fri, 2011-07-29 at 22:57 +0800, Lianhao Lu wrote: > > + "x86": ["ld-linux.so.2", "FLAG_ELF_LIBC5"], > > That looks a bit weird to me. Are you sure that's right? > Oops, it should be FLAG_ELF_LIBC6. -Lianhao ___ 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] license.bbclass: Splitting out licenses
On Wed, Jul 27, 2011 at 2:04 PM, Flanagan, Elizabeth wrote: > I would still pull it. It does give us a basis to work on and splits > things out a bit. > When I get back from the conference this week, I'll fix it so that > it's a more reliable > in returning results. My guess is that I'll have to rip this all out > from being event driven > and do it, as you suggest, a postprocess right after do_rootfs Khem took a pass at this (using the approach Richard suggested), so you might want to consider building on what he did. The testlab stuff in OE is incredibly useful, and might be considered for OE core. Thanks, Cliff http://patches.openembedded.org/patch/7587/ http://patches.openembedded.org/patch/7589/ to oe-core (these patches have been applied) and http://patches.openembedded.org/patch/7591/ (still being discussed) to meta-openembedded Then INHERIT += "testlab" in local.conf if you are using angstrom them testlab is already inherited bitbake console-image and you should see a new file called installed-package-licenses.txt in testlab directory along with other testlab results. -- = http://bec-systems.com ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] feature-arm-thumb: respect ARM_INSTRUCTION_SET
On 7/29/11 3:23 PM, Phil Blundell wrote: > On Fri, 2011-07-29 at 13:08 -0500, Mark Hatle wrote: >> Sorry I was gone much of yesterday and not able to comment. I'm going to >> break >> this down into the two problems that I see people having. >> >> 1) "interworking". I was recently told EABI requires interworking to be >> enabled, and in OE-core we only support EABI. So we should always have the >> interworking enabled for the tunes that we support. >> >> Is this correct, any objections? If so, assume from this point forward >> interworking is always enabled and we only support (in oe-core) interworking >> capable ARM chips. > > That's pretty much right though not 100% correct. Although it is true > that the AAPCS (and by extension the EABI) effectively requires all > relocatable objects to be built with interworking on, there are special > provisions for translating BX to MOV during link edit and hence allowing > v4 CPUs to run executables which are non-interworking but otherwise > conformant with the EABI. The effect of this is that, although v4 isn't > naturally an interworking-capable architecture, it is nonetheless > grandfathered into the EABI universe. See the remarks in section 5.6 of > ARM IHI 0042D. > > And, pragmatically, there is a small but significant base of OE users on > v4 (not v4t) platforms and I don't think we want to do anything that > would disenfranchise them in OE-core. Which set of users is still v4 (not interworking compatible)? Are new processors being made that still require that capability? or (in oe-core) is it time to drop support? Just because it's not in oe-core, doesn't mean it can't be in angstrom, or even meta-oe as unique tunings for those architectures.. > Neither the AAPCS nor the wider EABI makes any attempt to cater for > architectures earlier than v4 and I don't think OE-core needs to do so > either. It's not totally unimaginable that someone might wish to target > OE-core at a v3 system but, if that ever happens, they can fill in the > missing bits in an overlay. Ya, I never expected we'd support anything older the v4... but there is more variation in v4 then I had realized. >> The confusion continues that people are expecting a package arch of "armv5t" >> to >> be arbitrarily thumb or not thumb.. since the arch (to them) indicates that >> the >> CPU is compatible with both thumb and ARM code. That was not the intent of >> this >> change. Instead the _package architecture_ is designed to convey the ABI and >> instruction set used when building the software in the package. > > It's worth pointing out, just in case it isn't already obvious, that an > individual package might contain a mixture of ARM and Thumb binaries, > and an individual binary might contain a mixture of ARM-state and > Thumb-state functions. This is doubly true when static libraries are > involved, of course. Some compilers may (although GCC doesn't, today) > even switch automatically between ARM-state and Thumb-state depending on > their view of which is going to give the best results. I didn't realize there were compilers that would switch states.. the others I knew, but for the most part things are built on a package-level basis with a single set of options for the whole package. (There will always be exceptions of course.) > So, the distinction between "arm" and "thumb" binaries is always going > to be a slightly blurry one and, although I can see the attraction of > being able to label a particular package as "arm" or "thumb", it's more > a question of picking points on a continuum than a binary switch. Currently the switching point is on a recipe basis. I'm sure we could make a recipe that does both thumb and arm and do dynamic switching on a binary by binary basis inside of a recipe.. but nothing that I am aware of does that today. I've also not seen any real-world use cases that point to this -- outside of custom application code that is being specifically tuned for a device. >> This not only helps with debugging what someone is using, but also helps with >> designing filesystems that may contain both arm and thumb code. For example >> a >> developer is building a device.. they have the requirements of "higher" >> performance in there specific application, but maximum space savings >> everywhere >> else. They want to start with a binary package feed, NOT the build system. >> So >> they will mix and match the armv5 and armv5t packages by choosing the smaller >> packages for most things (usually thumb), and using the ARM instruction set >> where they need performance (usually armv5 packages). >> >> --- >> >> So having a single value that simply switches the instruction set, without >> changing the package arch violates the intent of the change. An alternative >> would be something like: > > It's not entirely obvious to me that Thumb-ness is, in this sense, > sufficiently special to deserve a distinct package architecture. After > all, one can already
Re: [OE-core] [PATCH] feature-arm-thumb: respect ARM_INSTRUCTION_SET
On Fri, 2011-07-29 at 13:08 -0500, Mark Hatle wrote: > Sorry I was gone much of yesterday and not able to comment. I'm going to > break > this down into the two problems that I see people having. > > 1) "interworking". I was recently told EABI requires interworking to be > enabled, and in OE-core we only support EABI. So we should always have the > interworking enabled for the tunes that we support. > > Is this correct, any objections? If so, assume from this point forward > interworking is always enabled and we only support (in oe-core) interworking > capable ARM chips. That's pretty much right though not 100% correct. Although it is true that the AAPCS (and by extension the EABI) effectively requires all relocatable objects to be built with interworking on, there are special provisions for translating BX to MOV during link edit and hence allowing v4 CPUs to run executables which are non-interworking but otherwise conformant with the EABI. The effect of this is that, although v4 isn't naturally an interworking-capable architecture, it is nonetheless grandfathered into the EABI universe. See the remarks in section 5.6 of ARM IHI 0042D. And, pragmatically, there is a small but significant base of OE users on v4 (not v4t) platforms and I don't think we want to do anything that would disenfranchise them in OE-core. Neither the AAPCS nor the wider EABI makes any attempt to cater for architectures earlier than v4 and I don't think OE-core needs to do so either. It's not totally unimaginable that someone might wish to target OE-core at a v3 system but, if that ever happens, they can fill in the missing bits in an overlay. > The confusion continues that people are expecting a package arch of "armv5t" > to > be arbitrarily thumb or not thumb.. since the arch (to them) indicates that > the > CPU is compatible with both thumb and ARM code. That was not the intent of > this > change. Instead the _package architecture_ is designed to convey the ABI and > instruction set used when building the software in the package. It's worth pointing out, just in case it isn't already obvious, that an individual package might contain a mixture of ARM and Thumb binaries, and an individual binary might contain a mixture of ARM-state and Thumb-state functions. This is doubly true when static libraries are involved, of course. Some compilers may (although GCC doesn't, today) even switch automatically between ARM-state and Thumb-state depending on their view of which is going to give the best results. So, the distinction between "arm" and "thumb" binaries is always going to be a slightly blurry one and, although I can see the attraction of being able to label a particular package as "arm" or "thumb", it's more a question of picking points on a continuum than a binary switch. > This not only helps with debugging what someone is using, but also helps with > designing filesystems that may contain both arm and thumb code. For example a > developer is building a device.. they have the requirements of "higher" > performance in there specific application, but maximum space savings > everywhere > else. They want to start with a binary package feed, NOT the build system. > So > they will mix and match the armv5 and armv5t packages by choosing the smaller > packages for most things (usually thumb), and using the ARM instruction set > where they need performance (usually armv5 packages). > > --- > > So having a single value that simply switches the instruction set, without > changing the package arch violates the intent of the change. An alternative > would be something like: It's not entirely obvious to me that Thumb-ness is, in this sense, sufficiently special to deserve a distinct package architecture. After all, one can already switch between -Os and -O99, or different -mtune levels or no doubt many other things which influence code size and performance without the package architecture changing. I guess some DISTROs might want to offer a smorgasbord kind of approach where every binary is compiled in N different ways and packaged separately, but I get the general sense that most distros will probably not want to do that and perhaps it oughtn't to be the default behaviour. (And of course, on another pragmatic point, it isn't by any means universally true that ARM-state has better performance than Thumb-state on real world systems. There are a significant number of cases where you get higher performance in Thumb-state than ARM-state.) p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] feature-arm-thumb: respect ARM_INSTRUCTION_SET
Sorry I was gone much of yesterday and not able to comment. I'm going to break
this down into the two problems that I see people having.
1) "interworking". I was recently told EABI requires interworking to be
enabled, and in OE-core we only support EABI. So we should always have the
interworking enabled for the tunes that we support.
Is this correct, any objections? If so, assume from this point forward
interworking is always enabled and we only support (in oe-core) interworking
capable ARM chips.
2) The tune naming is confusing people.
Initial design was (tune name):
armv5 = armv5 class CPU, with ARM instructions, w/ interworking enabled
armv5t = armv5 class CPU, with thumb instructions, w/ interworking enabled
The output of "armv5" was a package with the arch of "armv5", output of "armv5t"
was similarly "armv5t". Note, the package arch produced though is NOT the same
as the tune name, it just happens to be the same in these cases. (We could
easily call the tune names "armv5t_nothumb" and "armv5t_thumb" and still have
package arch of "armv5" and "armv5t".)
The confusion continues that people are expecting a package arch of "armv5t" to
be arbitrarily thumb or not thumb.. since the arch (to them) indicates that the
CPU is compatible with both thumb and ARM code. That was not the intent of this
change. Instead the _package architecture_ is designed to convey the ABI and
instruction set used when building the software in the package.
This not only helps with debugging what someone is using, but also helps with
designing filesystems that may contain both arm and thumb code. For example a
developer is building a device.. they have the requirements of "higher"
performance in there specific application, but maximum space savings everywhere
else. They want to start with a binary package feed, NOT the build system. So
they will mix and match the armv5 and armv5t packages by choosing the smaller
packages for most things (usually thumb), and using the ARM instruction set
where they need performance (usually armv5 packages).
---
So having a single value that simply switches the instruction set, without
changing the package arch violates the intent of the change. An alternative
would be something like:
feature-arm-thumb.inc:>
TUNEVALID[thumb] = "Support using thumb instructions"
TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "thumb",
"${ARM_THUMB_M_OPT}", "", d)}"
ARM_THUMB_M_OPT = "${@['-mno-thumb',
'-mthumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1) == 'thumb']}"
OVERRIDES .= "${['', ':thumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1) ==
'thumb']}"
ARMPKGSFX_THUMB .= ${['', '_thumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1)
== 'thumb']}"
TARGET_CC_KERNEL_ARCH += "-mno-thumb-interwork -mno-thumb"
tune-armv5.inc:
DEFAULTTUNE ?= "armv5t"
ARMPKGARCH ?= "armv5t"
TUNEVALID[armv5t] = "Enable instructions for ARMv5"
TUNE_CONFLICTS[armv5t] = "armv4"
TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv5t",
"-march=armv5t${ARMPKGSFX_DSP}", "", d)}"
ARMPKGSFX_DSP = "${@bb.utils.contains("TUNE_FEATURES", [ "armv5t", "dsp" ], "e",
"", d)}"
require conf/machine/include/arm/arch-armv4.inc
require conf/machine/include/arm/feature-arm-vfp.inc
require conf/machine/include/arm/feature-arm-thumb.inc
AVAILTUNES += "armv5t armv5te"
TUNE_FEATURES_tune-armv5t = "armv5 thumb"
TUNE_FEATURES_tune-armv5te = "armv5 dsp thumb"
(and some more lines for compatibility)
arch-arm.inc:
...
TUNE_PKGARCH = "${@d.getVar('ARMPKGARCH',
True)}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}${ARMPKGSFX_THUMB}"
When you select the tune of "armv5t" you will get classic ARM instructions with
the ability to enable thumb via ARM_INSTRUCTION_SET = thumb.
When you switch into building thumb (or out of it) the two produced package arch
will be:
armv5t
armv5t_thumb
This allows per packages switching using the ARM_INSTRUCTION_SET instead of
specific tune features, and still preserves the design of capturing the ABI &
instruction set in the package arch.
If this is reasonable, I'll work on a more complete patch set for this.
--Mark
On 7/29/11 12:10 PM, Martin Jansa wrote:
> On Fri, Jul 29, 2011 at 07:04:33PM +0200, Martin Jansa wrote:
>> Signed-off-by: Martin Jansa
>> ---
>> .../conf/machine/include/arm/feature-arm-thumb.inc |3 ++-
>> 1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/meta/conf/machine/include/arm/feature-arm-thumb.inc
>> b/meta/conf/machine/include/arm/feature-arm-thumb.inc
>> index b580168..e7d392e 100644
>> --- a/meta/conf/machine/include/arm/feature-arm-thumb.inc
>> +++ b/meta/conf/machine/include/arm/feature-arm-thumb.inc
>> @@ -5,7 +5,8 @@
>> # but requires more instructions (140% for 70% smaller code) so may be
>> # slower.
>> TUNEVALID[thumb] = "Use thumb instructions instead of ARM"
>> -TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "thumb", "-mthumb",
>> "-mno-thumb", d)}"
>> +ARM_THUMB_M_OPT = "${@['-mno-thumb',
>> '-
Re: [OE-core] [PATCH] feature-arm-thumb: respect ARM_INSTRUCTION_SET
On Fri, Jul 29, 2011 at 07:04:33PM +0200, Martin Jansa wrote:
> Signed-off-by: Martin Jansa
> ---
> .../conf/machine/include/arm/feature-arm-thumb.inc |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/meta/conf/machine/include/arm/feature-arm-thumb.inc
> b/meta/conf/machine/include/arm/feature-arm-thumb.inc
> index b580168..e7d392e 100644
> --- a/meta/conf/machine/include/arm/feature-arm-thumb.inc
> +++ b/meta/conf/machine/include/arm/feature-arm-thumb.inc
> @@ -5,7 +5,8 @@
> # but requires more instructions (140% for 70% smaller code) so may be
> # slower.
> TUNEVALID[thumb] = "Use thumb instructions instead of ARM"
> -TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "thumb", "-mthumb",
> "-mno-thumb", d)}"
> +ARM_THUMB_M_OPT = "${@['-mno-thumb',
> '-mthumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1) == 'thumb']}"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "thumb",
> "${ARM_THUMB_M_OPT}", "${ARM_THUMB_M_OPT}", d)}"
> OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "thumb", ":thumb", "",
> d)}"
>
> # Note armv7 will hit on armv7a as well
> --
> 1.7.6
>
This seems to work, but be aware that _armv4t override is not respected
anymore :/.
I was using something like this to set default ARM_INSTRUCTION_SET from
distro config:
PREFERRED_ARM_INSTRUCTION_SET_armv4t = "thumb"
PREFERRED_ARM_INSTRUCTION_SET_armv5te = "thumb"
PREFERRED_ARM_INSTRUCTION_SET_armv5teb = "thumb"
PREFERRED_ARM_INSTRUCTION_SET ?= "arm"
ARM_INSTRUCTION_SET = "${PREFERRED_ARM_INSTRUCTION_SET}"
but from -e output it's clear that it's ignored
# PREFERRED_ARM_INSTRUCTION_SET_armv4t=thumb
PREFERRED_ARM_INSTRUCTION_SET_armv4t="thumb"
# PREFERRED_ARM_INSTRUCTION_SET=arm
PREFERRED_ARM_INSTRUCTION_SET="arm"
# PREFERRED_ARM_INSTRUCTION_SET_armv5te=thumb
PREFERRED_ARM_INSTRUCTION_SET_armv5te="thumb"
# PREFERRED_ARM_INSTRUCTION_SET_armv5teb=thumb
PREFERRED_ARM_INSTRUCTION_SET_armv5teb="thumb"
# ARM_INSTRUCTION_SET=${PREFERRED_ARM_INSTRUCTION_SET}
ARM_INSTRUCTION_SET="arm"
Regards,
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] feature-arm-thumb: respect ARM_INSTRUCTION_SET
Signed-off-by: Martin Jansa
---
.../conf/machine/include/arm/feature-arm-thumb.inc |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/meta/conf/machine/include/arm/feature-arm-thumb.inc
b/meta/conf/machine/include/arm/feature-arm-thumb.inc
index b580168..e7d392e 100644
--- a/meta/conf/machine/include/arm/feature-arm-thumb.inc
+++ b/meta/conf/machine/include/arm/feature-arm-thumb.inc
@@ -5,7 +5,8 @@
# but requires more instructions (140% for 70% smaller code) so may be
# slower.
TUNEVALID[thumb] = "Use thumb instructions instead of ARM"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "thumb", "-mthumb",
"-mno-thumb", d)}"
+ARM_THUMB_M_OPT = "${@['-mno-thumb',
'-mthumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1) == 'thumb']}"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "thumb",
"${ARM_THUMB_M_OPT}", "${ARM_THUMB_M_OPT}", d)}"
OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "thumb", ":thumb", "", d)}"
# Note armv7 will hit on armv7a as well
--
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] feature-arm-thumb: Take ARM_INSTRUCTION_SET into account to decide thumb mode
This will decouple the compiling in thumb mode from having thumb
capable cores.
Signed-off-by: Khem Raj
---
.../conf/machine/include/arm/feature-arm-thumb.inc |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/meta/conf/machine/include/arm/feature-arm-thumb.inc
b/meta/conf/machine/include/arm/feature-arm-thumb.inc
index b580168..533eab9 100644
--- a/meta/conf/machine/include/arm/feature-arm-thumb.inc
+++ b/meta/conf/machine/include/arm/feature-arm-thumb.inc
@@ -4,7 +4,10 @@
# encoded RISC sub-set. Thumb code is smaller (maybe 70% of the ARM size)
# but requires more instructions (140% for 70% smaller code) so may be
# slower.
-TUNEVALID[thumb] = "Use thumb instructions instead of ARM"
+TUNEVALID[thumb] = "Use thumb instructions instead of ARM if
ARM_INSTRUCTION_SET != arm"
+ARM_THUMB_M_OPT = "${@['-mthumb',
'-mno-thumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1) != 'arm']}"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "thumb",
"${ARM_THUMB_M_OPT}", "${ARM_THUMB_M_OPT}", d)}"
+
TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "thumb", "-mthumb",
"-mno-thumb", d)}"
OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "thumb", ":thumb", "", d)}"
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] classes, recipes: Replace use of ARM_INSTRUCTION_SET with contruct using TUNE_FEATURES
On 07/29/2011 09:39 AM, Martin Jansa wrote:
On Fri, Jul 29, 2011 at 07:59:31AM -0700, Khem Raj wrote:
Currently when using thumb feature all recipes can not be compiled in
thumb mode. Therefore we had ARM_INSTRUCTION_SET to force arm intruction
set even when thumb was global choice. With this patch we remove thumb
from tune features for these recipes. This will make sure that compiler
is not using thumb options to compile these recipes at all.
Signed-off-by: Khem Raj
---
meta/classes/qt4e.bbclass |2 +-
meta/classes/qt4x11.bbclass|2 +-
meta/conf/machine/include/tune-thumb.inc | 32
meta/recipes-core/eglibc/eglibc.inc|4 +-
meta/recipes-core/glib-2.0/glib.inc|4 ++-
meta/recipes-core/glibc/glibc.inc |4 ++-
meta/recipes-core/glibc/glibc_2.10.1.bb|3 +-
meta/recipes-core/uclibc/uclibc.inc|2 +-
meta/recipes-devtools/gcc/gcc-csl-arm-2008q1.inc |3 +-
.../xorg-xserver/xserver-kdrive.inc|4 ++-
meta/recipes-multimedia/alsa/alsa-lib_1.0.24.1.bb |3 +-
.../gstreamer/gst-plugins-bad_0.10.21.bb |3 +-
meta/recipes-multimedia/libmad/libmad_0.15.1b.bb |4 ++-
meta/recipes-multimedia/tremor/tremor_20101121.bb |4 ++-
meta/recipes-qt/qt4/qt4_arch.inc |3 +-
meta/recipes-support/boost/boost-36.inc|4 ++-
meta/recipes-support/gmp/gmp.inc |3 +-
meta/recipes-support/libgcrypt/libgcrypt.inc |3 +-
meta/recipes-support/liboil/liboil_0.3.17.bb |3 +-
19 files changed, 39 insertions(+), 51 deletions(-)
delete mode 100644 meta/conf/machine/include/tune-thumb.inc
this causes ie eglibc not only to disable thumb but also to pass
-march=armv4 and look in wrong directory for toolchain.. which because
it's not filtering thumb is in armv4t-oe-linux-gnueabi
export PATH="
/OE/shr-core/tmp/sysroots/x86_64-linux/usr/bin/armv4-oe-linux-gnueabi.gcc-cross-initial:
/OE/shr-core/tmp/sysroots/x86_64-linux/usr/bin/armv4-oe-linux-gnueabi:
/OE/shr-core/tmp/sysroots/om-gta02/usr/bin/crossscripts:
/OE/shr-core/tmp/sysroots/x86_64-linux/usr/sbin:
/OE/shr-core/tmp/sysroots/x86_64-linux/usr/bin:
/OE/shr-core/tmp/sysroots/x86_64-linux/sbin:
/OE/shr-core/tmp/sysroots/x86_64-linux//bin:
/OE/shr-core/openembedded-core/scripts:
/OE/bin:
/usr/local/bin:
/usr/bin:
/bin:
/opt/bin:
/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.1:
/OE/shr-core/openembedded-core/scripts"
simple forward of oe.dev arm-thumb.inc logic to arm-feature-thumb.inc
+++ b/meta/conf/machine/include/arm/feature-arm-thumb.inc
@@ -5,7 +5,8 @@
# but requires more instructions (140% for 70% smaller code) so may be
# slower.
TUNEVALID[thumb] = "Use thumb instructions instead of ARM"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "thumb", "-mthumb",
"-mno-thumb", d)}"
+ARM_THUMB_M_OPT = "${@['-mno-thumb',
'-mthumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1) == 'thumb']}"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}",
"${ARM_THUMB_M_OPT}", d)}"
seems to work.. will send patch after more testing, but eglibc compiled fine
now..
decoupling the -mthumb/-mno-thumb from thumb tune feature is right think
to do.
yes this would be something on the lines I was thinking can work with
minimal changes.
Regards,
___
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] arm tune files status summary
On 07/29/2011 06:28 AM, Phil Blundell wrote:
There are quite a lot of different sub-threads going on at the moment
regarding the various breakages associated with the recent arm tuning
file patch. Here's a summary of what I think are all the current issues
and their status.
1. bogus PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} in bitbake.conf causing
rootfs construction to fail.
Paul and Koen both posted (essentially identical) patches for this and
it looks as though Paul's has been applied. So, the original breakage
should be resolved but it isn't entirely clear what this line in
bitbake.conf was trying to accomplish in the first place. I think
someone still needs to conduct an audit to establish whether there are
any circumstances where PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} does
need setting to ${TARGET_ARCH} and, if so, make that happen.
2. endianness confusion in armv5/armv6 tune files.
I posted a patch for this. It doesn't look like it's been applied yet
but it's in the archives for anybody who wants it. Only big-endian
configs would be affected anyway and I think those are something of a
fringe pursuit.
I am testing this patch
3. eglibc unbuildable on qemuarm
This is happening because qemuarm selects arm926ejs tuning, which in
turn selects armv5te, and the current arrangement of tune files forces
Thumb-state on if you ask to tune for a T-variant architecture. The old
"ARM_INSTRUCTION_SET" variable which used to override the ISA selection
seems not to be respected anymore. This is unfortunate because there is
assembler code in eglibc which isn't Thumb-1 aware and hence can't be
built under -mthumb.
A short-term workaround would be to hack tune-arm926ejs.inc to select
the TUNE_FEATURES for armv5e rather than armv5te. But this is clearly
not a good solution in general and, other than changing the underlying
policy of inferring ISA choice from architecture name, it's not obvious
what the right way of solving it is.
This particular issue causes sufficiently gross breakage that I would
have expected it to show up on the Yocto autobuilder run before the
patch was merged. I'm not quite sure why it apparently didn't fail
there but maybe the autobuilder doesn't actually test qemuarm at
present.
I have posted a patch for this
4. can't build ARM-state code for ARMv4T architecture.
This is another facet of the above; there is currently no way to say
that you want to select -march=armv4t without also enabling -mthumb.
This makes it impossible to build interworking-capable ARM-state code
for v4T.
yeah this is kind of fundamental problem. We need to differentiate
between having thumb feature and really using it.
5. cortex tuning not working
Various of the cortex files had a spelling mistake which would cause the
TUNE_FEATURES never to actually match anything. This is a trivial fix
and I sent a patch for it yesterday. I don't think it's been merged
yet.
I am testing this patch
6. distros no longer able to select ARM vs Thumb state either globally
or per package
My thinking is that default should always be ARM mode and then distros
can say TUNE_FEATURES += "usethumb" then tune infra can check for both
i.e. having thumb in machines and distros asking for it before adding
-mthumb to CCARGS
This is really another manifestation of the issue in #3. But the point
here isn't so much that builds are failing, rather that we seem to have
lost the ability to have a single switch that the DISTRO can flip to
build the entire world (or individual packages) as Thumb rather than
ARM. For Thumb-1 in particular the tradeoffs are sufficiently
complicated that I don't think there is ever going to be a globally
"right" answer.
I think that's all I know of.
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] classes, recipes: Replace use of ARM_INSTRUCTION_SET with contruct using TUNE_FEATURES
On Fri, Jul 29, 2011 at 07:59:31AM -0700, Khem Raj wrote:
> Currently when using thumb feature all recipes can not be compiled in
> thumb mode. Therefore we had ARM_INSTRUCTION_SET to force arm intruction
> set even when thumb was global choice. With this patch we remove thumb
> from tune features for these recipes. This will make sure that compiler
> is not using thumb options to compile these recipes at all.
>
> Signed-off-by: Khem Raj
> ---
> meta/classes/qt4e.bbclass |2 +-
> meta/classes/qt4x11.bbclass|2 +-
> meta/conf/machine/include/tune-thumb.inc | 32
>
> meta/recipes-core/eglibc/eglibc.inc|4 +-
> meta/recipes-core/glib-2.0/glib.inc|4 ++-
> meta/recipes-core/glibc/glibc.inc |4 ++-
> meta/recipes-core/glibc/glibc_2.10.1.bb|3 +-
> meta/recipes-core/uclibc/uclibc.inc|2 +-
> meta/recipes-devtools/gcc/gcc-csl-arm-2008q1.inc |3 +-
> .../xorg-xserver/xserver-kdrive.inc|4 ++-
> meta/recipes-multimedia/alsa/alsa-lib_1.0.24.1.bb |3 +-
> .../gstreamer/gst-plugins-bad_0.10.21.bb |3 +-
> meta/recipes-multimedia/libmad/libmad_0.15.1b.bb |4 ++-
> meta/recipes-multimedia/tremor/tremor_20101121.bb |4 ++-
> meta/recipes-qt/qt4/qt4_arch.inc |3 +-
> meta/recipes-support/boost/boost-36.inc|4 ++-
> meta/recipes-support/gmp/gmp.inc |3 +-
> meta/recipes-support/libgcrypt/libgcrypt.inc |3 +-
> meta/recipes-support/liboil/liboil_0.3.17.bb |3 +-
> 19 files changed, 39 insertions(+), 51 deletions(-)
> delete mode 100644 meta/conf/machine/include/tune-thumb.inc
this causes ie eglibc not only to disable thumb but also to pass
-march=armv4 and look in wrong directory for toolchain.. which because
it's not filtering thumb is in armv4t-oe-linux-gnueabi
export PATH="
/OE/shr-core/tmp/sysroots/x86_64-linux/usr/bin/armv4-oe-linux-gnueabi.gcc-cross-initial:
/OE/shr-core/tmp/sysroots/x86_64-linux/usr/bin/armv4-oe-linux-gnueabi:
/OE/shr-core/tmp/sysroots/om-gta02/usr/bin/crossscripts:
/OE/shr-core/tmp/sysroots/x86_64-linux/usr/sbin:
/OE/shr-core/tmp/sysroots/x86_64-linux/usr/bin:
/OE/shr-core/tmp/sysroots/x86_64-linux/sbin:
/OE/shr-core/tmp/sysroots/x86_64-linux//bin:
/OE/shr-core/openembedded-core/scripts:
/OE/bin:
/usr/local/bin:
/usr/bin:
/bin:
/opt/bin:
/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.1:
/OE/shr-core/openembedded-core/scripts"
simple forward of oe.dev arm-thumb.inc logic to arm-feature-thumb.inc
+++ b/meta/conf/machine/include/arm/feature-arm-thumb.inc
@@ -5,7 +5,8 @@
# but requires more instructions (140% for 70% smaller code) so may be
# slower.
TUNEVALID[thumb] = "Use thumb instructions instead of ARM"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "thumb", "-mthumb",
"-mno-thumb", d)}"
+ARM_THUMB_M_OPT = "${@['-mno-thumb',
'-mthumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1) == 'thumb']}"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "thumb",
"${ARM_THUMB_M_OPT}", "${ARM_THUMB_M_OPT}", d)}"
seems to work.. will send patch after more testing, but eglibc compiled fine
now..
Regards,
signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC BUG #1236 2/2] eglibc: Modify ldd script according to multilib config.
On Fri, 2011-07-29 at 22:57 +0800, Lianhao Lu wrote: > + "x86": ["ld-linux.so.2", "FLAG_ELF_LIBC5"], That looks a bit weird to me. Are you sure that's right? p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] tune-xscale: fix xscale/xscale-be confusion
Currently tune-xscale.inc has options wrt. setting of xscale/xscale-be tunes.
Fix that.
Signed-off-by: Dmitry Eremin-Solenikov
---
meta/conf/machine/include/tune-xscale.inc |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/conf/machine/include/tune-xscale.inc
b/meta/conf/machine/include/tune-xscale.inc
index 9fe9685..54f3727 100644
--- a/meta/conf/machine/include/tune-xscale.inc
+++ b/meta/conf/machine/include/tune-xscale.inc
@@ -10,7 +10,7 @@ TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5te}
xscale"
PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}"
AVAILTUNES += "xscale-be"
-TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5teb} xscale"
+TUNE_FEATURES_tune-xscale-be = "${TUNE_FEATURES_tune-armv5teb} xscale-be"
PACKAGE_EXTRA_ARCHS_tune-xscale-be = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
# webkit-gtk has alignment issues with double instructions on armv5 so
--
1.7.2.3
___
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] python-native: Fix a compiler finding issue
On 07/28/2011 11:58 PM, Mei, Lei wrote:
>
>
>> -Original Message-
>> From: openembedded-core-boun...@lists.openembedded.org
>> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
>> Tom Rini
>> Sent: Friday, July 29, 2011 9:44 AM
>> To: openembedded-core@lists.openembedded.org
>> Subject: Re: [OE-core] [PATCH 1/1] python-native: Fix a compiler finding
>> issue
>>
>> On 07/28/2011 06:15 PM, Mei, Lei wrote:
>>>
>>>
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
>> Of
Tom Rini
Sent: Thursday, July 28, 2011 11:09 PM
To: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH 1/1] python-native: Fix a compiler finding
>> issue
On 07/28/2011 12:20 AM, Mei Lei wrote:
> The CC variable sometimes add option information after compiler name,
>> but
python can't get the real compiler name if those information added.
> Fix this issue by dropping the option information when finding compiler
>> name.
>
> Signed-off-by: Mei Lei
I think this is going to cause problems when you must pass flags to gcc
to have it work, eg 'gcc -m64'.
>>>
>>> This patch fixed your worried issue.
>>> The CC variable, sometimes like: "x86_64-poky-linux-gcc -m64
>> --sysroot=/${TMPDIR}/sysroots/qemux86-64", contains flags information.
>>> This will lead to wrong compiler name "qemux86-64" rather than
>> "x86_64-poky-linux-gcc" when python finding the compiler name, so add this
>> patch to find the real gcc name.
>>
>> No, what I'm saying is I have a compiler that must be invoked as 'gcc
>> -m64' (which is what BUILD_CC is). So, I think after saying that, the
>> right answer is to modify python to read the OE-specific BUILD_CC variable.
>
>
> I think I didn't describe this patch exactly before.
>
> This patch is only for function runtime_library_dir_option, this function is
> to detect which platform we are running and what compiler we used, then
> decide what option information should be passed to compiler.
>
> By default, our cross-compiler's name be recognized as "qemux86" rather than
> " x86_64-poky-linux-gcc" in this function, this is wrong, this will induce a
> wrong option information passed to x86_64-poky-linux-gcc and block the
> compile process.
>
> And function runtime_library_dir_option only return the option information,
> so didn't influence compiler name in global.
>
> By the way, I think BUILD_CC is host compiler name, not for target.
You're patching python-native, not python, which means the host python
and not the target python.
--
Tom Rini
Mentor Graphics Corporation
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] arm tune files status summary
Op 29 jul. 2011 om 15:28 heeft Phil Blundell het volgende
geschreven:
> There are quite a lot of different sub-threads going on at the moment
> regarding the various breakages associated with the recent arm tuning
> file patch. Here's a summary of what I think are all the current issues
> and their status.
>
> 1. bogus PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} in bitbake.conf causing
> rootfs construction to fail.
>
> Paul and Koen both posted (essentially identical) patches for this and
> it looks as though Paul's has been applied. So, the original breakage
> should be resolved but it isn't entirely clear what this line in
> bitbake.conf was trying to accomplish in the first place. I think
> someone still needs to conduct an audit to establish whether there are
> any circumstances where PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} does
> need setting to ${TARGET_ARCH} and, if so, make that happen.
>
> 2. endianness confusion in armv5/armv6 tune files.
>
> I posted a patch for this. It doesn't look like it's been applied yet
> but it's in the archives for anybody who wants it. Only big-endian
> configs would be affected anyway and I think those are something of a
> fringe pursuit.
>
> 3. eglibc unbuildable on qemuarm
>
> This is happening because qemuarm selects arm926ejs tuning, which in
> turn selects armv5te, and the current arrangement of tune files forces
> Thumb-state on if you ask to tune for a T-variant architecture. The old
> "ARM_INSTRUCTION_SET" variable which used to override the ISA selection
> seems not to be respected anymore. This is unfortunate because there is
> assembler code in eglibc which isn't Thumb-1 aware and hence can't be
> built under -mthumb.
>
> A short-term workaround would be to hack tune-arm926ejs.inc to select
> the TUNE_FEATURES for armv5e rather than armv5te. But this is clearly
> not a good solution in general and, other than changing the underlying
> policy of inferring ISA choice from architecture name, it's not obvious
> what the right way of solving it is.
>
> This particular issue causes sufficiently gross breakage that I would
> have expected it to show up on the Yocto autobuilder run before the
> patch was merged. I'm not quite sure why it apparently didn't fail
> there but maybe the autobuilder doesn't actually test qemuarm at
> present.
>
> 4. can't build ARM-state code for ARMv4T architecture.
>
> This is another facet of the above; there is currently no way to say
> that you want to select -march=armv4t without also enabling -mthumb.
> This makes it impossible to build interworking-capable ARM-state code
> for v4T.
>
> 5. cortex tuning not working
>
> Various of the cortex files had a spelling mistake which would cause the
> TUNE_FEATURES never to actually match anything. This is a trivial fix
> and I sent a patch for it yesterday. I don't think it's been merged
> yet.
>
> 6. distros no longer able to select ARM vs Thumb state either globally
> or per package
>
> This is really another manifestation of the issue in #3. But the point
> here isn't so much that builds are failing, rather that we seem to have
> lost the ability to have a single switch that the DISTRO can flip to
> build the entire world (or individual packages) as Thumb rather than
> ARM. For Thumb-1 in particular the tradeoffs are sufficiently
> complicated that I don't think there is ever going to be a globally
> "right" answer.
>
> I think that's all I know of.
This matches my observations, thanks for summarizing all this!
>
> 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] [PATCH] classes, recipes: Replace use of ARM_INSTRUCTION_SET with contruct using TUNE_FEATURES
Currently when using thumb feature all recipes can not be compiled in
thumb mode. Therefore we had ARM_INSTRUCTION_SET to force arm intruction
set even when thumb was global choice. With this patch we remove thumb
from tune features for these recipes. This will make sure that compiler
is not using thumb options to compile these recipes at all.
Signed-off-by: Khem Raj
---
meta/classes/qt4e.bbclass |2 +-
meta/classes/qt4x11.bbclass|2 +-
meta/conf/machine/include/tune-thumb.inc | 32
meta/recipes-core/eglibc/eglibc.inc|4 +-
meta/recipes-core/glib-2.0/glib.inc|4 ++-
meta/recipes-core/glibc/glibc.inc |4 ++-
meta/recipes-core/glibc/glibc_2.10.1.bb|3 +-
meta/recipes-core/uclibc/uclibc.inc|2 +-
meta/recipes-devtools/gcc/gcc-csl-arm-2008q1.inc |3 +-
.../xorg-xserver/xserver-kdrive.inc|4 ++-
meta/recipes-multimedia/alsa/alsa-lib_1.0.24.1.bb |3 +-
.../gstreamer/gst-plugins-bad_0.10.21.bb |3 +-
meta/recipes-multimedia/libmad/libmad_0.15.1b.bb |4 ++-
meta/recipes-multimedia/tremor/tremor_20101121.bb |4 ++-
meta/recipes-qt/qt4/qt4_arch.inc |3 +-
meta/recipes-support/boost/boost-36.inc|4 ++-
meta/recipes-support/gmp/gmp.inc |3 +-
meta/recipes-support/libgcrypt/libgcrypt.inc |3 +-
meta/recipes-support/liboil/liboil_0.3.17.bb |3 +-
19 files changed, 39 insertions(+), 51 deletions(-)
delete mode 100644 meta/conf/machine/include/tune-thumb.inc
diff --git a/meta/classes/qt4e.bbclass b/meta/classes/qt4e.bbclass
index 670605b..ab91ab3 100644
--- a/meta/classes/qt4e.bbclass
+++ b/meta/classes/qt4e.bbclass
@@ -15,4 +15,4 @@ export OE_QMAKE_EXTRA_MODULES = "network"
EXTRA_QMAKEVARS_PRE += " QT_LIBINFIX=${QT_LIBINFIX} "
# Qt4 uses atomic instructions not supported in thumb mode
-ARM_INSTRUCTION_SET = "arm"
+TUNE_FEATURES := "${@oe_filter_out('thumb', '${TUNE_FEATURES}', d)}"
diff --git a/meta/classes/qt4x11.bbclass b/meta/classes/qt4x11.bbclass
index abb1d9d..3704b48 100644
--- a/meta/classes/qt4x11.bbclass
+++ b/meta/classes/qt4x11.bbclass
@@ -6,4 +6,4 @@ QT_DIR_NAME = "qt4"
QT_LIBINFIX = ""
# Qt4 uses atomic instructions not supported in thumb mode
-ARM_INSTRUCTION_SET = "arm"
+TUNE_FEATURES := "${@oe_filter_out('thumb', '${TUNE_FEATURES}', d)}"
diff --git a/meta/conf/machine/include/tune-thumb.inc
b/meta/conf/machine/include/tune-thumb.inc
deleted file mode 100644
index 9f6ce95..000
--- a/meta/conf/machine/include/tune-thumb.inc
+++ /dev/null
@@ -1,32 +0,0 @@
-#tune file for thumb instructions
-
-ARM_INSTRUCTION_SET ?= "arm"
-# "arm" "thumb"
-#The instruction set the compiler should use when generating application
-#code. The kernel is always compiled with arm code at present. arm code
-#is the original 32 bit ARM instruction set, thumb code is the 16 bit
-#encoded RISC sub-set. Thumb code is smaller (maybe 70% of the ARM size)
-#but requires more instructions (140% for 70% smaller code) so may be
-#slower.
-
-THUMB_INTERWORK ?= "yes"
-# "yes" "no"
-#Whether to compile with code to allow interworking between the two
-#instruction sets. This allows thumb code to be executed on a primarily
-#arm system and vice versa. It is strongly recommended that DISTROs not
-#turn this off - the actual cost is very small.
-
-OVERRIDE_THUMB = "${@['', ':thumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d,
1) == 'thumb']}"
-OVERRIDE_INTERWORK = "${@['',
':thumb-interwork'][bb.data.getVar('THUMB_INTERWORK', d, 1) == 'yes']}"
-OVERRIDES .= "${OVERRIDE_THUMB}${OVERRIDE_INTERWORK}"
-
-#Compiler and linker options for application code and kernel code. These
-#options ensure that the compiler has the correct settings for the selected
-#instruction set and interworking.
-ARM_INTERWORK_M_OPT = "${@['-mno-thumb-interwork',
'-mthumb-interwork'][bb.data.getVar('THUMB_INTERWORK', d, 1) == 'yes']}"
-ARM_THUMB_M_OPT = "${@['-mno-thumb',
'-mthumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1) == 'thumb']}"
-
-#
-TUNE_CCARGS += "${ARM_INTERWORK_M_OPT} ${ARM_THUMB_M_OPT}"
-TARGET_CC_KERNEL_ARCH += "-mno-thumb-interwork -mno-thumb"
-
diff --git a/meta/recipes-core/eglibc/eglibc.inc
b/meta/recipes-core/eglibc/eglibc.inc
index 1b2e630..2adcd05 100644
--- a/meta/recipes-core/eglibc/eglibc.inc
+++ b/meta/recipes-core/eglibc/eglibc.inc
@@ -33,8 +33,6 @@ LEAD_SONAME = "libc.so"
GLIBC_EXTRA_OECONF ?= ""
INHIBIT_DEFAULT_DEPS = "1"
-ARM_INSTRUCTION_SET = "arm"
-
# eglibc uses PARALLELMFLAGS variable to pass parallel build info so transfer
# PARALLEL_MAKE into PARALLELMFLAGS and empty out PARALLEL_MAKE
EGLIBCPARALLELISM := "PARALLELMFLAGS="${PARALLEL_MAKE}""
@@ -48,3 +46,5 @@ do_configure_prepend() {
sed -e "s#@BASH@#/bin/sh#" -i ${S}/elf/ldd.bash
[OE-core] [RFC BUG #1236 0/2] Modify ldd script for multilib.
This is part of the BUG #1236 fixing. Current there seems no way to get the dynamic loader(ld.so) names for all the ABIs configured in the multilib configuration during runtime. So we put the ld.so names in the dictionary "ld_info_all" in the file eglibc-ld.inc. This dictionary is indexed by the TUNENAME. To support a new ABI, new entry should be added into this dictionary along with the new ABI's TUNENAME. The information in ld_info_all can be used for both ldd script, and the KNOWN_INTERPRETER_NAMES in the file ldconfig.h (which has not been done yet). 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 llub/bug1236 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=llu/1236 Lianhao Lu (2): utils.bbclass/multilib.conf: Added misc supporting functions. eglibc: Modify ldd script according to multilib config. meta/classes/utils.bbclass | 35 meta/conf/bitbake.conf |1 + meta/conf/multilib.conf |6 +++- meta/recipes-core/eglibc/eglibc-ld.inc | 53 +++ meta/recipes-core/eglibc/eglibc.inc |1 + meta/recipes-core/eglibc/eglibc_2.13.bb |6 +++- 6 files changed, 100 insertions(+), 2 deletions(-) create mode 100644 meta/recipes-core/eglibc/eglibc-ld.inc ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC BUG #1236 2/2] eglibc: Modify ldd script according to multilib config.
Part fix of [BUGID #1236].
1. Collect all the values for RTLDLIST for the current multilib
configuration to modify the ldd scripts.
2. Collect all the values for KNOWN_INTERPRETER_NAMES for the current
multilib configuration.
Signed-off-by: Lianhao Lu
---
meta/recipes-core/eglibc/eglibc-ld.inc | 53 +++
meta/recipes-core/eglibc/eglibc.inc |1 +
meta/recipes-core/eglibc/eglibc_2.13.bb |6 +++-
3 files changed, 59 insertions(+), 1 deletions(-)
create mode 100644 meta/recipes-core/eglibc/eglibc-ld.inc
diff --git a/meta/recipes-core/eglibc/eglibc-ld.inc
b/meta/recipes-core/eglibc/eglibc-ld.inc
new file mode 100644
index 000..ad60964
--- /dev/null
+++ b/meta/recipes-core/eglibc/eglibc-ld.inc
@@ -0,0 +1,53 @@
+def ld_append_if_tune_exists(d, infos, dict):
+ tune = d.getVar("DEFAULTTUNE", True) or ""
+ libdir = d.getVar("base_libdir", True) or ""
+ if dict.has_key(tune):
+ infos['ldconfig'].add('{ "' + libdir + '/' + dict[tune][0] +
'",' + dict[tune][1] + ' }')
+ infos['lddrewrite'].add(libdir+'/'+dict[tune][0])
+
+def eglibc_dl_info(d):
+ ld_info_all = {
+ "mips": ["ld.so.1", "FLAG_ELF_LIBC6"],
+ "mips64-n32": ["ld.so.1", "FLAG_ELF_LIBC6"],
+ "mips64": ["ld.so.1", "FLAG_ELF_LIBC6"],
+ "mipsel": ["ld.so.1", "FLAG_ELF_LIBC6"],
+ "mips64el-n32": ["ld.so.1", "FLAG_ELF_LIBC6"],
+ "mips64el": ["ld.so.1", "FLAG_ELF_LIBC6"],
+ "mips-nf": ["ld.so.1", "FLAG_ELF_LIBC6"],
+ "mips64-nf-n32": ["ld.so.1", "FLAG_ELF_LIBC6"],
+ "mips64-nf": ["ld.so.1", "FLAG_ELF_LIBC6"],
+ "mips64el-nf-n32": ["ld.so.1", "FLAG_ELF_LIBC6"],
+ "mips64el-nf": ["ld.so.1", "FLAG_ELF_LIBC6"],
+ "powerpc": ["ld.so.1", "FLAG_ELF_LIBC6"],
+ "powerpc-nf": ["ld.so.1", "FLAG_ELF_LIBC6"],
+ "powerpc64": ["ld64.so.1", "FLAG_ELF_LIBC6"],
+ "powerpc64-nf": ["ld64.so.1", "FLAG_ELF_LIBC6"],
+ "core2": ["ld-linux.so.2", "FLAG_ELF_LIBC6"],
+ "core2-64": ["ld-linux-x86-64.so.2", "FLAG_ELF_LIBC6"],
+ "x86": ["ld-linux.so.2", "FLAG_ELF_LIBC5"],
+ "x86-64": ["ld-linux-x86-64.so.2", "FLAG_ELF_LIBC6"],
+ "i586": ["ld-linux.so.2", "FLAG_ELF_LIBC6"],
+ }
+
+ infos = {'ldconfig':set(), 'lddrewrite':set()}
+ ld_append_if_tune_exists(d, infos, ld_info_all)
+ variants = d.getVar("MULTILIB_VARIANTS", True) or ""
+ for item in variants.split():
+ localdata = bb.data.createCopy(d)
+ #Fix ME. OVERRIDES not work, we have to set DEFAULTTUNE to
TUNENAME
+ #overrides = localdata.getVar("OVERRIDES", False) +
":virtclass-multilib-" + item
+ #localdata.setVar("OVERRIDES", overrides)
+ if localdata.getVar("BBEXTENDVARIANT", True) == item:
+ tunename=localdata.getVar("TUNENAME", False) or ""
+ else:
+
tunename=localdata.getVar("TUNENAME_virtclass-multilib-" + item, False) or ""
+ if tunename != "":
+ localdata.setVar("DEFAULTTUNE", tunename)
+ ld_append_if_tune_exists(localdata, infos, ld_info_all)
+
+ infos['ldconfig'] = ' '.join(infos['ldconfig'])
+ infos['lddrewrite'] = ' '.join(infos['lddrewrite'])
+ return infos
+
+ALL_KNOWN_INTERPRETER_NAMES = "${@eglibc_dl_info(d)['ldconfig']}"
+RTLDLIST = "${@eglibc_dl_info(d)['lddrewrite']}"
diff --git a/meta/recipes-core/eglibc/eglibc.inc
b/meta/recipes-core/eglibc/eglibc.inc
index 1b2e630..0ed4359 100644
--- a/meta/recipes-core/eglibc/eglibc.inc
+++ b/meta/recipes-core/eglibc/eglibc.inc
@@ -1,4 +1,5 @@
require eglibc-common.inc
+require eglibc-ld.inc
STAGINGCC = "gcc-cross-intermediate"
STAGINGCC_virtclass-nativesdk = "gcc-crosssdk-intermediate"
diff --git a/meta/recipes-core/eglibc/eglibc_2.13.bb
b/meta/recipes-core/eglibc/eglibc_2.13.bb
index 41fe7c7..b1bfbf1 100644
--- a/meta/recipes-core/eglibc/eglibc_2.13.bb
+++ b/meta/recipes-core/eglibc/eglibc_2.13.bb
@@ -3,7 +3,7 @@ require eglibc.inc
SRCREV = "14157"
DEPENDS += "gperf-native"
-PR = "r9"
+PR = "r10"
PR_append = "+svnr${SRCPV}"
EGLIBC_BRANCH="eglibc-2_13"
@@ -199,6 +199,10 @@ do_compile () {
rpcgen -h $r -o $h || oewarn "unable to generate header
for $r"
done
)
+
+ echo "Adjust dynamic loader list to ${EGLIBC_DYNAMIC_LOADERS}"
+ [ -z "${RTLDLIST}" ] && return
+ sed -i ${B}/elf/ldd -e 's#^\(RTLDLIST=\).*$#\1"${RTLDLIST}"#'
}
require eglibc-package.inc
--
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] [RFC BUG #1236 1/2] utils.bbclass/multilib.conf: Added misc supporting functions.
1. Added variable MULTILIB_VARIANTS to store all the instance variants
for multilib extend.
2. Added function all_multilib_tune_values to collect the variable
values for all multilib instance.
Signed-off-by: Lianhao Lu
---
meta/classes/utils.bbclass | 35 +++
meta/conf/bitbake.conf |1 +
meta/conf/multilib.conf|6 +-
3 files changed, 41 insertions(+), 1 deletions(-)
diff --git a/meta/classes/utils.bbclass b/meta/classes/utils.bbclass
index 8c3a9b8..f8adaea 100644
--- a/meta/classes/utils.bbclass
+++ b/meta/classes/utils.bbclass
@@ -341,3 +341,38 @@ def base_set_filespath(path, d):
for o in overrides.split(":"):
filespath.append(os.path.join(p, o))
return ":".join(filespath)
+
+def extend_variants(d, var, extend, delim=':'):
+ """Return a string of all bb class extend variants for the given
extend"""
+ variants = []
+ whole = d.getVar(var, True) or ""
+ for ext in whole.split():
+ eext = ext.split(delim)
+ if len(eext) > 1 and eext[0] == extend:
+ variants.append(eext[1])
+ return " ".join(variants)
+
+def all_multilib_tune_values(d, var, unique=True):
+ """Return a string of all ${var} in all multilib tune configuration"""
+ values = []
+ value = d.getVar(var, True) or ""
+ if value != "":
+ values.append(value)
+ variants = d.getVar("MULTILIB_VARIANTS", True) or ""
+ for item in variants.split():
+ localdata = bb.data.createCopy(d)
+ #Fix ME. OVERRIDES not work, we have to set DEFAULTTUNE to
TUNENAME
+ #overrides = localdata.getVar("OVERRIDES", False) +
":virtclass-multilib-" + item
+ #localdata.setVar("OVERRIDES", overrides)
+ if localdata.getVar("BBEXTENDVARIANT", True) == item:
+ tunename=localdata.getVar("TUNENAME", False) or ""
+ else:
+
tunename=localdata.getVar("TUNENAME_virtclass-multilib-" + item, False) or ""
+ if tunename != "":
+ localdata.setVar("DEFAULTTUNE", tunename)
+ value = localdata.getVar(var, True) or ""
+ if value != "":
+ values.append(value)
+ if unique:
+ values = set(values)
+ return " ".join(values)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 6e109ec..bcff50e 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -736,3 +736,4 @@ BB_HASHTASK_WHITELIST ?=
"(.*-cross$|.*-native$|.*-cross-initial$|.*-cross-inter
BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR
SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL TERM USER
FILESPATH USERNAME STAGING_DIR_HOST STAGING_DIR_TARGET COREBASE"
MLPREFIX ??= ""
+MULTILIB_VARIANTS ??= ""
diff --git a/meta/conf/multilib.conf b/meta/conf/multilib.conf
index 894b7a5..60760df 100644
--- a/meta/conf/multilib.conf
+++ b/meta/conf/multilib.conf
@@ -1,6 +1,11 @@
baselib = "${@d.getVar('BASE_LIB_tune-' + (d.getVar('DEFAULTTUNE', True) or
'INVALID'), True) or 'lib'}"
+MULTILIB_VARIANTS = "${@extend_variants(d,'MULTILIBS','multilib')}"
+
+TUNENAME_virtclass-multilib-lib64 ?= "x86-64"
+TUNENAME_virtclass-multilib-lib32 ?= "x86"
+
MULTILIBS ??= "multilib:lib32"
BBCLASSEXTEND_append_pn-linux-libc-headers = " ${MULTILIBS}"
BBCLASSEXTEND_append_pn-eglibc-initial = " ${MULTILIBS}"
@@ -21,4 +26,3 @@ BBCLASSEXTEND_append_pn-bash = " ${MULTILIBS}"
BBCLASSEXTEND_append_pn-ncurses = " ${MULTILIBS}"
BBCLASSEXTEND_append_pn-expat = " ${MULTILIBS}"
BBCLASSEXTEND_append_pn-eglibc-locale = " ${MULTILIBS}"
-
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] sanity.bbclass: Add sanity check that TUNE_PKGARCH appears in PACKAGE_ARCHS
On Jul 28, 2011, at 10:07 PM, Saul Wold wrote:
> On 07/28/2011 06:57 PM, Kumar Gala wrote:
>>
>> On Jul 28, 2011, at 7:41 PM, Saul Wold wrote:
>>
>>> On 07/28/2011 05:07 PM, Kumar Gala wrote:
Its possible we get duplications if we explicity add TUNE_PKGARCH to
PACKAGE_ARCHS so instead just add a sanity check to verify it.
Signed-off-by: Kumar Gala
---
meta/classes/sanity.bbclass | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index b054146..999e15d 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -375,8 +375,10 @@ def check_sanity(e):
elif oeroot.find (' ') != -1:
messages = messages + "Error, you have a space in your COREBASE
directory path. Please move the installation to a directory which doesn't
include a space."
-# Check that we don't have duplicate entries in PACKAGE_ARCHS
+# Check that we don't have duplicate entries in PACKAGE_ARCHS& that
TUNE_PKGARCH is in PACKAGE_ARCHS
pkgarchs = data.getVar('PACKAGE_ARCHS', e.data, True)
+tunepkg = data.getVar('TUNE_PKGARCH', e.data, True)
+tunefound = False
seen = {}
dups = []
@@ -385,9 +387,15 @@ def check_sanity(e):
dups.append(pa)
else:
seen[pa] = 1
+ if pa == tunepkg:
+ tunefound = True
+
if len(dups):
messages = messages + "Error, the PACKAGE_ARCHS variable contains
duplicates. The following archs are listed more than once: %s" % "
".join(dups)
>>> Kumar,
>>>
>>> Thanks for the patch, some questions.
>>>
>>> Is this correct, do you still want to report the error, if there is a dup?
>>>
>>> Would it not just be better to just drop the dup if it is the TUNE_PKGARCH?
>>
>> I wasn't sure how to drop the dup. :)
>>
>> If there is a way to uniq PACKAGE_ARCHS that would be fine
>>
> Would this be what your looking for, it "uniq"s only the tunepkg value.
>
> - if seen.get(pa, 0) == 1:
> + if pa == tunepkg:
> + tunefound = True
> +if seen.get(pa, 0) == 1:
> +pkgarchs.remove(pa)
> + elif seen.get(pa, 0) == 1:
>dups.append(pa)
>else:
>seen[pa] = 1
> - if pa == tunepkg:
> - tunefound = True
No, I don't thing that's right. TUNE_PKGARCH is a singleton. The other check
was to make sure that we didn't have ANY duplicates in PACKAGE_ARCHS. I think
that is still valid as the code stands.
- k
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] arm tune files status summary
There are quite a lot of different sub-threads going on at the moment
regarding the various breakages associated with the recent arm tuning
file patch. Here's a summary of what I think are all the current issues
and their status.
1. bogus PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} in bitbake.conf causing
rootfs construction to fail.
Paul and Koen both posted (essentially identical) patches for this and
it looks as though Paul's has been applied. So, the original breakage
should be resolved but it isn't entirely clear what this line in
bitbake.conf was trying to accomplish in the first place. I think
someone still needs to conduct an audit to establish whether there are
any circumstances where PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} does
need setting to ${TARGET_ARCH} and, if so, make that happen.
2. endianness confusion in armv5/armv6 tune files.
I posted a patch for this. It doesn't look like it's been applied yet
but it's in the archives for anybody who wants it. Only big-endian
configs would be affected anyway and I think those are something of a
fringe pursuit.
3. eglibc unbuildable on qemuarm
This is happening because qemuarm selects arm926ejs tuning, which in
turn selects armv5te, and the current arrangement of tune files forces
Thumb-state on if you ask to tune for a T-variant architecture. The old
"ARM_INSTRUCTION_SET" variable which used to override the ISA selection
seems not to be respected anymore. This is unfortunate because there is
assembler code in eglibc which isn't Thumb-1 aware and hence can't be
built under -mthumb.
A short-term workaround would be to hack tune-arm926ejs.inc to select
the TUNE_FEATURES for armv5e rather than armv5te. But this is clearly
not a good solution in general and, other than changing the underlying
policy of inferring ISA choice from architecture name, it's not obvious
what the right way of solving it is.
This particular issue causes sufficiently gross breakage that I would
have expected it to show up on the Yocto autobuilder run before the
patch was merged. I'm not quite sure why it apparently didn't fail
there but maybe the autobuilder doesn't actually test qemuarm at
present.
4. can't build ARM-state code for ARMv4T architecture.
This is another facet of the above; there is currently no way to say
that you want to select -march=armv4t without also enabling -mthumb.
This makes it impossible to build interworking-capable ARM-state code
for v4T.
5. cortex tuning not working
Various of the cortex files had a spelling mistake which would cause the
TUNE_FEATURES never to actually match anything. This is a trivial fix
and I sent a patch for it yesterday. I don't think it's been merged
yet.
6. distros no longer able to select ARM vs Thumb state either globally
or per package
This is really another manifestation of the issue in #3. But the point
here isn't so much that builds are failing, rather that we seem to have
lost the ability to have a single switch that the DISTRO can flip to
build the entire world (or individual packages) as Thumb rather than
ARM. For Thumb-1 in particular the tradeoffs are sufficiently
complicated that I don't think there is ever going to be a globally
"right" answer.
I think that's all I know of.
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/3] Add ARM tune file overhaul based largely on work from Mark Hatle
Op 29 jul. 2011 om 09:25 heeft Phil Blundell het volgende geschreven: > On Thu, 2011-07-28 at 22:59 -0700, Khem Raj wrote: >> here I guess we have to say AVAILTUNES += "arm920t arm920" >> where arm920 is arm mode and 920t is thumb mode. but anyway I would >> prefer that thumb is optionally added provided user asked for it >> through DISTRO/MACHINE features then we should first make sure >> that selected machine has thumb feature and if yes for both then we >> should enable -mthumb compiler option which now it enable when thumb >> appears in TUNE_FEATURES > > I don't think we want to go down the road of inventing CPU names for > ARM-state variants of Thumb-capable cores. (In other words, we > shouldn't start putting things like "arm920" in AVAILTUNES when there > isn't actually a core named arm920.) > > Fundamentally I think you're right that the choice between ARM-state and > Thumb-state (for t1 at least) ought to be under the control of the > DISTRO and not selected purely on the basis of the hardware > capabilities. For t2 it is a bit less of a clear-cut issue but, if > there are genuinely people making ARMv7 cores with the Thumb decoder > removed, I guess we need to have that same switch there as well Another issue is silicon bugs on early a8 revisions, but gcc and linux might have enough workarounds nowadays > > 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] eglibc: unify eglibc-utils/${PN}-utils and remove PACKAGES from eglibc.inc
On Fri, Jul 29, 2011 at 09:17:31AM +0200, Martin Jansa wrote:
> * PACKAGES were defined in eglibc.inc as well as eglibc-package.inc,
> definition
> from eglibc.inc was overriden from recipes including eglibc.inc only
> * 37ff0fea8f7180b1a9d91d24dfe1735730427497 changed RPROVIDES_eglibc-utils,
> but ie FILES_ were still using eglibc-utils instead of ${PN}-utils, unify
> all eglibc-utils
BTW: there is still problem with ie
RPROVIDES_${PN}-utils = "glibc-utils"
leading to
ERROR: Trying to resolve runtime dependency glibc-utils resulted in conflicting
PREFERRED_PROVIDER entries being found.
The providers found were:
['virtual:nativesdk:/OE/shr-core/openembedded-core/meta/recipes-core/eglibc/eglibc_2.13.bb',
'/OE/shr-core/openembedded-core/meta/recipes-core/eglibc/eglibc_2.13.bb']
The PREFERRED_PROVIDER entries resulting in this conflict were:
['PREFERRED_PROVIDER_virtual/libc-nativesdk = eglibc-nativesdk',
'PREFERRED_PROVIDER_virtual/libc = eglibc']
NOTE: multiple providers are available for runtime glibc-utils (eglibc,
eglibc-nativesdk, external-csl-toolchain, external-poky-toolchain)
NOTE: consider defining a PREFERRED_PROVIDER entry to match glibc-utils
now with glibc recipes removed, do we need to RPROVIDE this or can we fix
recipes
RDEPENDing on glibc-utils to use eglibc-utils directly?
otherwise we should fix right side to use ${PN/eglibc/glibc} to keep
eglibc-nativesdk from providing glibc-utils (glibc-nativesdk-utils only).
Regards,
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
On Thu, 2011-07-28 at 22:59 -0700, Khem Raj wrote: > here I guess we have to say AVAILTUNES += "arm920t arm920" > where arm920 is arm mode and 920t is thumb mode. but anyway I would > prefer that thumb is optionally added provided user asked for it > through DISTRO/MACHINE features then we should first make sure > that selected machine has thumb feature and if yes for both then we > should enable -mthumb compiler option which now it enable when thumb > appears in TUNE_FEATURES I don't think we want to go down the road of inventing CPU names for ARM-state variants of Thumb-capable cores. (In other words, we shouldn't start putting things like "arm920" in AVAILTUNES when there isn't actually a core named arm920.) Fundamentally I think you're right that the choice between ARM-state and Thumb-state (for t1 at least) ought to be under the control of the DISTRO and not selected purely on the basis of the hardware capabilities. For t2 it is a bit less of a clear-cut issue but, if there are genuinely people making ARMv7 cores with the Thumb decoder removed, I guess we need to have that same switch there as well. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] eglibc: unify eglibc-utils/${PN}-utils and remove PACKAGES from eglibc.inc
* PACKAGES were defined in eglibc.inc as well as eglibc-package.inc, definition
from eglibc.inc was overriden from recipes including eglibc.inc only
* 37ff0fea8f7180b1a9d91d24dfe1735730427497 changed RPROVIDES_eglibc-utils,
but ie FILES_ were still using eglibc-utils instead of ${PN}-utils, unify
all eglibc-utils
Signed-off-by: Martin Jansa
---
meta/recipes-core/eglibc/eglibc-package.inc |8
meta/recipes-core/eglibc/eglibc.inc |2 --
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/meta/recipes-core/eglibc/eglibc-package.inc
b/meta/recipes-core/eglibc/eglibc-package.inc
index 7646ea4..4de882e 100644
--- a/meta/recipes-core/eglibc/eglibc-package.inc
+++ b/meta/recipes-core/eglibc/eglibc-package.inc
@@ -65,11 +65,11 @@ FILES_libsotruss${PKGSUFFIX} =
"${libdir}/audit/sotruss-lib.so"
FILES_eglibc-dev_append += "${bindir}/rpcgen ${libdir}/*.a \
${base_libdir}/*.a ${base_libdir}/*.o ${datadir}/aclocal"
FILES_nscd${PKGSUFFIX} = "${sbindir}/nscd*"
-FILES_eglibc-utils = "${bindir}/* ${sbindir}/*"
+FILES_${PN}-utils = "${bindir}/* ${sbindir}/*"
FILES_${PN}-dbg += "${libexecdir}/*/.debug ${libdir}/audit/.debug"
FILES_catchsegv${PKGSUFFIX} = "${bindir}/catchsegv"
RDEPENDS_catchsegv${PKGSUFFIX} = "libsegfault"
-RDEPENDS_eglibc-utils += "bash"
+RDEPENDS_${PN}-utils += "bash"
FILES_eglibc-pcprofile = "${base_libdir}/libpcprofile.so"
FILES_eglibc-thread-db${PKGSUFFIX} = "${base_libdir}/libthread_db.so.*
${base_libdir}/libthread_db-*.so"
RPROVIDES_eglibc-dev += "libc-dev"
@@ -82,8 +82,8 @@ SUMMARY_eglibc-extra-nss = "hesiod, NIS and NIS+ nss
libraries"
DESCRIPTION_eglibc-extra-nss = "eglibc: nis, nisplus and hesiod search
services."
SUMMARY_ldd = "print shared library dependencies"
DESCRIPTION_ldd = "/usr/bin/ldd prints shared library dependencies for each
program or shared library specified on the command line."
-SUMMARY_eglibc-utils = "Miscellaneous utilities provided by eglibc"
-DESCRIPTION_eglibc-utils = "Miscellaneous utilities including getconf, iconf,
locale, gencat, tzselect, zic, rpcinfo, ..."
+SUMMARY_${PN}-utils = "Miscellaneous utilities provided by eglibc"
+DESCRIPTION_${PN}-utils = "Miscellaneous utilities including getconf, iconf,
locale, gencat, tzselect, zic, rpcinfo, ..."
DESCRIPTION_libsotruss = "Library to support sotruss which traces calls
through PLTs"
inherit libc-common multilib_header
diff --git a/meta/recipes-core/eglibc/eglibc.inc
b/meta/recipes-core/eglibc/eglibc.inc
index 1b2e630..0f97f82 100644
--- a/meta/recipes-core/eglibc/eglibc.inc
+++ b/meta/recipes-core/eglibc/eglibc.inc
@@ -41,8 +41,6 @@ EGLIBCPARALLELISM := "PARALLELMFLAGS="${PARALLEL_MAKE}""
EXTRA_OEMAKE += ${EGLIBCPARALLELISM}
PARALLEL_MAKE = ""
-PACKAGES = "glibc catchsegv sln nscd ldd glibc-utils glibc-dev glibc-doc
libsegfault glibc-extra-nss glibc-thread-db glibc-pcprofile"
-
OE_FEATURES = "${@features_to_eglibc_settings(d)}"
do_configure_prepend() {
sed -e "s#@BASH@#/bin/sh#" -i ${S}/elf/ldd.bash.in
--
1.7.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
On Thu, 2011-07-28 at 23:18 -0700, Khem Raj wrote: > On 07/27/2011 07:44 AM, Phil Blundell wrote: > cortex-m series supports only thumb2 intsruction set. I am not sure if > thumb2 alone is a superset of thumb1 iow thumb1 programs could be > executed on cortex-m series or not. Never had a cortex-m so I am not sure. Yes, I believe any thumb-1 program will run on a thumb-2 core. 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/3] Add ARM tune file overhaul based largely on work from Mark Hatle
On Thu, 2011-07-28 at 23:38 -0700, Khem Raj wrote: > On 07/27/2011 08:25 AM, Phil Blundell wrote: > > On Wed, 2011-07-27 at 09:58 -0500, Mark Hatle wrote: > >> For the tune names.. armv5 means I want classic ARM instructions, while > >> armv5t > >> means I was thumb instructions. > >> > >> So armv5 and armv5t are distinct in the contents of the tunings. > > > > Ah, I see. Does that go for v4t too? I can imagine cases where you > > would want to say "select the v4T ISA but generate ARM code not Thumb". > > > >> Yes, the mention of DSP should be using the 'e'. What I'm not sure of is > >> does > >> the "dsp" capabilities actually change any of the code or support > >> generated. If > >> not then we can ignore it. > > > > Yes. PLD, for example, is only available in ARMv5E (not ARMv5) and this > > will affect any code which uses __builtin_prefetch(). I don't think GCC > > will ever open-code the saturating arithmetic instructions, but it does > > expose the v5/v5e distinction through preprocessor macros and source > > code might use that to select asm() statements which use those opcodes. > > LDRD/STRD which are armv5e only are used by gcc IIRC Ah yes, you're right. Those too. 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] python-native: Fix a compiler finding issue
>-Original Message-
>From: openembedded-core-boun...@lists.openembedded.org
>[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
>Tom Rini
>Sent: Friday, July 29, 2011 9:44 AM
>To: openembedded-core@lists.openembedded.org
>Subject: Re: [OE-core] [PATCH 1/1] python-native: Fix a compiler finding issue
>
>On 07/28/2011 06:15 PM, Mei, Lei wrote:
>>
>>
>>> -Original Message-
>>> From: openembedded-core-boun...@lists.openembedded.org
>>> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
>Of
>>> Tom Rini
>>> Sent: Thursday, July 28, 2011 11:09 PM
>>> To: openembedded-core@lists.openembedded.org
>>> Subject: Re: [OE-core] [PATCH 1/1] python-native: Fix a compiler finding
>issue
>>>
>>> On 07/28/2011 12:20 AM, Mei Lei wrote:
The CC variable sometimes add option information after compiler name,
>but
>>> python can't get the real compiler name if those information added.
Fix this issue by dropping the option information when finding compiler
>name.
Signed-off-by: Mei Lei
>>>
>>> I think this is going to cause problems when you must pass flags to gcc
>>> to have it work, eg 'gcc -m64'.
>>
>> This patch fixed your worried issue.
>> The CC variable, sometimes like: "x86_64-poky-linux-gcc -m64
>--sysroot=/${TMPDIR}/sysroots/qemux86-64", contains flags information.
>> This will lead to wrong compiler name "qemux86-64" rather than
>"x86_64-poky-linux-gcc" when python finding the compiler name, so add this
>patch to find the real gcc name.
>
>No, what I'm saying is I have a compiler that must be invoked as 'gcc
>-m64' (which is what BUILD_CC is). So, I think after saying that, the
>right answer is to modify python to read the OE-specific BUILD_CC variable.
I think I didn't describe this patch exactly before.
This patch is only for function runtime_library_dir_option, this function is to
detect which platform we are running and what compiler we used, then decide
what option information should be passed to compiler.
By default, our cross-compiler's name be recognized as "qemux86" rather than "
x86_64-poky-linux-gcc" in this function, this is wrong, this will induce a
wrong option information passed to x86_64-poky-linux-gcc and block the compile
process.
And function runtime_library_dir_option only return the option information, so
didn't influence compiler name in global.
By the way, I think BUILD_CC is host compiler name, not for target.
Thanks
Lei
>
>--
>Tom Rini
>Mentor Graphics Corporation
>
>___
>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
