linux/poky.git/meta/classes/uninative.bbclass, branch uninative-3.2

uninative: Fix typo in error message

2020-10-13T08:42:08+00:00

Fix typo in an error message. s/verson/version/ (From OE-Core rev: bc96db2e0b5b8a9cc2c909ea70df290e03a50b94) Signed-off-by: Naoki Hayama Signed-off-by: Richard Purdie

uninative: Handle PREMIRRORS generically

2020-08-08T08:17:49+00:00

Currently uninative handles SOURCE_MIRROR_URL but not generic PREMIRRORS. It can handle this better, attempt to iterate PREMIRRORS entries. (From OE-Core rev: 6426c952b5ade48ea94fb647efc464e603989b97) Signed-off-by: Richard Purdie

uninative: Recognise ppc64 host ldso

2020-02-02T16:57:21+00:00

(From OE-Core rev: 15f7eedf3f153f844dd64f028877aac621e040d1) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

uninative: check .done file instead of tarball

2019-10-19T22:18:33+00:00

In case multiple builds share UNINATIVE_DLDIR's location, one build might be in the process of downloading the tarball while another is just checking whether the tarball exists. Check for the done file instead and rely on the fetchers lockfile mechanism in case two builds are running. (From OE-Core rev: a1c95580549cb4f77601e62c7f026b19c752d853) Signed-off-by: Stefan Agner Signed-off-by: Richard Purdie

uninative: Switch from bz2 to xz

2019-05-30T11:37:03+00:00

(From OE-Core rev: 29fc9210b973be68de474e75068e4c72371afe5a) (From OE-Core rev: b6645596f2d2faf8f1fdfbedfe1edd004fbce6bc) Signed-off-by: Richard Purdie

uninative: Add support for aarch64 hosts

2018-09-20T16:06:00+00:00

(From OE-Core rev: b72e54b9a649faf4eb292e3bc643d5d06d4d4fea) Signed-off-by: Richard Purdie

uninative: Set the dynamic linker to use at compile time

2018-04-18T17:57:06+00:00

Its possible some dynamic runtime library in the dependency chain may come from sstate and link to libraries which need the libc from uninative. If we don't do this and binaries are run at do_install time they would fail to find the symbols from the later libc. Examples: cmake-native do_install: bin/cmake: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by TOPDIR/tmp/work/x86_64-linux/cmake-native/3.10.3-r0/recipe-sysroot-native/usr/lib/libexpat.so.1) dbus-native do_install: tmp/work/x86_64-linux/dbus-native/1.12.2-r0/build/bus/.libs/lt-dbus-daemon: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x32/build/build/tmp/work/x86_64-linux/dbus-native/1.12.2-r0/recipe-sysroot-native/usr/lib/libexpat.so.1) This issue is resolved when the interpreter is changed at sstate unpack time but this isn't soon enough to avoid issues at compile/install time. By specifing which dynamic linker/loader to use at compile time, this race window is removed entirely. (From OE-Core rev: 35867ee035030ab76fc9ccdb0eb1c3f80126301c) Signed-off-by: Richard Purdie

uninative: Add allow-shlib-undefined to BUILD_LDFLAGS and drop other workarounds

2018-04-18T17:57:06+00:00

We have a problem when for example, a glibc 2.27 based system builds some library like libpopt-native and puts it into sstate then it is reused on a pre glibc-2.27 system to build something which depends on popt like rpm-native. This results in an error like: recipe-sysroot-native/usr/lib/libpopt.so: undefined reference to `glob@GLIBC_2.27' In the past we've had this problem with new symbols like getrandom and getentropy, here its with a more complex symbol where there is an old version and a newer version. We've looked into various options, basically we cannot link against our uninative libc/ld.so since we don't have the right headers or compiler link libraries. The compiler doesn't allow you to switch in a new set either, even if we did want to ship them. Shipping a complete compiler, dev headers and libs also isn't an option. On the other hand if we follow the ld man page, it does say: """ The reasons for allowing undefined symbol references in shared libraries specified at link time are that: - A shared library specified at link time may not be the same as the one that is available at load time, so the symbol might actually be resolvable at load time. """ which is exactly this case. By the time the binary runs, it will use our uninative loader and libc and the symbol will be available. Therefore we basically have a choice, we get weird intermittent bugs, we drop uninative entirely, or we pass this option. If we pass the option, we can drop the other workarounds too. (From OE-Core rev: 75a62ede393bf6b4972390ef5290d50add19341a) (From OE-Core rev: d18bf7fa8e80d6cfaf3fdbe1ab06eec84b954432) Signed-off-by: Richard Purdie

uninative: add variables to the whitelist so that it does not re-triger recipe parsing

2018-04-03T22:53:20+00:00

When uninative is activated (poky's default) internal datastore variables are modified (NATIVELSBSTRING and SSTATEPOSTUNPACKFUNCS) to enable uninative support. This is happening after parsing is done at the beginning of the build. On the next bitbake call the recipe would be parsed if the two variables above were not added to the parsing whitelist BB_HASHCONFIG_WHITELIST. The fix is to add these two variables to the recipe parsing whitelist BB_HASHCONFIG_WHITELIST, this is done at recipe parsing time, only when uninative.bbclass is used. (From OE-Core rev: 75bb95ada98ef129d2fa48568f27dddb078c852c) Signed-off-by: Cuero Bugot Signed-off-by: Richard Purdie

uninative: Add compatiblity version check

2018-03-15T13:27:19+00:00

If glibc is newer on the host than in uninative, the failure mode is pretty nasty for clusters where the sstate is shared, including the Yocto Project autobuilder. This check aborts the use of uninative in such scenarios where a newer glibc version appears and avoids corruption of sstate caches. We use ldd to check the glibc version since that is included in libc-bin (or equivalent) which locales use so it should always be present. (From OE-Core rev: d6f6101cd0ae92e8ad2dec0bcb6db5044726edf9) Signed-off-by: Richard Purdie