There were a couple problems with the handling of precompiled locales.
- it gathered the list of locales from the directories - this breaks due to
the naming mismatch, e.g. en_US.UTF-8 vs en_US.utf8.
- it retained its hardcoded assumption that the non-suffixed locale (en_US, as
opposed to en_US.*) is UTF-8, while the others are otherwise. Hardcoding
this is both inflexible and just plain wrong for some toolchains. It's most
common in desktop distros for 'en_US' to be non-utf8, and ''en_US.UTF-8' is
utf8, and this is the case in some external toolchains as well.
The code now uses the SUPPORTED file to hold the knowledge it needs. This file
not only holds the list of locales to generate, but also maps the locale names
to the charsets they correspond to. The code now uses this to assemble its
charset map, falling back to the '.' suffix as charset when the locale is not
in the map. For precompiled, it now uses the locale->charset knowledge it has,
thereby allowing non-utf8 non-suffixed locale names, whereas for
non-precompiled, it reverts to the previous assumption, renaming the utf8
locale and forcibly suffixing the others.
So, a person maintaining an external toolchain recipe is responsible for
ensuring that the SUPPORTED file they provide matches up with the compiled
locales in the toolchain, if they want to utilize precompiled locales.
I believe in the long term the compiled case should do the same thing
precompiled does, and use SUPPORTED or a similar mechanism to encode the
knowledge, and if people want all the non-suffixed names to be utf8, they can
change that file to do so. This would avoid the hardcoded assumption in the
code, as well as consolidating the behavior between the compiled and
precompiled cases.
Signed-off-by: Christopher Larson <kergoth@gmail.com>
We want to ensure that changing external toolchain version will change the
metadata checksums of target recipes. This will do so via ensuring that any
variable which references TOOLCHAIN_OPTIONS also pulls in the toolchain
version variables.
Signed-off-by: Christopher Larson <kergoth@gmail.com>
A quick glance at configure.ac shows that both are required to build mesa, but
we were relying on their being built implicitly via other recipes in the
dependency chain. Make it explicit.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Kang Kai [Tue, 13 Mar 2012 03:23:59 +0000 (11:23 +0800)]
create-recipe: base on autospectacle.pl to create recipe file
[Yocto 1656]
create-recipe is based on original autospectacle.pl from project Meego.
Add feature to create a recipe .bb file. It requires a parameter to be
told where to download source package, then download and parse.
Create recipe file according to parse results.
This is a newly installed directory and Makefile that is not needed
in an embedded setup
It fixes:
ERROR: For recipe eglibc, the following files/directories were installed but not shipped in any package:
ERROR: /var
ERROR: /var/db
ERROR: /var/db/Makefile
Martin Jansa [Wed, 21 Mar 2012 07:51:39 +0000 (08:51 +0100)]
xorg: add more native BBCLASSEXTENDs from meta-oe
* We have now .bbappends in meta-oe, but adding native BBCLASSEXTEND
doesn't add any maintenance cost to oe-core and makes recipe upgrades
easier (no need to wait for .bbappend renames ready for meta-oe).
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
busybox: Pass HOST_CC_ARCH through CONFIG_EXTRA_CFLAGS
The -mabi option is part of HOST_CC_ARCH which does not
appear in CFLAGS. This is for completeness since compiler
already defaults to n64 it wont matter that much
uclibc has recently got posix_spawn implementation
and the implementation resided in librt so we link
-lrt to get the configure tests using uclibc provided
definitions and not the gnu-lib wrappers
Currently we stub out iconv in glib when building
for uclibc which is not needed and infact results
in building systems with false hope of having
iconv and they misbehave during runtime
Peter Seebach [Fri, 27 Apr 2012 23:51:46 +0000 (18:51 -0500)]
tune-sh4.inc: Fix spelling of big-endian feature set
In tune-sh3, tune-xscale, and tune-sh4, several FEATURES lines referred
to nonexistent features like "sh3eb" when they should have referred to "sh3
bigendian" or the like. Caught by the TUNEVALID sanity check.
Signed-off-by: Peter Seebach <peter.seebach@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Martin Jansa [Sun, 29 Apr 2012 08:46:42 +0000 (10:46 +0200)]
ofono: upgrade to 1.6
* 1.5 is not compatible with glib-2.32 and newer
| In file included from gisi/client.h:30:0,
| from gisi/client.c:33:
|/OE/shr-core/tmp-eglibc/sysroots/spitz/usr/include/glib-2.0/glib/gtypes.h:28:2: error: #error "Only <glib.h> can be included directly."
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Richard Purdie [Thu, 9 Feb 2012 14:09:18 +0000 (14:09 +0000)]
package_rpm: Only rebuild the indexes if the packages have changed
This change farms the solvedb creation out to a separate script which
handles creation of the index, only if mtime of any of the packages
has changed.
For a core-image-minimal set of rpm's this saves ~20s of a 45s rootfs
build. For core-image-sato it saves 1 minute of a 5 minute rootfs build.
The more packages in the system, the bigger the saving will be.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ken Werner [Fri, 27 Apr 2012 10:59:17 +0000 (12:59 +0200)]
Qt 4.8 GCC 4.7 fixes
This change introduces two new patches to Qt 4.8. One prevents the build
system from using the -fuse-ld=gold GCC flag as this isn't upstream and
therefore not supported by many toolchains out there. The second patch
fixes a compile time error when using toolchains based on GCC 4.7.
Signed-off-by: Ken Werner <ken.werner@linaro.org> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Richard Purdie [Thu, 26 Apr 2012 19:54:23 +0000 (20:54 +0100)]
package_rpm.bbclass: Replace shell provides/requires script with python version
The existing shell script is a fork bomb and forks off hundreds of
grep/cur/wc calls as it reads from its input stream and iterates over
the file data table for each line of input. This patch replaces the
shell code with python code which doesn't exec anything and hence runs
much faster without the exec() overhead. This speeds up rpm packaging
considerably, as can be measured simply by timing it, or watching the
processor utilisation.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
gcc-4.7: Use full relative path in require directive
This will help in meta-linaro where it will be able
to utilize maximum recipes from OE-Core and thereby
keep close compatibility with OE-Core gcc recipes
Khem Raj [Thu, 22 Mar 2012 23:15:50 +0000 (16:15 -0700)]
gcc-4.7: Lower the internal consistency check level to release
This should help in speeding up compilation at the expense
of a bit less info when gcc ICEs but we dont get many gcc
ICEs and therefore using --enable-checking=release is
right balance
Khem Raj [Thu, 22 Mar 2012 23:08:03 +0000 (16:08 -0700)]
gcc-4.7: Disable cloog and ppl
If build system has those libraries installed
gcc configure will pick them up. We want
consistent builds so we disable them since we
do not (yet) support them
gcc-4.6: Specify complete paths in require directive
This is needed for adjusting meta-linaro where linaro
gcc recipes leverage the core recipe infrastructure and
modifies minimal to keep compatibility with OE-Core
so that any changes in OE-Core gcc recipes does not
trigger changes in meta-linaro.
this option by default points to /usr/local no matter
what so we cant let it sit on sidelines otherwise it
will access host machine's /usr/local which may not
be desired. So disable this option. This also helps in making
gcc's shared state more consistent
Khem Raj [Fri, 24 Feb 2012 03:07:46 +0000 (19:07 -0800)]
gcc: Stash the gcc-cross builddir to reuse in libgcc and gcc-runtime
Currently we stash the libgcc install tree and then reuse that
to populate libgcc recipe later. This mechanism does not work
for gcc 4.7/trunk since now libstdc++ needs access to build tree
of libgcc. This patch stashes the gcc-cross build tree
and then reuses this in libgcc as well as in gcc-runtime
recipe builds.
Now we build libgcc in the libgcc recipe instead of just
using the prebuilt install tree
core-image-minimal build/run tested on all qemu machines
Khem Raj [Wed, 28 Mar 2012 14:22:44 +0000 (07:22 -0700)]
gcc-configure: Pass distinct target flags
When building gcc-cross-canadian libgcc is built using
headers from gcc-crosssdk and not the target sysroot
because we do not pass proper CFLAGS for target bits
so it ends up using CFLAGS that were meant for compiling
canadian gcc itself. It does not show up as a problem
when building SDK with eglibc because eglibc-nativesdk
and eglibc have identical headers. The problem shows
up clearly when you try to build uclibc based meta-toolchain
since then nativesdk libc and target libc are different
Khem Raj [Thu, 22 Mar 2012 22:51:29 +0000 (15:51 -0700)]
tcmode-default: Use SDKGCCVERSION ?= "${GCCVERSION}"
Usually they should be same if not defined to be different
by user. In this case if I override GCCVERSION in local.conf
then SDKGCCVERSION will also follow the suite.
Richard Purdie [Sat, 11 Feb 2012 02:58:28 +0000 (18:58 -0800)]
classes: Add recipe class to overrides
We have currently no override to detect a recipe being build cross, crosssdk
or for target at times we can use virtclass-native and virtclass-nativesdk to
override stuff in recipes but we dont have way to modify a variables
based on recipe type always.
This patch adds in such an override and in particular makes a target override
class available.
Martin Jansa [Fri, 23 Mar 2012 22:30:40 +0000 (22:30 +0000)]
bitbake.conf: use TUNE_PKGARCH instead of TARGET_ARCH in SDK_NAME
* also use weak assignment for SDK_NAME_PREFIX as suggested by khem
* TUNE_PKGARCH is not 100% right too, because such SDK image usually has few
machine specific packages included (e.g. base-files, securetty, opkg configs)
but those are not important for SDK users so it's better to have one SDK for
whole e.g. armv7a-vfp-neon then 6 SDK for each machine which would work the
same.
You can see diff between crespo and om-gta04 SDK here:
http://build.shr-project.org/shr-core/sdk/oecore-i686-armv7a-vfp-neon-toolchain-efl-crespo-om-gta04.diff
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* The location where xev was located didn't contain xorg-app-common.inc,
but still xev requires it. So moving it fixes that issue.
* File checksums and License checksums were also added.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
While building on distros like fedora17, which has /bin/perl,
the target perl scripts get perl path also as /bin/perl.
And that is not correction path of perl on the target.
This commit avoids this error.
| error: Failed dependencies:
| /bin/perl is needed by quilt-0.51-r2.i586
NOTE: package core-image-sato-sdk-1.0-r0: task do_rootfs: Failed
ERROR: Task 8
(/home/nitin/prj/poky.git/meta/recipes-sato/images/core-image-sato-sdk.bb,
do_rootfs) failed with exit code '1'
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
Mark Norman [Wed, 25 Apr 2012 10:44:20 +0000 (20:14 +0930)]
uclibc SDK not including libpthread_nonshared.a
Modified the uclibc PACKAGES list order to ensure the uclibc-dev package is
processed before uclibc-staticdev to allow *_nonshared.a libraries to be
packaged in the uclibc-dev package. The *_nonshared.a libraries are required
by the SDK.
Scott Garman [Wed, 25 Apr 2012 05:13:12 +0000 (22:13 -0700)]
libpng: upgrade to 1.2.49
License hasn't changed, just updated the md5 checksums due to trivial
date changes within the text (and the position of the license text
within png.h).
Addresses CVE-2011-3045
Fixes [YOCTO #2352]
Signed-off-by: Scott Garman <scott.a.garman@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Andrei Gherzan [Thu, 5 Apr 2012 20:54:24 +0000 (23:54 +0300)]
python: Add patch to avoid warning about _tkinter
_tkinter module needs tk module along with tcl. tk is not yet integrated
in yocto so we skip the check for this module.
Avoid a warning by not adding this module to missing variable.
[YOCTO #1937]
Signed-off-by: Andrei Gherzan <andrei@gherzan.ro> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Andrei Gherzan [Thu, 5 Apr 2012 20:54:22 +0000 (23:54 +0300)]
python: Add patch to search for db.h in inc_dirs and remove warning
python should search for db.h in inc_dirs and not in a hardcoded path.
If db.h is found but HASHVERSION is not 2 we avoid a warning by not.
adding this module to missing variable.
[YOCTO #1937]
Signed-off-by: Andrei Gherzan <andrei@gherzan.ro> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Andrei Gherzan [Thu, 5 Apr 2012 20:54:21 +0000 (23:54 +0300)]
python: Add patch for 64bit platform
This patch was added for 64bit host machines. In the compile process python
is checking if platform is a 64bit platform using sys.maxint which is the host's
value. The patch fixes this issue so that python would check if TARGET machine
is 64bit not the HOST machine. In this way will have "dl" and "imageop" modules
built if HOST machine is 64bit but the target machine is 32bit.
[YOCTO #1937]
Signed-off-by: Andrei Gherzan <andrei@gherzan.ro> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
{kernel, module}.bbclass: don't run depmod for module packages during do_rootfs
* depmod already gets executed by pkg_postinst_kernel-image.
* If you build a module using module.bbclass, pkg_postinst returns 1 in
do_rootfs, causing pkg_postinst to run again on first boot. To improve
this situation, I copied pkg_postinst from kernel.bbclass to module.bbclass.
This was rejected by Koen, because he doesn't like the code from
kernel.bblcass, which uses ${STAGING_DIR_KERNEL}. Richard then suggested
that calling depmod during do_rootfs wasn't necessary at all, because
it already gets done by kernel-image.
Signed-off-by: Andreas Oberritter <obi@opendreambox.org> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Martin Jansa [Thu, 29 Mar 2012 14:08:55 +0000 (16:08 +0200)]
kernel.bbclass: unify white spaces
* indentation was with spaces and tabs, unify to use tabs instead of
spaces, for shell code and populate_packages_preppend,
because "python populate_packages" expects tabs (or 8 spaces)
* and use 4 spaces for anonymous python
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
