| Age | Commit message (Collapse) | Author |
|---|
|
We need this to avoid symbol mismatch issues for binaries that use this
on newer systems which then won't run on older ones where it isn't present.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
packages like fontforge-native fail with mysterious errors like
| ../../git/inc/gwwiconv.h:44:21: error: conflicting types for ‘gww_iconv_close’
| #define iconv_close gww_iconv_close
| ^~~~~~~~~~~~~~~
| ../../git/inc/gwwiconv.h:37:13: note: previous declaration of ‘gww_iconv_close’ was here
| extern void gww_iconv_close( gww_iconv_t cd);
| ^~~~~~~~~~~~~~~
The reason behind this is that a check for iconv fails during native
configure run, the check fails because the autoconf test to check for iconv
pokes for these gconv's in test runs before declaring iconv support successful.
Therefore when uninative is active the package fails to build but when
uninative is inactive all works fine. this patch fixes that
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Fedora28[1] has decided to go ahead and use libxcrypt to replace libcrypt from glibc
despite the change not having merged into glibc upstream yet. This breaks the use of
uninative in OE on fedora28 since binaries there are now using new symbols only found
in libxcrypt. libxcrypt is meant to be backwards compatible with libcrypt but not the
reverse.
Since this will impact OE in the next release cycle, this changes nativesdk only
to use this new model and adds libxcrypt to work in that case. This allows us to
build a uninative which is compatible with fedora28 and previous other OSes.
In order to work, recipes will now need to depend on virtual/crypt where they use
libcrypt since its now a separate library and we can't depend on it from glibc to
preseve backwards compatibility since glibc needs to build first. For now, only the
problematic nativesdk recipes have been fixed up. For target use, the default
provider remains glibc for now. Assuming this change is merged into upstream glibc,
we will need to roll this change out for the target but we will do this in the next
release cycle when we can better deal with the resulting bugs.
[1] https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt
Original patch from Charles-Antoine Couret <charles-antoine.couret@essensium.com>,
tweaked by RP to add virtual provides, SkipRecipe for libxcrypt and other minor
tweaks.
Signed-off-by: Charles-Antoine Couret <charles-antoine.couret@essensium.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
They are redundant since nopackages are being inherited.
Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The windres binutils binary which is used for Windows resource files
requires utf-16 and cp1252 encoding support in order to correctly
generate resource files with strings. As such when using uninative to
build mingw resources for a nativesdk target the windres binary is
executed on the native host, thus using the uninative libc and gconv
modules.
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
LICENSE and LIC_FILES_CHKSUM apply to the sources specified by SRC_URI,
not to the recipe itself. As such a license declaration for a source-less
recipe makes little sense. The LICENSE declaration is mandatory, but
LIC_FILES_CHKSUM can be removed in such cases.
Remove the LIC_FILES_CHKSUM declarations from all recipes that do not
need it.
CC: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Olaf Mandel <o.mandel@menlosystems.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
We still have problems where deploying SDKMACHINE=i686 can cause removal
of SDKMACHINE=x86_64 artefacts.
The reason is that x86_64 is a BUILD_ARCH as well as an SDK_ARCH and
the manifest namespaces overlap. To fix this, set PACKAGE_ARCH and
the stamp-extra-into to include SDK_OS. SDK_OS may not be entirely correct
but it is what sstate.bbclass uses for nativesdk and fixing that is
a separate issue.
This is confirmed to resolve artefact problems on the AB which have been
delaying a new uninative release.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The uninative tarball only contains nativesdk compoents. It should
not get regenerated when MACHINE changes for example. Currently its
sstate arch is also incorrect so changing SDKMACHINE results in other
variants being removed from the deploy directory.
This patch removes the target architecture dependencies so that
deploy artefacts can overlap and it doesn't continually rebuild. This
also fixes various autobuilder/release artefact issues we're having
as a result of these issues.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Otherwise the stamps for x86-64 and i686 uninative tarballs match
and we can't deploy both to the DEPLOYDIR.
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
under sstate control
Firstly, these recipes are not target (MACHINE) specific so they should
by SDK_ARCH based, not PACKAGE_ARCH.
Also fix use of SDK_DEPLOY -> SDKDEPOLYDIR after other recent changes.
Together these fixes avoid various build failures and ensure the tarballs
only get built once rather than multiple times.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
xrange() no longer exists in python 3, use range()
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
So that a single machine can build multiple architectures for the
uninative-tarball respect SDK_ARCH instead of BUILD_ARCH.
This means a x86-64 host can build a i686 uninative-tarball by setting
SDKMACHINE=i686.
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
This task is meaningless for uninative-tarball as the package task
has been deleted. Besides, sometimes it would cause problems. To
reproduce, use the following command.
bitbake uninative-tarball -c cleansstate && bitbake uninative-tarball &&
bitbake uninative-tarball -c clean && bitbake uninative-tarball
The error is something like below.
File: 'sstate.bbclass', lineno: 33, function: sstate_installpkg
0029: bb.build.exec_func(f, d)
0030:
0031: for state in ss['dirs']:
0032: prepdir(state[1])
*** 0033: os.rename(sstateinst + state[0], state[1])
0034: sstate_install(ss, d)
0035:
0036: for plain in ss['plaindirs']:
0037: workdir = d.getVar('WORKDIR', True)
Exception: OSError: [Errno 2] No such file or directory
[YOCTO #7597]
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
|
|
DEPENDS doesn't actually add the dependency on patchelf-native to the
populate_sdk task. SDK_DEPENDS does this, but move the append to after
inheriting the base class so it does not get overwritten.
Without this, uninative-tarball fails to build in a clean workspace on a
system without patchelf.
[YOCTO #7467]
Signed-off-by: Tyler Hall <tylerwhall@gmail.com>
Acked-by: Randy Witt <randy.e.witt@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
uninative.bbclass uses -xjf for decompression so actually run the data
through bzip2.
Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
These patches are the start of a new idea, a way of allowing a single set of
cross/native sstate to work over mutliple distros, even old ones.
The assumption is that our own C library is basically up to date. We build
and share a small tarball (~2MB) of a prebuilt copy of this along with a
patchelf binary (which sadly is C++ based so libstdc++ is in there). This
tarball can be generated from our usual SDK generation process through
the supplied recipe, uninative-tarball.
At the start of the build, if its not been extracted into the sysroot, this
tarball is extracted there and configured for the specified path.
When we install binaries from a "uninative" sstate feed, we change the
dynamic loader to point at this dynamic loader and C librbary. This works
exactly the same way as our relocatable SDK does. The only real difference
is a switch to use patchelf, so even if the interpreter section is too small,
it can still adjust the binary.
Right now this implements a working proof of concept. If you build the tarball
and place it at the head of the tree (in COREBASE), you can run a build from
sstate and successfully build packages and construct images.
There is some improvement needed, its hardcoded for x86_64 right now, its trivial
to add 32 bit support too. The tarball isn't fetched right now, there is just a
harcoded path assumption and there is no error handling. I haven't figured
out the best delivery mechanism for that yet. BuildStarted is probably not
the right event to hook on either.
I've merged this to illustrate how with a small change, we might make the
native/cross sstate much more reusable and hence improve the accessibility
of lower overhead builds. With this change, its possible the Yocto Project may
be able to support a configured sstate mirror out the box. This also has
positive implications for our developer workflow/SDK improvements.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
Richard Purdie
Khem Raj
Ming Liu
Nathan Rossi
Olaf Mandel
Joshua Lock
Ross Burton
Randy Witt
Chen Qi
Tyler Hall