The previous commit to this file meant thumb was always being turned on
even when TUNE_FEATURES did not contain "thumb". This is clearly wrong
and this patch corrects this so thumb options are no longer specified
in that case.
(From OE-Core rev: 4b5e8074f8aca59b09421db464ce652e84f898f2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: 2c9bd779b008be266072f3c6d79430f63ec02241)
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is comming from x32 need to pass special parameters to ld & as.
(From OE-Core rev: 96931af89f9cc3056e413cff437a85eca85b3b75)
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need to ensure only one value ends up in TUNE_PKGARCH rather than several.
This change ensures consistency accross all the PPC tune files and that they
correctly inherit the core value but also allow it to be overwritten.
(From OE-Core rev: f9a8b719dd3fc7593a509c8f288caf1486add2f8)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add SDK_PACKAGE_ARCHS to avoid the sed operations we were previously doing
inside of the variouns populate_sdk functions and related items.
Also add documentation to populate_sdk to explain when the various functions
are expected to be doing.
Finally fix a bug in populate_sdk_rpm where the wrong value was being set,
noticed while working on this change.
(From OE-Core rev: 587c1d5bac71fa6faa65ee3a271391cbf931e8f7)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
All 64-bit PPC processors support hard-float so no need to support
soft-float.
(From OE-Core rev: 54c7d1faf5376c8fb9b19f4e192ce959c8442782)
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When figuring out how to set TUNE_CCARGS we should look for 'm64' not
'n64' in TUNE_FEATURES.
(From OE-Core rev: 7a9ea28e69e8121a559f610dd2330edd33f0a907)
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Glibc 2.10.1 is outdated now and eglibc seems to provide a superset of
its functionality.
(From OE-Core rev: 1d9866a2c4fe93202749a56c7ad89a3cbd07d9f8)
Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
PACKAGE_EXTRA_ARCHS_tune-armv5eb needs to be defined in terms of
the non-e with the same endianness, i.e. PACKAGE_EXTRA_ARCHS_tune-armv5b
not PACKAGE_EXTRA_ARCHS_tune-armv5, otherwise PACKAGE_EXTRA_ARCHS will
end up containing a semi-random mixture of endiannesses and disaster
will ensue. Likewise for the vfp and armv6 variants.
This is all a bit confusing because TUNE_FEATURES is done the opposite
way around, i.e. TUNE_FEATURES_tune-armv5eb is derived by taking the
armv5e version and adding bigendian. But fixing that is probably
a subject for a separate patch.
(From OE-Core rev: 391c0102a81455c76244d13b6878e3a76cca65dc)
Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Otherwise the test in TUNE_CCARGS will never match.
(From OE-Core rev: 3b7784021259ac745c80043bec16189fa8f4e45e)
Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Because of the way BitBake handles ??= under certain circumstances, this
default setting ends up stepping all over the real setting from the arch
include file. Since virtually all arch include files or tune files define
a real value for this we shouldn't need to have a default (or it needs to
be done in a different way).
(From OE-Core rev: 6c43ca6fc6a7fffc84cf28684cac0c0eb4129902)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Acked-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch adds the core multilib class which can be used along with a
parameter specifying the mutlilib to use in BBCLASSEXTEND.
The MLPREFIX variable is added and can be used in cases where its too
difficult to dynmaically work out where a mutltilib prefix is needed
to be added to a variable.
This includes:
* SHLIBSDIR and PACKAGE_ARCH fixes from Lianhao Lu.
* PACKAGE_DYNAMIC mapping from Yu Ke
* PACKAGE_INSTALL mapping from Yu Ke
* RPROVIDES mapping from Yu Ke
* TARGET_VENDOR fix from Mark Hatle
* Ignorning *-native-runtime dependnecies as well as *-native from Yu Ke
* Map PKG and ALLOW_EMPTY from Dongxiao Xu
* Ensure RCONFLICTS and PKG field dependencies are remapped (from Dongxiao Xu)
* Ensure PN and MLPREFIX are set at the same time to ensure consistent BPN values (Yu Ke)
(From OE-Core rev: 5d9453049915db48ec4b5972e12287417ebb61a2)
Signed-off-by: Yu Ke <ke.yu@intel.com>
Signed-off-by: Xu Dongxiao <dongxiao.xu@intel.com>
Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The introduction of the linux-yocto-3.0 kernel is taking
precedence over the known working 2.6.37 version. Forcing
2.6.37 until 3.0 is validated on the qemu machines.
(From OE-Core rev: 77a41ab5ca92606ee08f002a8dfc631f642a3179)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using i686 doesn't work well with locale generation and doesn't gain anything
so revert to the i586 default.
(From OE-Core rev: 79b7b1aab5d3d002bfa7a49887d5d834c29eae45)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The current approach causes duplicate values to appear in the TUNE_ARCH
field and this patch addresses that.
(From OE-Core rev: 02031d766f983cd7e01e468cb2c926604313cd2a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is this discrepency in spelling. Lets fix it in
core. There are lot of layers using SITEINFO_ENDIANNESS
This was shielded since meta-oe had its own copy of
siteinfo class. But that class has now been deleted in
favor of oe-core
(From OE-Core rev: 54a54778fad39931ac7d43daaf37ce7c1946a29b)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These changes revolve around the idea of tune features. These are represented by
'flag' strings that are included in the TUNE_FEATURES variable.
Any string included in TUNE_FEATURES should also add a TUNEVALID[<name>] entry so
we can know which flags are available in TUNE_FEATURES and have documentation about
what the flags do. We will add sanity code to error if flags are listed in
TUNE_FEATURES but are not documented in TUNEVALID.
A given tune configuration will want to define one or more predetermined sets of
_FEATURE flag lists. These are defined in the form TUNE_FEATURES_tune-<name>.
For defined tune configuation, <name> should be added to the AVAILTUNE list so that
we can determine what tune configurations are available. Flags cannot be used in this
case as with TUNEVALID since its useful to be able to build up tune lists from other
TUNE_FEATURES_tune-yyy options.
A given tune configuration may also define PACKAGE_EXTRA_ARCHS_tune-<name> and
BASE_LIB_tune-<name> to control the multilib location. All options can be overridden
by the distro or local user configuration.
(From OE-Core rev: 5f9d56bd64997b93ed7e46c117851002a0556654)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch removes the variables BASE_PACKAGE_ARCH, BASEPKG_HOST_SYS,
BASEPKG_TARGET_SYS and also removes the immediate assignments in
several core classes as these are no longer required.
This should make it clearer what some of the core variables do and
simplfy some overly complex and confusing class code.
(From OE-Core rev: d5521be2dcbaf213c140b0d12a4176380874426b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since we're updating the tune file format, it makes sense to abstract
the compiler tune arguments at this point too. This means that should
these need to be overridden at any point, the original values can
still be obtained in a similar manner to the other TUNE* variables.
Whilst this isn't strictly necessary for any current need, its likely
good practise to standardise this behaviour.
(From OE-Core rev: 3a3c69a1bc3cf0b6f6a3b13d86c12ed21798d48e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is currently consideradble confusion over how the tune files operate
and how these interact with the rest of the build system. This update/overhaul
changes things so the tune files are primarily resonsible for setting:
TUNE_ARCH - What was formerly set as TARGET_ARCH and is the value that
represents the architecture we're targetting.
TUNE_PKGARCH - The value that represents the tune confuration that this set
of tune parameters results in.
This allows the significant improvement that the core can now always determine
the target architecture value, even when TARGET_ARCH needs to be reset to
something different and likewise, there is one package architecture variable
the core can reference allowing simplification of the BASE_PACKAGE_ARCH, PACKAGE_ARCH
and FEED_ARCH variables.
(From OE-Core rev: a10de4cf8b424ee95c8e283e75d486be5b3b8eac)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add the ability to dynamically change the library directory from "lib" to
other values. This allows the tune files to specifiy altnerative ABIs
which can be dynamically enabled by the multilib BBCLASSEXTEND code.
A variety of approaches have been attempted with this, the immediate
expansions in cross.bbclass being problematic as they are they are expanded
before the bbclass extend event hander runs. This approach ensures the
${baselib} variable is retained in the expressions resolving that complication.
Derived from some ideas from Mark Hatle.
(From OE-Core rev: aeea22da699b276a97ca1a17e3c53176c9afd9de)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
1a9ae8ea8c0540d41b8ff4d95c0420d6df754634 removed -uclibc
hence it got all wrong for powerpc. uclibc TARGET_OS
for classic ppc is linux-uclibc and for ppc w/ SPE its
linux-uclibcspe
(From OE-Core rev: 6c4ddd2d532ea91cd5752a7e56e8487cca1ac1e3)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is needed for packages that go into core-image-minimal
and core-image-sato highlighted by uclibc
(From OE-Core rev: ab9543d48262a75f87621fc2b64dcb8ab8caf0bf)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We have no hg URIs in the metadata, so don't require and don't
ASSUME_PROVIDED it either. meta-oe has a mercurial-native recipe
if hg URIs are added in a recipe later.
(From OE-Core rev: 6473c9096bf4995c21147e737322d800219c89ab)
Signed-off-by: Tom Rini <tom_rini@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Its possible that BASE_PACKAGE_ARCH isn't set to ppce500 or ppce500v2 when
we build native toolchains. So we can utilize TARGET_FPU being set to
'ppc-efd' or 'ppc-efs' to determine if we should enable the gnuspe ABI.
(From OE-Core rev: 1a9ae8ea8c0540d41b8ff4d95c0420d6df754634)
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Its better to use xterm since some folks may not be using gnome
or KDE. Chances of having xterm on build machines are lot more
than having gnome-terminal.
(From OE-Core rev: 6ba0dc5b075ab63d6c16fcb45928336a919cf070)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The upstream package tracking webapp needs this additional distro
tracking field to work properly for the following recipes I
maintain:
* icu
* blktool
* apmd
* gperf
* dosfstools
* insserv
* at
(From OE-Core rev: aada3127a425f8f35c834f2d96f3737fd62df9c0)
Signed-off-by: Scott Garman <scott.a.garman@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since we no longer support 2.4, update this setting to 2.6.16, to line up
with the most accepted setting from OE. (This affects eglibc's kernel
support, and 2.6.16 is the minimum version for glibc 2.9 onwards.)
(From OE-Core rev: 888ab93fb8a5baf6308bdc004dba721b0950f6ab)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since the change in busybox configuration to match OE (OE core rev
b5564c4a9cadf306b447180c433b25ec071f8ce1) we now need ipv4 in
DISTRO_FEATURES to get standard IPv4 functionality in busybox.
(From OE-Core rev: 74bb505de16292ea278106c8575f955dfdc3141e)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
