This also deletes the buildall task since I seen usecases for it.
(From OE-Core rev: 8229fb5d7205f5e5b198ab2860fbcc02054476eb)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This enables a switch to subversion 1.7 now bitbake is able to cope with
upgrading existing working copies. The impact of this change should be
minimal since we don't have many subversion recipes now.
(From OE-Core rev: ac0aa35ba6d7a21636bdd23d45ae0bf8112bdaa8)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[YOCTO #2605].
Added openssh-sftp-server to the tools-debug IMAGE_FEATURE.
(From OE-Core rev: a6b6df1350149c116050cb93c3c7b4802c709d31)
Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
IMAGE_FEATURES such as 'ssh-server-dropbear' and 'ssh-server-openssh'
can't be both enabled. User can use the following variables to define
the relationship of image features:
IMAGE_FEATURES_REPLACES_foo = "bar" means including image feature "foo"
would replace the image feature "bar".
IMAGE_FEATURES_CONFLICTS_foo = "bar" means including both image features
"foo" and "bar" would cause an parsing error.
(From OE-Core rev: e36d12a9c1cf69540079e48a1dfadbc343758e48)
Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using Gentoo Linux as the build host, it fails without this patch
Use Getopt::Std in place of getopts.pl.
https://bugs.gentoo.org/show_bug.cgi?id=420083
which following error:
/usr/bin/perl -w ./../msggen.pl -l jstyleModule InterpreterMessages.msg
/usr/bin/perl -w ./../msggen.pl -l jstyleModule DssslAppMessages.msg
Undefined subroutine &main::Getopts called at ./../msggen.pl line 22.
make[2]: *** [InterpreterMessages.h] Error 2
make[2]: *** Waiting for unfinished jobs....
Undefined subroutine &main::Getopts called at ./../msggen.pl line 22.
make[2]: *** [DssslAppMessages.h] Error 2
(From OE-Core rev: 169a89b10817b742c063fcd76721e4dbbcca6199)
Signed-off-by: Dennis Lan <dennis.yxun@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This appears to be an oversight in the original implementation. All of the
host package types were being ignored except for the SDK cross-canadian type.
(From OE-Core rev: 750f99d4e2c805985cd87a2358b0625a808ecf4d)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When building an image recipe, you can now build a companion SDK by
calling the populate_sdk task:
bitbake -c populate_sdk core-image-minimal
Note: there are still issues w/ the SDK not working completely with
multilibs.
A lock is required between rootfs and populate_sdk activities to prevent
configuration file clashes and similar package management problems in ipk
and deb based systems. (RPM already had a lock for a different reason.)
(From OE-Core rev: a0de2a56f19ae4d8cd88e46e96917a7a019fe1ab)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Most of the time skipping per file dependency generation is a bad idea, but
when building a nativesdk or similar you may be required to pickup host
dependencies. These host dependencies can not always be reconciled within
the scope of other nativesdk components, so if we skip them we can facilitate
this unique situation.
(From OE-Core rev: a1ca125de55a8e7cab402e2ba5737a56d4e890c2)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The libc-common attempts to rewrite the package information in a way similar
to debian.bbclass. When it does this, it should be appending to the
dependency variables (RPROVIDES, RREPLACES, and RCONFLICTS), instead
of simply setting a hard coded value. Otherwise the lib package can not
tailor the dependency variables to suite it's needs.
(From OE-Core rev: fa1c7b797593cbd5e82dc264bde2667620eb0515)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When configure fails, it usually says "see config.log" yet nobody ever shares
the config.log file meaning the person trying to help invariably has to ask
for more information.
This patch dumps all the config.log files into the main bitbake log files when
configure fails, meaning all the information is present to help someone debug
such failures. It does make the log rather larger but this is preferable to
not having enough information in most cases.
[YOCTO #2463]
(From OE-Core rev: 7ad08f5b73aa949a877adc5641b4bb1d007de750)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The u-boot tree is fully capable of parallel builds, so this
setting should not exist as a blanket setting for all of the
recipes. Going forward, if there is a parallelism issue
in u-boot, it needs to be reported and fixed there, and not
with the "make -j1" band-aid approach.
(From OE-Core rev: 7fdd1f82803df9752e908f01f7643d66b82a690e)
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We don't want to force everyone to be stripping the -Os
flags from their u-boot builds. Remove it, since it pertains
to an old toolchain issue that is no longer relevant, and it
breaks the powerpc mpc8315.
(From OE-Core rev: 5e3f777f9fcc986ae66203651830b5765bca49fd)
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In order to enable basic multilib support for the export of an SDK
image, a number of minor changes had to be made:
The value of MULTIMACH_TARGET_SYS needs to be variable. This way we
can define the value to the appropriate multilib. (Also in some cases
the default PACKAGE_ARCH is set to MACHINE_ARCH which is incorrect for
the SDK.) Add a companion REAL_MULTIMACH_TARGET_SYS, based on code
from meta-environment, to allow for this.
We have to convert the do_populate_sdk into a python call, and then
break up the previous items into three parts.
* Image construction
* Setup of environment files
* Generation of the tarball
Then we can iterate over the multilibs to populate the environment files.
Finally, matching changes were needed in the toolchain-scripts file. And
what I presume is an optimization of immediate evaluation for
TOOLCHAIN_CONFIGSITE_NOCACHE and ..._SYSROOTCACHE needed to be done at
runtime, otherwise the wrong values may be used.
(From OE-Core rev: 42545ffbb37f2646a2a8c20999c21d3300e24f59)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we combine the do_populate_sdk with the image generation, we want
to avoid the dependency processing unless do_populate_sdk is run.
This requires the bitbake change to implement task based rdepends.
(From OE-Core rev: 5fa9f980248e7813ce74f48a29c4b7d94e308cf9)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We want to be able to supply attempt only packages in the SDK in order to
support more advanced SDK images that more closely match specific image
recipes.
(From OE-Core rev: 9b9efa96537f4977b158c29151e53d02600d2294)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
populate_sdk was renamed to populate_sdk_base in order to allow for changes
that may break existing SDK recipes. Any such changes need an analog
in populate_sdk (new version) to restore previous desired behavior.
In addition to the rename, one minor change was made. The _base version
only had the do_populate_sdk as an added task, but no before or after defined.
For compatibility, populate_sdk has do_populate_sdk defined as "after"
do_install and before do_build, this is identical to the original behavior.
(From OE-Core rev: bde224ba44c16edc1892cea1b33ab973ae971115)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When a recent change, the path to log files may be contained within an
arbitrary directory. To generate the manual log files in the correct path
we should be using the ${BB_LOGFILE}'s path instead of always assuming the
logs go into ${WORKDIR}/temp.
(From OE-Core rev: 779db325d407f0bade84572ef99fdad4d0c88011)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
While sdk images already have dev-pkgs included, the kernel-dev package
is special and does not get installed. Add kernel-dev explicitly to the
*sdk image recipes.
Note: We have to be careful with "IMAGE_INSTALL +=" as it must appear
after "inherit core-image" which makes an "IMAGE_INSTALL ?=" assignment.
(From OE-Core rev: 337428316de3612a8e1efa70b3a4ba7cb6e058d2)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
CC: Jessica Zhang <jessica.zhang@intel.com>
CC: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is a "Segmentation fault" error when the tmpdir is longer than 470
(or less), this is because it used "char cmd[1024]" which is not enough
for the command line. Allocate a larger memory size should fix this problem.
[YOCTO #2664]
(From OE-Core rev: 3fd5d0334439b6231a6afd2a544a16b87ae81c99)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
kconfig-frontends provides the kconfig infrastructure
thats used for linux kernel as a standalone package. Its
not intended to be used for kernel itself but can be
used by packages who are based on kconfig e.g. busybox
uclibc or new packages who wants to use kconfig infra
for the package build
kconfig-frontends names it's shared library as -3.4.0.so instead of .so.3.4.0,
this causes the -dev package to grab it since it matches on *.so. This error
would also have shown up with the old PACKAGE order.
(From OE-Core rev: 705baf06d151eb4f9dcae7b23c7f3e57c0c09a74)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These variables all take package name extensions and should be considered in sstate
dependency processing.
This may also fix some multilib alternatives issues (unconfirmed).
[YOCTO #2056]
(From OE-Core rev: 64422f7c5da160050a5454817c8fa9d070104b34)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we don't do this it will match on expressions like "NOTE:" which
are not fatal errors.
(From OE-Core rev: 8f4e160ce0b0c755545d62b06db14decd45b9f1e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I noticed this when qemu-native failed to build and a rootfs was not generated
which is not the intended behaviour.
Also update the syntax to use appendVarFlag instead of get/setVarFlag
(From OE-Core rev: fa13e83ec3f91dce866ac212e91b62db24b6486d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(From OE-Core rev: ff3f912eed0270afa14d706fc1e57f8a1de2614b)
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(From OE-Core rev: 8846728da016a964f581e3aa76ec9d457a3d795d)
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If cross-compiling, apr's configure script assumes that pid_t is
64-bit which is wrong - it appears that 32-bit is a safe assumption
for Linux no matter what the architecture, so use that instead by
default.
This fixes Apache writing garbage to its pid file when built using apr
produced from this recipe.
(From OE-Core rev: 81eb71736a4d14abe85d810f9862d8a9421e9ef5)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
apr will use libuuid if it is present, and thus we should require that
it is there so that we have a deterministic build.
(From OE-Core rev: b880cebf503ca13cd4fcb741895e57e6353065be)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(From OE-Core rev: 935a7f3847bd86ed78418db5cb6dd98ac0b6e65d)
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
include-unistd.h-for-gcc47.patch is no longer needed, since it was fixed upstream.
(From OE-Core rev: 54429dfcca0e35a3aeaa78e509240b87d6a8f4ac)
Signed-off-by: Jonathan Santos <jrsantos@jonathanrsantos.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When making changes to kernel.bbclass, it would be nice not to have to
manually change the PR of every linux-yocto*.bb file that requires it.
Move the "require kernel" line to linux-yocto.inc and update the
linux-yocto recipes to use INC_PR.
(From OE-Core rev: 7a41d96c946029aeec03cd26f326bc6ca26e74fd)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
CC: Bruce Ashfield <bruce.ashfield@windriver.com>
CC: Tom Zanussi <tom.zanussi@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Building apache with this version of apr would blow up on the results
from:
apr_config --apr-libtool
Errors of the form:
/bin/sh: /media/large/tmp/sysroots/x86_64-linux/usr/share/build-1/libtool: No such file or directory
Fix that by ensuring libtool from apr's build lands in
.../usr/share/build-1/.
(From OE-Core rev: eefbc2f219571dd0c66e1099ea4ad72b1a973fd4)
Signed-off-by: Joe MacDonald <joe.macdonald@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
uclibc has some functions in librt that are needed
by bison build.
(From OE-Core rev: 987bc3ff3e1a619132434c5d939c7035d3d19fcb)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This gets systemd building with uclibc
(From OE-Core rev: d577fa59d8643954249fed7a79232e609add36f8)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This adds uclibc patches to build systemd there are
new functions that are used by systemd which are needed
Additionally when using gold linker to build userspace
based on uclibc there are spurious hidden symbol that
show up in librt.so and libc.so which should not exist
So we patch uclibc for that
(From OE-Core rev: ecffa7571ed27a75e3248cb860affae233249440)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
uclibc and uclibc-initial were providing conflicting PROVIDES
separate the common bits into logical pieces. Create a common
inc file to hold package information and version specific includes
so correct logical units can be included in uclibc and uclibc-initial
recipes.
(From OE-Core rev: bdfd2f6f286889b8920ebf6a670542b26534c1cb)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Quote for eglibc source:
for mips eglibc now builds syscall tables for all abi's
so we make sure that we choose right march option which is
compatible with o32,n32 and n64 abi's
e.g. -march=mips32 is not compatible with n32 and n64 therefore
we filter it out in such case -march=from-abi which will be
mips1 when using o32 and mips3 when using n32/n64
(From OE-Core rev: 6a013236d362874c661aa5f15b948aac32177181)
Signed-off-by: Dennis Lan <dennis.yxun@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This was needed because on eglibc based builds we did not
define USE_NLS but now we define it in default config to have
a valid value so we do not need this here. Moreover it was
wrong and was not covering all cases of uclibc triplets
(From OE-Core rev: fc9492654aab2a6e3f46977193b5a5f388e4ee85)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
USE_NLS is generally defined for uclibc based system builds
and generally its defined to 'no' there. However this variable
does not exist at all for eglibc/glibc distributions. This
patch adds a weak definition to 'yes' on eglibc based system
builds. This will ease out some of the cryptic contructs we
have to define certain options based on USE_NLS and also
checking got uclibc at the same time to avoid pythong exceptions
when its not defined.
(From OE-Core rev: 41db1bf69314e542a9d7ac1fb1b4bc65db75b642)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes build warnings like below
WARNING: For recipe libgcc, the following files/directories were installed but not shipped in any package:
WARNING: /usr/lib/arm-oe-linux-gnueabi/4.7.2/include
WARNING: /usr/lib/arm-oe-linux-gnueabi/4.7.2/include/unwind.h
(From OE-Core rev: f7ec6ea2b32207993e7fc92ed67c08f542007953)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The "apply=yes" doesn't appear to be necessary, so drop it.
[YOCTO #2664]
(From OE-Core rev: 78abdd12305d4b74d7ec82fd38b7a27aaa8d7d95)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In tree linux-yocto 3.0 boards indicate that they are BSPs via
the older/obsolete syntax "scc_leaf". This line in their board
description is detected by the build process and is used to find
the BSP description and the kernel type they use as their base.
To work with the latest kern tools, the BSP descriptions should
be updated to "include <ktype> branch <machine>" to acheive the
same result.
All trees newer than 3.0 already have this change and do not need
to be updated.
(From OE-Core rev: e32c993859337964033a285922dac3971e5add2d)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The autogen-native built error on FC17:
ccache: failed to create /dev/null/.ccache
This is because the default gcc command of FC17 is a symlink to ccache,
so the ccache will always be used regardless to the setting of CCACHE,
ccache uses $HOME/.ccache as the CACHE_DIR by default, but autogen set
HOME=/dev/null, so the error happens.
Disable ccache explicitly if it is not enabled would fix the problem,
otherwise it would always use ccache regardless to the setting of CCACHE
on Fedora 17.
The ccache 3.1.7 has a bug, it would always create $CCCHE_DIR/.ccache
even CCACHE_DISABLE=1.
Unset CCACHE_DISABLE in ccache.bbclass, since ccache only checks whether
there is a CCACHE_DISABLE in the environment or not, it doesn't care about
its value, so we need unset it explicitly when enable ccache.
[YOCTO #2554]
(From OE-Core rev: dd2bab9b6a973d8086dfb6282e781fd79d30b05a)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This function can miss packages whose license is in
"COPYLEFT_LICENSE_EXCLUDE" and tarball packages with license in
"COPYLEFT_LICENSE_INCLUDE".
[YOCTO #2473]
(From OE-Core rev: 4800bed394ebd7fb50552a96d6a5f83d98fe790f)
Signed-off-by: Xiaofeng Yan <xiaofeng.yan@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Laurentiu Palcu
Richard Purdie
Lianhao Lu
Dennis Lan
Mark Hatle
Paul Gortmaker
Darren Hart
Robert Yang
Khem Raj
Robert P. J. Day
Paul Eggleton
Jonathan Santos
Valentin Popa
Joe MacDonald
Bruce Ashfield
Xiaofeng Yan