Age | Commit message (Collapse) | Author | Files |
|
It is not entirely obvious that all reasonable configurations
will have multilib.conf strictly before the file which might
want to set MULTILIB_GLOBAL_VARIANTS. The x86-ish values here
look like reasonable default guesses, but shouldn't override
an explicit setting.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
directory
Currently we have a hierarchy of pkgdata directories and the code has to put together
a search path and look through each in turn until it finds the data it needs.
This has lead to a number of hardcoded paths and file globing which
is unpredictable and undesirable. Worse, certain tricks that should be
easy like a GL specific package architecture become problematic with the
curretn search paths.
With the modern sstate code, we can do better and construct a single pkgdata
directory for each machine in just the same way as we do for the sysroot. This
is already tried and well tested. With such a single directory, all the code that
iterated through multiple pkgdata directories and simply be removed and give
a significant simplification of the code. Even existing build directories adapt
to the change well since the package contents doesn't change, just the location
they're installed to and the stamp for them.
The only complication is the we need a different shlibs directory for each
multilib. These are only used by package.bbclass and the simple fix is to
add MLPREFIX to the shlib directory name. This means the multilib packages will
repackage and the sstate checksum will change but an existing build directory
will adapt to the changes safely.
It is close to release however I believe the benefits this patch give us
are worth consideration for inclusion and give us more options for dealing
with problems like the GL one. It also sets the ground work well for
shlibs improvements in 1.6.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Multilib with opkg hasn't worked since the --force-overwrite option was dropped in
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=88a9f6db3482623c9cb54fb03db1045051cec9f6
Since we merged the libexecdir changes, we also need the --force-maintainer flag
to avoid conf file conflicts.
Both these changes are suboptimal however the alternative is completely broken and
these changes only affect people who have multilibs enabled and use opkg.
[YOCTO #3453]
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
(From OE-Core rev: 81f3dd49693a7ad2e98c182896c98fc71b01592f)
Signed-off-by: Constantin Musca <constantinx.musca@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
(From OE-Core rev: 1a97cab9d4856e8948025ce6f406c76a2732ec36)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
- skip the non-packagegroup allarch recipes in multilib_virtclass_handler
- extend PROVIDES/RPROVIDES for allarch recipes which are not packagegroups
- use variants from MULTILIB_GLOBAL_VARIANTS (lib32 lib64 libx32) to create
additional pkgdata files for multilib allarch: ${pkgdatadir}/${variant}-${PN}
and ${pkgdatadir}/runtime/${variant}-${pkg}
- use variants from MULTILIB_VARIANTS to create additional pkgdata files
for multilib kernel/module-base recipes
- add a sanity check to determine if the current multilib is in
MULTILIB_GLOBAL_VARIANTS
[YOCTO #2918]
[YOCTO #3440]
[YOCTO #3565]
[YOCTO #3568]
Signed-off-by: Constantin Musca <constantinx.musca@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
If the STAGING_DIR_KERNEL is set in the multilib.conf, then it may be
set incorrected. The evaluation happens before TMPDIR and LIBC are
defined in other components.
Moving the definition process to the multilib.bbclass ensures that
everything has been loaded before it is set.
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
RP: The list of recipes in multilib.conf needs to go away and we need
to just be able to extend all recipes with the multilib class.
Tested by building and running lib32-core-image-sato-sdk.
[YOCTO #1563]
Signed-off-by: Bogdan Marinescu <bogdan.a.marinescu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
cross compile, we can add it back
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
1. STAGING_KERNEL_DIR was getting an invalid MLPREFIX. Fix this by forcing the expansion in multilib.conf.
2. Added multilib rule for 'perf'.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This project has been unmaintained for some time, and even the OpenMoko
project is not using it any more (in favour of FSO). Since we have ofono
in OE-Core which replaces and surpasses its functionality, we can remove
libgsmd.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
(-) renamed self-hosted-image to build-appliance-image
(-) replaced build-appliance-image description
[YOCTO #2636]
Signed-off-by: Valentin Popa <valentin.popa@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Add the multilib support for this package to multilib.conf because error will
appear when building an lib32-core-image-lsb without this patch.
[YOCTO #2571]
Signed-off-by: Xiaofeng Yan <xiaofeng.yan@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
[YOCTO #2316]
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Zhai Edwin <edwin.zhai@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
task-core-tools-debug, task-core-tools-profile, task-core-tools-testapps
otherwise if we choose one through PACKAGE_GROUPS all packages
are built since they are in same recipe.
Signed-off-by: Khem Raj <raj.khem@gmail.com>
|
|
This patch adds in various missing dependencies to ensure the set
of recipes listed for multilib support can be cleanly built.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Enable these two core dependencies for multilib builds, fixing
multilib build failures that were occurring. I've checked and the
recipes are multilib capable.
[YOCTO #1835]
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It's very old at this point and doesn't build with recent clutter
Signed-off-by: Joshua Lock <josh@linux.intel.com>
|
|
clutter-1.8 is the future here.
Signed-off-by: Joshua Lock <josh@linux.intel.com>
|
|
The D-Bus backend has been integrated into upstream GConf so we can
switch to upstream and drop gconf-dbus.
I've gone for a release in the 3.2 series as we disable Gtk+, and
therefore are not impacted by the gtk+3 changes, and the D-Bus backend
was unstable before this release.
Signed-off-by: Joshua Lock <josh@linux.intel.com>
|
|
* xserver-xorg is closer to upstream naming and
that's how it's named in OE-classic and meta-oe? It would make meta-oe
transition easier and better to do it now then convert meta-oe to
xserver-xf86 and then rename it back later.
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
|
|
currently we have allarch type of recipes, which may still have
architecture dependency, like x11-common. So we need to drop the
handling to allarch in multilib case.
Also remove the PV postfix in python-pygobject DEPENDS, since multilib
code will treat a native package multilib capable.
[YOCTO #1497]
[YOCTO #1498]
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
|
|
[YOCTO #1481]
Since tasks are referred to almost exclusively via RDEPENDS, and bitbake
will build an entire task recipe when only one of its task packages are
actually needed, building a console-only image that uses
task-core-apps-console (or less directly, has apps-console in its
IMAGE_FEATURES) will cause a build of a whole list of X11 applications
that aren't needed. Splitting the task-core recipe into X11 and console
portions prevents this issue.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
Recipes like update-rc.d and qemu-config inherit "allarch", thus we
shouldn't add multilib BBCLASSEXTEND for them in multilib.conf.
Besides, we need to add multilib packages as the RPROVIDER contents for
those recipes, in order to avoid the NoProvider error when parsing.
[YOCTO #1471]
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Kernel should be unique in a multilib system, so we remove the
linux-yocto's extension in multilib.conf
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
For a given system we only want one kernel to be built. This change makes
the main kernel recipe provide all of the provides of the various enabled
multilibs hence allowing it to fulfil all the appropriate dependencies.
To make this work a global multilib class file needed to be created.
This patch also enables this multi provider functionality for "allarch"
packages.
[YOCTO #1361]
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
libsdl is required by sato image, so extend it for multilib.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
|
|
Thinking of the senario that, if we already built out a 64bit image
along with the full toolchain bootstrapped, then we need to build some
32bit libraries, which needs lib32 versions of gcc and eglibc. These
toolchain recipes will bootstrap again in the same sysroot, resulting
that lib32-gcc-cross-initial will find some macros owned by eglibc have
already been defined and thus it includes non-existed headers that
provided by later lib32-eglibc.
The solution for the above issue is to use different sysroot for
multilib recipes, here we add ${MLPREFIX} in front of the machine
specific sysroot directory name.
[YOCTO #1372]
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
|
|
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.
3. multilib bbclass handler will save the orignal value of all variables
defined in MULTILIB_SAVE_VARNAME.
Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
|
|
Added more recipes supporting multilib extend.
Signed-off-by: Lianhao Lu <lianhao.lu@intel.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)
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>
|