fix the MLPREFIX referrence typo which cause multilib rpm
do_rootfs failure
CC: Mark Hatle <mark.hatle@windriver.com>
(From OE-Core rev: 9653089620ad5aef7876b582708561c3a315a064)
Signed-off-by: Yu Ke <ke.yu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Earlier iterations of the multilib patch used "TUNENAME", which was later
renamed to DEFAULTTUNE. This file was missed in the rename.
(From OE-Core rev: fdd39925df8268ad41c1ff643a0761b03fad8e08)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Its possible we get duplications if we explicity add TUNE_PKGARCH to
PACKAGE_ARCHS so instead just add a sanity check to verify it.
(From OE-Core rev: b2ae0444eb1984b86c02e571bb1efeaacdeafcf1)
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
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>
This reads the sgml-docbook.bak and adds the entries into sgml-docbook.cat since
this occurs out of order during shared state sysroot populate.
(From OE-Core rev: 87d68520c190007869ed1877fbb40eef23763524)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch writes a sgml-docbook.bak that is read by the sgml-common during a shared
state sysroot populate, because it comes out of order.
(From OE-Core rev: b372198fe3c9d8be18bd15545fb0bc4dd9d5aa68)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch writes a sgml-docbook.bak that is read by the sgml-common during a shared
state sysroot populate, because it comes out of order.
(From OE-Core rev: 4d4047c7b997a9cee96f170c203315cbd82ff084)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch writes a sgml-docbook.bak that is read by the sgml-common during a shared
state sysroot populate, because it comes out of order.
(From OE-Core rev: 457f30a389031947f037bd7ea1217c190c2089c1)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The do_archgen step creates a script that utilizes the variable name
${ARCH}. However, we also utilize and define ${ARCH} so instead of
having the following in the script:
COMPAT_WITH="${ARCH},${COMPAT} $COMPAT_WITH"
We get something like:
COMPAT_WITH="powerpc,${COMPAT} $COMPAT_WITH"
Just renaming the variable in the script to not conflict with ${ARCH}
fixes the issue.
[PR bump from Saul Wold]
(From OE-Core rev: 09573a276456122b408c5bcebc537455fd1c5f29)
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
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>
Fixed [BUGID #1299]. OLD_MULTIMACH_TARGET_SYS is no longer available.
Use new recipe-scope variable REAL_MULTIMACH_TARGET_SYS instead.
(From OE-Core rev: b69a2be2f30dc633597399d42d6c87d9f0910c1a)
Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
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>
ghostscript fails some time on autobuilder, it seems a parallel build issue.
Add patch to fix it.
Fixes [Yocto #1202]
(From OE-Core rev: 90c0eabcce04e8358ce8df9cd9ed60fdeea68cf5)
Signed-off-by: Kang Kai <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This makes debugging the new tune code easier since it doesn't involve staring at 'bitbake -e' output anymore.
(From OE-Core rev: c1903b1221e9b419aefe49e40a8acd61575de797)
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
connman plugins have dependency on bluez4, wpa-supplicant, and ofono.
These names are hardcoded, fix the issue to support multilib.
(From OE-Core rev: a27503dc76652afef6eaf7330c8e6a421d72a6fc)
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Support install multiple multilib in opkg backend.
The installation is done in 3 phases.
Phase 1: install normal packages to IMAGE_ROOTFS.
Phase 2: install multilib packages under MULTILIB_TEMP_ROOTFS. Packages
belongs to the same multilib arch would be installed to a unique
directory.
Phase 3: check file confliction between IMAGE_ROOTFS and
MULTILIB_TEMP_ROOTFS, install multilib packages to IMAGE_ROOTFS only if
the sanity check passed.
(From OE-Core rev: 9d81c2166be7ed388e5616e01ca2b4059e524c8e)
Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
1. Added MULTILIB_PACKAGE_INSTALL for multilib instances of packages to
be installed in the rootfs.
2. MULTILIBRE_ALLOW_REP contains the regular expression to match the
files allow to be replaced by the conflicting files.
3. MULTILIBRE_FORCE_SAME contains the regular expression to match the
files allow to be replaced only if the conflicting files are identical.
4. Added shell function multilib_sanity_check() to check whether the
overwring for multilib situation is allowed.
(From OE-Core rev: 137a4626a7e8107fc8a71724d5124f44236293b9)
Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a first pass at adding multilib support to the RPM package
and image handling code.
(From OE-Core rev: 1939a4395997098862912e013a2b13ed2f385f9f)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since we now handle GLIBC_DYNAMIC_LINKER in gcc-configure-common.inc:
's#\(GLIBC_DYNAMIC_LINKER[^ ]*\)\( *"/lib.*\)#\1 SYSTEMLIBS_DIR\2#'
we can drop the patch which changes a hardcoded value for this.
No PR bump since there is no code change resulting from this, its just
a cleanup.
There is still a valid question over the remainder of this patch and its
interaction with multilib configurations.
(From OE-Core rev: 036faf66c3889cd8bf4cd3c9b97c80f008f3c6e2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
in eglibc-package.inc, the "PACKAGES" variable use the ${PN} reference,
while RPROVIDES does not use ${PN}. This will lead multilib.bbclass
not mapping its RPROVIDES, and cause "NO RPROVIDER: lib64-glibc-utils"
error.
This patch unify the recipe to fix this issue
(From OE-Core rev: 37ff0fea8f7180b1a9d91d24dfe1735730427497)
Signed-off-by: Yu Ke <ke.yu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
in multilib case, the PACKAGE_DYNAMIC is overrided with multilib
prefix. Take multilib:lib64-perl as example. the "perl-module-*"
will become "lib64-perl-module-*"
the output_pattern in do_split_packages is designed to work with
PACKAGE_DYNAMIC, so it should be applied with the same logic, i.e.
overriding with multilib prefix. otherwise the do_split_package will
split incorrect files
this patch implements the mulitlib override logic for do_split_packages
We also need to rename the extra_depends to support multilib case
(from Dongxaio Xu).
(From OE-Core rev: a4bc86713892502aeefbbdb3053e8cf1e1fc0bdb)
Signed-off-by: Yu Ke <ke.yu@intel.com>
Signed-off-by: Xu Dongxiao <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
prune_suffix() also needs be aware of MLPREFIX when changing PN for
use in BPN.
(From OE-Core rev: 20dd241052afa5ff80b91ebf09b0b48765bc3412)
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>
Updating the linux-yocto SRCREVs to pickup changes from the
continuing uprev to korg 3.0. With this set of update, the
meta/feature audits are complete.
qemumips and qemuppc are fixed with this update and can now
boot to a prompt.
(From OE-Core rev: b4ec5c27b51c15e8bde7ca2597329c4f5b801240)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This means if PKGARCHCOMPAT_ARMV7A is set, "armv7a-vfp-neon" is renamed
to be "armv7a". Other compatibility mappings can be added as needed.
(From OE-Core rev: 08c0b7060009113e8dffdef51ff6b9b4b7f28894)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need to include file class and file color in order to do the conflict
resolution required with a multilib design. This is normally disabled when
we don't use the internal dependency generator, patch enables it in
all cases.
(From OE-Core rev: 4c43ea3440ecca02d2945b02017f56a8de9ff808)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When linking with gcc, the parameter is read from left to write, if *.o
calls a function contained in libxxx, the parameter order should be
"gcc ... *.o -lxxx".
This commit fixes the problem in distcc.
(From OE-Core rev: 782499eaa817f1beecc0aea5bfa075196f8e2a53)
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We switch to using os.lchown in order to avoid following a symlink.
We also now check if an item is a symlink, if so we avoid the
os.chmod as a symlink inherits the mode of it's target.
(From OE-Core rev: c64d075b3d367e6c76aafa17782585d026b1f31e)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
By default man pages are compressed, the way ncurses compresses
them causes differences (timestamp and name) to be embedded into
the gziped file. So each build will end up with a slightly
different file. Avoid this, by not compressing the man pages.
Avoid header conflict with curses.h using the multilib header
helper.
(From OE-Core rev: ae5269039511d0f3d8aa6a87cb8d9fcf01d79ddd)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Due to mismatches between various header definitions in i386 and x86_64
we need to overwrite the i386 versions of the headers with their x86_64
equivalents.
This can not be done for the syscall.h as it's dynamically generated,
so use the header conflict resolution helper for that.
(From OE-Core rev: 019a33236f76aacb989e8f37b09b81599c27f296)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Koen Kooi
Yu Ke
Mark Hatle
Kumar Gala
Malcolm Crossley
Saul Wold
Phil Blundell
Lianhao Lu
Martin Jansa
Dmitry Eremin-Solenikov
Paul Eggleton
Richard Purdie
Kang Kai
Dongxiao Xu
Bruce Ashfield