Since we want to be able to stop unpacking to WORKDIR, correct the WORKDIR
references in recipe do_compile/do_install tasks to use UNPACKDIR in the
appropraite places instead.
(From OE-Core rev: d73595df69667fe9d12ecd407b77a0b8dae2109c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
An automated conversion using scripts/contrib/convert-spdx-licenses.py to
convert to use the standard SPDX license identifiers. Two recipes in meta-selftest
were not converted as they're that way specifically for testing. A change in
linux-firmware was also skipped and may need a more manual tweak.
(From OE-Core rev: ceda3238cdbf1beb216ae9ddb242470d5dfc25e0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is the result of automated script conversion:
scripts/contrib/convert-overrides.py <oe-core directory>
converting the metadata to use ":" as the override character instead of "_".
(From OE-Core rev: 42344347be29f0997cc2f7636d9603b1fe1875ae)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When building pseudo-native to work with uninative, we need to ensure the
configuration will work on all supported target systems. This means
"new clone" semantics, xattr and statvfs support in particular. It is
extremely unlikely we'd run on a system without any of these but add
a check just to be sure when uninative is enabled.
(From OE-Core rev: ea5b208ee25752bea6037cd0f3b28da7d2c9905e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added HOMEPAGE and DESCRIPTION for recipes with missing decriptions or homepage
[YOCTO #13471]
(From OE-Core rev: bb05814335e7101bfd8df0a11dc18a044e867bed)
Signed-off-by: Dorinda Bassey <dorindabassey@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
pseudo-native is special in that bitbake ends up executing it from the
sysroot-components directory before we have any workdirs for the bitbake
fakeroot worker. Since we switched to dynamically linking sqlite, it
means sqlite from the host system may be found, we really want the version
in sysroot-components. Trying to run tasks to create some special environment
for pseudo is hard and error prone. The simplest fix is to add an RPATH to
the binary so that it can correctly find the sqlite we want.
Unfortunately passing $ORIGIN into make doesn't work so well with shell
quoting so we have to fix that during do_install.
[YOCTO #13814]
(From OE-Core rev: 3937ca9e2dfabb1ce9bce1d536b60b1e2a43739b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Back in 2010[1] we made pseudo statically link against sqlite3. Since then
the world has changed, pseudo now has separate processes for the database
in the server and the client and they have separate linking commands.
Also, whilst there were concerns about needing specific versions of sqlite3,
in the OE environment, this is always the case.
[1] http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=ad0ac0ecd38fc77daf42485489fccc10a5e1e3e7
The static sqlite3-native is causing us problems, in particular:
tmp/work/x86_64-linux/pseudo-native/1.9.0+gitAUTOINC+060058bb29-r0/recipe-sysroot-native/usr/lib/libsqlite3.a(sqlite3.o):(.data.rel+0xb0): undefined reference to `fcntl64'
which occurs if sqlite3-native was built on a machine with glibc 2.28 or later
and pseudo-native is being built on glibc before that. With dyanmical linking,
libc is backwards compatible and works but with static linking it does not.
There appears to be no easy way to avoid this other than adding a copy of
sqlite3 into the pseudo recipe. Given the static linking doesn't seem to
be required any longer due to the separate processes, drop that to fix
those issues.
(From OE-Core rev: a0c238d40a9cc1f87da0607fddaaef0c31d93720)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
While working with ostree disk generation in conjunction with wic, I
found a problem with pseudo where it tried to resolve a symlink when
it shouldn't, based on openat() flags. A C program has been
constructed to test pseudo to show that it is working properly with
the correct behavior around openat().
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <dirent.h>
#include <unistd.h>
#include <fcntl.h>
int main()
{
/*
* Tested with: gcc -Wall -o app app.c ; echo "no pseudo" ;
* ./app ; echo "pseudo"; pseudo ./app
*/
system("rm -rf tdir tlink");
system("mkdir tdir");
system("ln -s tdir tlink");
DIR *dir = opendir(".");
int dfd = dirfd(dir);
int target_dfd = openat (dfd, "tlink", O_RDONLY | O_NONBLOCK |
O_DIRECTORY | O_CLOEXEC | O_NOFOLLOW);
if (target_dfd == -1) {
printf("Test 1 good\n");
} else {
printf("Test 1 failed\n");
close(target_dfd);
}
target_dfd = openat (dfd, "tlink", O_RDONLY | O_NONBLOCK |
O_DIRECTORY | O_CLOEXEC);
if (target_dfd == -1) {
printf("Test 2 failed\n");
} else {
printf("Test 2 good\n");
close(target_dfd);
}
/* Test 3 make sure the owner of the link is root */
struct stat sbuf;
if (!lstat("tlink", &sbuf) && sbuf.st_uid == 0) {
printf("Test 3 good\n");
} else {
printf("Test 3 failed\n");
}
/* Test 4 tests open with the "rb" flag, owner should not change */
int ofd = openat(dfd,"./tlink", O_RDONLY|O_CLOEXEC);
if (ofd >= 0) {
if (fstat(ofd, &sbuf) != 0)
printf("ERROR in fstat test 4\n");
else if (sbuf.st_uid == 0)
printf("Test 4 good\n");
close(ofd);
} else {
printf("Test 4 failed with openat()\n");
}
/* Test pseudo db to see the fstat() above did not delete the DB entry */
if (!lstat("tlink", &sbuf) && sbuf.st_uid == 0)
printf("Test 5 good\n");
else
printf("Test 5 failed... tlink is owned by %i and not 0\n", sbuf.st_uid);
return 0;
}
int main()
{
/* Tested with: gcc -Wall -o app app.c ; echo "no pseudo" ; ./app ; echo "pseudo"; pseudo ./app */
system("rm -rf tdir tlink");
system("mkdir tdir");
system("ln -s tdir tlink");
DIR *dir = opendir(".");
int dfd = dirfd(dir);
int target_dfd = openat (dfd, "tlink", O_RDONLY | O_NONBLOCK | O_DIRECTORY | O_CLOEXEC | O_NOFOLLOW);
if (target_dfd == -1) {
printf("This is right\n");
} else {
printf("This is broken\n");
}
return 0;
}
Many thanks to Peter Seebach for fixing the problem in the pseudo code
to use the same logic which was already there for the
AT_SYMLINK_NOFOLLOW.
Also updated is the license MD5 checksum since the master branch of
pseudo has had the SPDX data updated.
(From OE-Core rev: a98ea4be5ce19ff380ca500ba1ef3da490ec4556)
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If sqlite3 is built with FTS5 it uses log() from libm, it sqlite3 is built
with READLINE it uses tgetent from a curses lib and readline from libreadline,
if it is built using deflate from libz ... , but all that linkage is lost
if we manually statically link so explicitely extract extra static linking
options from pkg-config and force them into pseudo as well.
This commit obsoletes (so include the implicit revert)
e39fec613d pseudo: fix link with new sqlite3
(From OE-Core rev: 042af406583acc091ef82c3d1dcedd41315046de)
Signed-off-by: Jens Rehsack <sno@netbsd.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Pseudo is using a custom configure script that detects if it shall build with
extended file attribute support or not. The check is done by simply calling
'getfattr' provided by attr-native which is not part of the dependency list.
Due to the recent changes (recipe specific sysroot & cleanup of $PATH) this
call fails now when the recipe is being build for the first time (at least
when being build for nativesdk case). Explicitly setting up a dependency to
attr-native just to satisfy configure would be wrong also since the real
dependency is to attr/nativesdk-attr which are already part of the dependency
list (see DEPENDS). Therefore bypass the test in the configure by explicitly
enabling xattr using a configure option available in any case.
(From OE-Core rev: a7381eb16ba2183ed990a009bb8e82b4702f3d98)
Signed-off-by: Andreas Kaufmann <andreas.kaufmann.79@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Drop patches where the changes exist upstream
* Fetch from git as no tarball is available for 1.8.1
* Move common code to pseudo.inc
* Update patchset in git recipe
(From OE-Core rev: 0c36984d4c501d12fa91cf7371511641585cc256)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Setting rpath causes clash of host and sdk libc and makes
pseudo to crash with relocation error: libpthread.so.0:
symbol __libc_vfork, version GLIBC_PRIVATE not defined
in file libc.so.6 with link time reference
Removing rpath fixes this as it makes pseudo to use only host
pthread and libc.
[YOCTO #9761]
(From OE-Core rev: be5c943e82a21d3ef2dfaaa5b41b6a2814f2fb19)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With the autodebug package generation logic, specifically setting FILES_${PN}-dbg
isn't needed in most cases, we can remove them.
(From OE-Core rev: 3ab59d49dd7c18e194b58d1248b4b87709b5a738)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We really want the same sstate checksums for pseudo-native on 32 and 64 bit platforms
but the use of SITEINFO_BITS prevents this. Since other things would change if
the bit size changes, we can safely exclude this variable and rely on others
(e.g. BUILD_ARCH included in WORKDIR) to handle this.
[YOCTO #5970]
(From OE-Core rev: 4caf6187bb52d4f6f92ea0959e90339b82ac92b8)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This uprevs pseudo to 1.6. This merges in all of the existing
fixes, and also adds partial support for extended attributes,
including storing arbitrary extended attributes in the database,
and also interpreting the posix permissions ACLs as chmod
requests.
The extended attribute support means we need xattr.h, the simplest
way to be sure of this is to build attr before pseudo, which doesn't
take long.
(From OE-Core rev: b8f5d6b493ec759a97b92cf9b4c07ad8a8114de6)
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>
The virtclass overrides will go away at some point (apart from the multilib one).
Change them all to class-xxx instead since people enjoy copy and pasting them.
(From OE-Core rev: d1c073d2813bd913617990cd047507353ea0c09e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A lot of our recipes had short one-line DESCRIPTION values and no
SUMMARY value set. In this case it's much better to just set SUMMARY
since DESCRIPTION is defaulted from SUMMARY anyway and then the SUMMARY
is at least useful. I also took the opportunity to fix up a lot of the
new SUMMARY values, making them concisely explain the function of the
recipe / package where possible.
(From OE-Core rev: b8feee3cf21f70ba4ec3b822d2f596d4fc02a292)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
libpseudo.so is always installed into ${prefix}/lib/, not ${libdir},
so fix these paths; and skip libdir WARN_QA checking to ignore the
warning in 64bit and multilib enabled system
(From OE-Core rev: 47c7850c025994685aa1811057f4f9a5f0f2a3ae)
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Putting a warning at the top of do_compile is useful but not everyone reads the
file from beginning to end, so use a trap to put the message at the bottom too.
[ YOCTO #4919 ]
(From OE-Core rev: 51950fcbe4b98bdbb8b3dde88a8729e540d9609f)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In the future bbnote/bbwarn will be integrated into bitbake's logging, so use
those functions instead of echo directly.
(From OE-Core rev: 4933d7ae45d88090191c8ea07fd109ed34925e2d)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The exported SDK only needs simulated root privileges for specific
tasks, such as the user-mode NFS server or rootfs extraction, and
oe-core does not support multilib builds in the generated SDK, so
it is neither necessary nor possible to build a 32-bit libpseudo.so
for a 64-bit SDK.
[YOCTO #5135]
(From OE-Core rev: 908b179b798704db74c886ec4c70c0942b09cb00)
Signed-off-by: Randy MacLeod <Randy.MacLeod@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is for Yocto bug #4920. The NO32LIBS variable is intended to allow
the user to force the creation of a 32-bit libpseudo, for use with things
like prebuilt binary toolchains. Unfortunately, the tests for likely
compilability (stubs-32.h) were still present, so you would get silent
failures. And if you did cause it to try to build, the failures were not
particularly clearly explained.
So, we:
1. Emit at least a message during configuration saying we're only
building 64-bit, if we are.
2. Warn the user for at least one common case where we know builds
are likely to fail.
3. If NO32LIBS is 0, we try the compile for sure, and if it fails,
we've emitted at least some sort of message up near the top of the
compile output that tells you what might be wrong.
(From OE-Core rev: 22548b3243dfa2dc9861b0f15530632b37812a8c)
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>
The pseudo 1.5 update is a moderately experimental set of changes
which ought to improve performance. With these changes, pseudo
uses an in-memory sqlite database which is lushed on exit,
the protocol is changed to reduce waiting for server responses,
and pseudo can suppress any and all fsync/fdatasync type operations.
This last feature is optional, and not on by default, so we need
to pass in an extra configure argument, but that argument wouldn't
be known to an older configure, so... Enter PSEUDO_EXTRA_OPTS which
is passed to configure, and which pseudo_1.5.bb sets by default to
"--enable-force-async". (I haven't added it in pseudo_git.bb, but
maybe it should be changed; I'm not quite as sure there.)
The justification for these changes is that, for most of the real-world
build cases I deal with, they produce a 25% or more reduction in the
build time of a project. This increases when a system is heavily
loaded.
(From OE-Core rev: 79ddb0c33401da442dbaa8e0d73ebacf297d9185)
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>
This updates to pseudo 1.4.3. Changes:
1. A couple of minor tweaks to reduce difficulties using SDKs built
on slightly more recent machines on older machines; specifically,
avoiding getting @GLIBC_2.7 symbol references for sscanf(), fscanf(),
and open2().
2. Revision of the logic determining the library directory to use for
sqlite's library files.
The latter is a source of difficulty because it's come up a few times
that we may want pseudo to use lib64 for libpseudo.so, but bitbake's
usual setup would have libsqlite3.a in lib regardless of bit width.
Cleaned up previous design a bit by providing a distinct setting for
sqlite-lib, which defaults to the same library directory used for other
things. Adjusted build to use this new setting. (This ends up being
${baselib}; on targets, that might not be lib, but for native builds
it generally is, and for SDK builds it appears to do the right thing.)
Testing: Successful build of meta-toolchain for both 64-bit and 32-bit
SDKMACHINE, and builds with NO32LIBS = "0" also succeeded. Also builds
for multilib targets.
(From OE-Core rev: ae8811bb26fba2e71d7280f6d6c4f5cec6a2871b)
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>
The overrides virtclass-native and virtclass-nativesdk are deprecated,
which should be replaced by class-native and class-nativesdk.
[YOCTO #3297]
(From OE-Core rev: bb67ddeb2eed3e25c626a279ef53a7e8c7bfe6f2)
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>
When NO32LIBS = 0, building 32-bit version of pseudo-native and
building on a 64-bit host -- if the build was triggered by a
dependency change on something pseudo uses, the build could fail
due to left over files from the previous build. Fix this by
ensuring we run make distclean (and ignoring any failure codes) to
ensure we start over.
(From OE-Core rev: 30ae7320265efe039730cd2faf7bd86a264412ed)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This update replaces the half-baked --arch logic with the use
of $CFLAGS to pick compiler flags, on the grounds that it makes
a lot more sense for the build system to pick flags than for
pseudo to try to guess what they should be; this should allow
pseudo to at least compile for targets, and possibly run on
them.
This doesn't solve the problem of guessing how to forcibly
build the 32-bit variant on hosts, because we really don't
have a general solution for that. There's no idiom for "given
this set of compiler flags and this architecture, what flags
would you use to request a 32-bit compile instead?" So we
basically ignore that for now. If someone comes along trying
to use the build system to build pseudo-native on a 64-bit
host that also supports 32-bit binaries and isn't x86, we
will revisit this.
(From OE-Core rev: 711fcb4f10e2cefd7ff6e1921d87d1cad840d0c8)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The -nativesdk pseudo wrapper setting LD_LIBRARY_PATH turned out to be a
bad idea since it can mix up different libc and lib-dl verisons which
may or may not work depending on the phase of the moon.
As an alternative to solving the original problem, this patch drops the
symbol version requirement on memcpy which allows pseudo to work with
libc's back to 2.7 which should be sufficient for our supported targets
using nativesdk.
[YOCTO #2299]
[YOCTO #2351]
(From OE-Core rev: c6c701f424aeb502d20ff02d02712e56f4e259a5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There can be a conflict between the nativesdk libc and the host system's
libc. It is assumed the nativesdk version is of an equal or higher version.
This is a particular issue for pseudo if its loading a system binary
since the system's libc might be used of an older verison which would
then confuse libpseudo.so when loaded as a preload.
To avoid this, set LD_LIBRARY_PATH so the nativesdk libc is always
used.
Since we now use --without-rpath, we can remove the MAKEOPTS RPATH workaround.
[YOCTO #2299]
(From OE-Core rev: a481fe3b9883aa744be3253e2b4b27e6e46eb059)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If this value is not set to 1, then systems with some 32-bit libraries
but no 32-bit version of libgcc installed will have pseudo-native fail
at do_compile. It should only really be set to 0 by those who know what
they are doing.
(From OE-Core rev: 489a36d3d6b67d706f5918638e1fbc05ccd59e21)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[Yocto #2251]
Add --without-rpath to avoid embedding rpaths into the pseudo
components.
(From OE-Core rev: ae978e9671fdbcb31e306308bfb816b4bd2b2496)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The various local patches have made it into upstream, so we update
the build files and jump to pseudo 1.3. This also includes a popen()
fix which fixes some edge cases that caused failures trying to check
git branches and the like.
[Yocto bug #2181]
(From OE-Core rev: 0b007519fcfb1bcf2be9cad40b0f6265f8798518)
Signed-off-by: Seebs <peter.seebach@windriver.com>
Updated the pseudo_git.bb to match.
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixed the "not shipped" packaging warnings.
WARNING: For recipe pseudo-nativesdk, the following files/directories
were installed but not shipped in any package:
WARNING: /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/var
WARNING:
/opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/var/pseudo
(From OE-Core rev: 91f6d5777e4fc9f261c361f41eda397a4903b334)
Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This fixes two QA warnings:
a) Debug files being contained in the main package (by adding
an appropriate FILES expression)
b) Stop hardcoding the RPATH in the nativesdk case since our
path is on the loaders default search path
(From OE-Core rev: 1577975202437f8f89ef24a5e4d3f6c6c8a88c5c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Update both the core and pseudo_git packages to the latest 1.1.1 verison.
This fixes an issues where the call system() was not wrapped. This could
lead to issues where certain spawned commands broke out of a pseudo-chroot
and created files in the wrong place.
Also the update the 1.0 -> 1.1.1 adds additional capabilities such as
beginning support for MacOS X.
(From OE-Core rev: 9eaa9ed38a197be76317cd3e42f54d1808c3e971)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Not using the git version has the advantage of removing several early bootstrap
dependencies such as git-native (which pulls in perl and openssl).
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
