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.

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.

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.

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>

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

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 ]

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.

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]

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.

Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>

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.

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.

Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>