binutils will build differently if this feature is enabled, so
make the do_configure step depend on it
(From OE-Core rev: 0788cf349fe37ef4a36c626dbc396c97d1ab14d7)
Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
chrpath is assumed to be provided by the build host system. This means
we need to provide a replacement version and install into a specific directory
to avoid races.
(From OE-Core rev: 147c44c882a3dc667c079165d3ddc9d78b702286)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This converts the option to maintain the existing behaviour unless the option is
specified. We do specify the option during the builds themselves to ensure what
the users expects is built.
(From OE-Core rev: 0cc479699fe885049625d54c712b500c1b719e75)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
All variants of opkg are currently configured --disable-curl so there
seems no point in depending on it.
(From OE-Core rev: 875f1eb876c17c038a77bc7b7a5fed775d9fd3ea)
Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Even when installing onto a live target system, calling sync() during
package installation is of somewhat questionable benefit. But calling
it on the build host during rootfs construction is certainly useless and
can cause I/O to stall for several seconds on even a moderately sized
host which is clearly not desirable.
(From a patch originally by Mike Crowe.)
(From OE-Core rev: f48a68177510e8f2d4fcc3725a6dfc41a9a8e96b)
Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In certain cases with BerkleyDB 5.3.x we are getting the error:
db3.c:1443: dbcursor->pget(-30999): BDB0063 DB_BUFFER_SMALL: User memory too small fo
See https://bugs.launchpad.net/rpm/+bug/934420 for more information.
It appears to be some type of a bug in the BerkleyDB 5.3.x. In an attempt
to workaround the problem, when we encounter this situation we attempt
to adjust the size of the mmap buffer until the call works, or we
end up trying 10 times. The new size is either the updated vp->size
from the failed pget call, or the previous size + 1024.
If DBI debugging is enabled, additional diagnostics are printed, otherwise
a basic retry and success message is added to show that the failure was
resolved.
(From OE-Core rev: bfb2906206158748d0be33baf7984cf885756da1)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Remove the optimzation append from recipe and add the patch that is in the rpm
cvs repo, http://www.mail-archive.com/rpm-cvs@rpm5.org/msg08907.html. The -O2
optimzation append is removed since it can limit debugging options that are
provided when -O0 is used.
This was tested by setting: SELECTED_OPTIMIZATION = "-O0"
(From OE-Core rev: d109c6bd163469d6281d20174e4b79cb63483cd4)
Signed-off-by: Morgan Little <morgan.little@windriver.com>
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is an issue that is caused when doing the install step of rpm on systems
with high parallelization where two jobs of make will fight for the same file
while installing the sub-directory lua. This is caused by the same makefile rule
being called twice in a way that both could be trying to install at the same
time.
This fix renames the linking rule so it will always be run after the needed
files are added and removed it's dependency so the required rule would only
run once.
This was tested heavily using ppss to run mutliple installs in parallel. This
wouldn't happen in practise but it was tested will all the individual rules as
well.
(From OE-Core rev: d05c5da6b972db97d3eb66b659f5641368c9ebe4)
Signed-off-by: Morgan Little <morgan.little@windriver.com>
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When attempting to build with uuid and all tests compiling will error because
uuid.h doesn't exist in the rpm tarball. Fix this by changing the include to
use the one in ossp which solves the issue.
The recipe already depends on ossp so ossp/uuid.h will be there when rpm-native
is built.
(From OE-Core rev: 52ae2c2439bcb78323f61a3666e9b630b3a40b15)
Signed-off-by: Morgan Little <morgan.little@windriver.com>
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We're going around in circles trying to fix the sed expressions and making one case
work and others not work. This patch fixes the base configuration file so we have
non-overlapping substitutions. I've tried to significantly clean up various problems
that were occurring once and for all.
This will hopefully resolve all the issues people have been seeing with incorrect perl
paths.
(From OE-Core rev: 31ff70794ecc431431476f81c8934fff25383613)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It is needed in some SDKs that we ship own
version of lex/yacc for sdk host
(From OE-Core rev: 536c9e42d316efb42651fdc2eba1b8548d74329d)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Nothing should ever be poking files directly into the staging/sysroot
directories, it should always go through ${D}.
This patch ensures this recipe does this and hence fixes various
potential build issues such as lack of sstate tracking of files.
(From OE-Core rev: 7642143760c0157aba80cea7b427024ee097cc2c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Commit 38234f2e276356b1d77a87ceabc486107e336d19 tried to fix the sed
expressions by anchoring the left side of the search regexp to prevent
$prefix$prefix type expression in the perl config. For nativesdk this is
not enough. Adding anchors on both side fixes this.
(From OE-Core rev: bf84ec0fb9a4d01ea75447c2efe8e534ce975b53)
Signed-off-by: Christian Glindkamp <christian.glindkamp@taskit.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The LICENSE for ossp-uuid is MIT. As well, the LIC_FILES_CHKSUM
was missing the license text within uuid_md5.c
(From OE-Core rev: 99974820c8b12b1c1b05ab8a96f1b25b8e3888da)
Signed-off-by: Elizabeth Flanagan <elizabeth.flanagan@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This allows BSPs for architectures with no thread support to set (for
example) "GCCTHREADS=no" without having to override all the other configure
parameters.
(From OE-Core rev: 6bb0d37529a82b953d374f2d76c2412d7cee587b)
Signed-off-by: Phil Blundell <pb@pbcl.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When doing multilib builds rpm does not find libgcc1 for lib32
multilib because its not honoring the debian renaming scheme for
libgcc-multilib. Lets add MLPREFIX to fix it.
(From OE-Core rev: 9327ca868667b15f29af3123611d6f56b4249a63)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This solves a problem when installing rpm using the ipk pkg-management
system where /var/cache was conflicting with the existing /var/cache from
base-files.
(From OE-Core rev: 917f57cbb0906996661eebc6656c2c083ef979e9)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These were not getting fixed by orignal committer!
(From OE-Core rev: 7db73c70351939c4be9867981a8cf97148bbe57e)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch has been causing some regressions on gold.
e.g. systemd based images segfault and uclibc based images
dont boot. There has been few other reports on the mailing
list. Considering this lets withdraw this patch.
(From OE-Core rev: ecbe671de1553956f83798e1c6fa3ec2fc6a7b4e)
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>
For reasons that are now shrouded in obscurity, autotools.bbclass
has long contained a special heuristic to avoid attempting to run
autoreconf when building autoconf or automake themselves. However,
the wildcard test against PN which is used there is problematic when
trying to build another package whose name happens to start with
"autoconf", and in any case it is silly to do this test at runtime
for every package. The individual recipes for autoconf and automake
can just as easily suppress the behaviour that they don't want by
providing a custom do_configure() method which just runs configure.
(From OE-Core rev: a87db6f8dea71cbb7ead9285ff8af0e28cf75604)
Signed-off-by: Phil Blundell <pb@pbcl.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is needed if installation is done in a directory that needs root
privileges.
(From OE-Core rev: 28823486ba8ce4d88bbad3cea696ce9fba0cc165)
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This avoids the SVN or git fetcher issues for gcc
and the tar is mirrored around the world so it will
not be slow
Fixes [YOCTO #2908]
(From OE-Core rev: 5e03d1e83d0536a2fc69a88d3e5407108836203f)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The globs used for STAMPCLEAN were too greedy matching gcc-cross-initial
stamps for gcc-cross for example. This patch resolves that problem making
the assumption that PV starts with something numeric. This assumption
should hold in most cases and has a better failure case that the current
situation.
(From OE-Core rev: d7fbc70b6c6ac629d2a23ac16ab45461f88b4b26)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The directory usr/libexec/ in the SDK sysroot contains the default
symlinks to the toolchain binaries and these, too, need to point to the
correct toolchain path.
[YOCTO #3090]
(From OE-Core rev: 6e4923c0c9b218271fd44d78df9987b5cabb1c03)
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the installation is done in a directory which already contains a
valid installation, opkg will not install anything and the moving the
contents of /install/dir/opt/poky/1.2 (for example) to /install/dir will
throw some errors. However, the install directory will not be affected.
This patch will ensure that the /install/dir/opt/poky/1.2 exists.
(From OE-Core rev: 1cd01533cbec0e9ed61bbd33ecdf5dc306a32eec)
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The SDK installation scripts should not canonicalize symlinked
directories because the entire relocation would be done to the directory
to which the symlink points. Instead, if the installation is a symlink,
use that path to relocate the binaries.
For example, if we have the following symlink: /opt/sdk -> ~/my/test/sdk
the binaries will be relocated to /opt/sdk not ~/my/test/sdk as it is
done now.
[YOCTO #3102]
(From OE-Core rev: 9e6a25e2e9a7f37c3baa0b2949a43ac4127868da)
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When the cross canadian toolchains are installed, for different
architectures, they might contain common files. This leads to
installation failures since the opkg, by default, does not overwrite
files. This issue happens, for example, for binutils packages (that
contain the same locale files) or gdb (which installs some syscalls xml
files). The locale files could be removed from the binutils
cross-canadian package but we cannot do the same for the syscalls GDB
files which are used by GDB to display user friendly names for the
syscall numbers. Hence, the best solution is to force opkg to overwrite
these files.
[YOCTO #3109]
(From OE-Core rev: 3396545467df05421c3adeb4b5ec532fa95dcb06)
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
- include /usr/share/aclocal/intltool.m4 into the intltool
package (the files from intltool-dev must be included into the
main package, as intltool is a development tool)
- add missing rdepends: gettext-dev, libxml-parser-perl
[YOCTO #2597]
(From OE-Core rev: f5f3d3fb14e983af114afc6425dc339053927f25)
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>
This is for fixing the problem:
1) bitbake core-image-sato-sdk with MACHINE=qemux86
2) bitbake core-image-sato with with MACHINE=crownbay
The qemux86's PACKAGE_ARCH is i586, the crownbay's is core2, but several
i586 packages will be installed into crownbay's rootfs though there are
core2 packages. For example, there are:
xserver-xorg*_1.11.2-r7_i586.ipk
xserver-xorg*_1.9.3-r1_core2.ipk
The crownbay.conf says:
PREFERRED_VERSION_xserver-xorg ?= "1.9.3"
What the crownbay's image needs is xserver-xorg*_1.9.3-r1_core2.ipk, but
the xserver-xorg*_1.11.2-r7_i586.ipk will be installed, this is
incorrect.
This is caused by opkg's selecting mechanism: when more than one
candidate is found, it will use the higher version one and ignore the
arch priority.
we have several conf files which set the PREFERRED_VERSION_pkg = "..." ,
but there is no such a mechanism which can let us tell the opkg to
install the preferred version. When the preferred version is higher,
this is OK, but if the preferred version is lower, there would be
problems:
1) Most of the packages are core2 in the image, but several of them are
i586, though we have built the core2 ones, this seems strange.
2) What's worse is that the image may not work since the preferred
version pkg is not installed.
We have set the arch priority clearly in the opkg.conf, I think that
respect to the arch priority is reasonable during the image generation.
Add the "--select-higher-version" option to let the user have another
choice, the default is no.
[YOCTO #2575]
(From OE-Core rev: 0a80a02644f624443cef8cc4f604edb5ef8e6975)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a simple upgrade. Dropping the unneeded patches
and adding --disable-werror to configure since thats is
what one of the patch was doing which was dropped.
(From OE-Core rev: 452f26b6d189b9fafba644e41921091925fb6a47)
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>
* use SRCREV from opkg_svn.bb, because with 596 patches we have won't apply
(From OE-Core rev: 2bf865a9b89eb88c3f7c754362315841195cd8ca)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* it was triggered by c02364f36e228835ea5d7fd4e1d347fd451f8544 when new package had 2 entries in Provides and old version just 1
(From OE-Core rev: d98d6ec9425bd8764405c9812cddfcfd2a2b025b)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Remove opkg_0.1.8.bb and the related files since it doesn't work:
- It doesn't support the "--force_postinstall" option which is used by
package_ipk.bbclass.
- It still doesn't work after remove the "--force_postinstall" option,
it can't install the packages in complementary_pkgs.txt.
[YOCTO #3136]
(From OE-Core rev: 526da07578de2c6261d21bc339bca0d3b94d93cf)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The rpm should depend on bison-native, otherwise errors when "bitbake
rpm-native" in a fresh build:
| make[4]: Entering directory `/path/to/rpm-native-5.4.9-r46/rpm-5.4.9/syck/lib'
| bison -d -t -v -p syck -o gram.c gram.y
| make[4]: bison: Command not found
Basically, both the rpm-native and rpm should depend on bison-native,
but don't need depend on bison, but it seems that it isn't necessary
to add another depend line:
DEPENDS_virtclass-native = "libpcre-native ... bison-native"
So just add it to the DEPENDS.
[YOCTO #3123]
(From OE-Core rev: 839faed2e7ef554668f647732c7ee1c8d339c123)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This takes advantage of new bitbake functionality to clean up stale stamp
files when creating new stamp files.
[YOCTO #2961]
(From OE-Core rev: e21b6c04e512a3bc2339a20045b7041f1d26e859)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When processing dependencies, we need to look for both the SW_INSTALL and
SW_UNKNOWN states. If we don't do this, dependencies can be missed
and preinst scripts can run before dependencies are all installed.
This leads to package installation errors for packages like dbus-1
and associated user permission errors.
(From OE-Core rev: 119ef2789484222b94559675a09adc399f3b6bf0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These are fixes mainly cherrypicks for mips/ppc/x86
mainly fixing PRs in ld and gold
(From OE-Core rev: f098cfc24bae8e0685bcae53ea4fdc3326ddc6c4)
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>
There were a number of cases where pseudo used plain old stat()
to get dev/inode data for files; on 32-bit hosts, this could fail
if the files were over 2GB, causing pseudo to prevent removing of
large files. This is fixed in 1.4.1.
(From OE-Core rev: 056eddc4299d10ddafe0da3dc768bd80d0c1b96b)
Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Git requires python by default as an included script to link git
to perforce is written in Python. Define NO_PYTHON to stop the
script being included and thus remove the dependancy on Python.
(From OE-Core rev: 602538e1c8403e8b188109ce94a906a1d9090d7e)
Signed-off-by: Jack Mitchell <jack.mitchell@dbbroadcast.co.uk>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
following is the error message:
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from /lib/ld-2.13.so:
--2263-- Can't make sense of .got section mapping
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from /home/root/lzh:
--2263-- Can't make sense of .data section mapping
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from /usr/lib/valgrind/vgpreload_core-ppc32-linux.so:
--2263-- Can't make sense of .data section mapping
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from /usr/lib/valgrind/vgpreload_memcheck-ppc32-linux.so:
--2263-- Can't make sense of .data section mapping
--2263-- WARNING: Serious error when reading debug info
--2263-- When reading debug info from /lib/libc-2.13.so:
--2263-- Can't make sense of .data section mapping
(From OE-Core rev: 14626cc76210ed6fe40316a311f24147ed8de8be)
Signed-off-by: Zhenhua Luo <b19537@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
User mode emulation binaries are linked using a local linker script. The
nativesdk ones were not used and the resulting binaries did not have the
interp section resized. Hence, those binaries could not be relocated.
[YOCTO #3083]
(From OE-Core rev: da014e900adfe96f01290c5a8f5fb08e295ca204)
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This makes the libgcc builds identical when done with gcc-cross-initial
or final gcc-cross. Since eglibc only sees gcc-cross-initial it is
important that the final libgcc that appears on root file system is same
as the one against which eglibc was built.
(From OE-Core rev: bd0ab094d6c36b55848e23e63b96587773299a7f)
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>
arm patch is a forward port from OE/classic
ppc patch should help in building images with Os
(From OE-Core rev: ac9ebcea4a2b778f6dd103a729831d9a9be281df)
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>
This module is, apparently, included in the standard perl distribution
since 5.10.1 or so. The regular perl recipe has had this PROVIDES for a
while but it seems to have been overlooked in the native version.
(From OE-Core rev: 2c3e8c5ab098f84c77729377afc240bc71d81665)
Signed-off-by: Phil Blundell <pb@pbcl.net>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Matthew McClintock
Richard Purdie
Phil Blundell
Martin Jansa
Mark Hatle
Khem Raj
Christian Glindkamp
Elizabeth Flanagan
Saul Wold
Laurentiu Palcu
Constantin Musca
Robert Yang
Peter Seebach
Jack Mitchell
Zhenhua Luo