linux/poky.git/meta/classes/uninative.bbclass, branch hardknott

uninative: Add version to uninative tarball name

2021-12-05T12:35:43+00:00

uninative works via hashes and doesn't need the version in the tarball name but it does make things easier to inspect in DL_DIR. There were reasons such as ease of publication of the build tarballs but we can handle those differently now and the signature issues from the early code aren't an issue now. From 3.4 onwards we can use a version'd name. [YOCTO #12970] (From OE-Core rev: e3ba0041ccb9633ec21241cb6852aa50c2663677) Signed-off-by: Richard Purdie (cherry picked from commit dadba70d6a24d8ebb5576598efffa973151c7218) Signed-off-by: Anuj Mittal Signed-off-by: Richard Purdie

uninative: Improve glob to handle glibc 2.34

2021-10-29T10:17:21+00:00

With glibc 2.34, the libraries were renamed. Tweak the glob to support both as this is needed for newer uninative versions. [RP: tweak commit message] (From OE-Core rev: f60da44d32a579f5ba5c95dd60f80d624de39ce4) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie (cherry picked from commit 98248306e4b5f023e96375293b60524574ebb686) Signed-off-by: Anuj Mittal Signed-off-by: Richard Purdie

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