linux/poky.git/meta/classes, branch yocto-2.4.3

package.bbclass: Add '-b' option to file call in isELF

2018-05-08T14:37:17+00:00

The isELF function works by running: result = file if 'ELF' in result By default 'file' will prepend the result with the path name of the file that is being checked. This usually works fine, such as: $ file /home/foo/openembedded-core/meta/classes/package.bbclass /home/foo/openembedded-core/meta/classes/package.bbclass: Python script, ASCII text executable, with very long lines However, if the path includes 'ELF', ELF will end up in the result, and then the check will return positive. $ file /home/ELF/openembedded-core/meta/classes/package.bbclass /home/ELF/openembedded-core/meta/classes/package.bbclass: Python script, ASCII text executable, with very long lines This will then result in the isELF coming back true, and possibly causing the checks that use isELF, such as the 'is it already stripped' check, to do the incorrect thing. Adding the '-b' option to file will result in the path being omitted in the result: $ file /home/ELF/openembedded-core/meta/classes/package.bbclass Python script, ASCII text executable, with very long lines (From OE-Core rev: b6d5729a0f0e6f2c8b36d425a18e9e2ed26f5de0) Signed-off-by: Mark Hatle Signed-off-by: Ross Burton (cherry picked from commit 5a324e9b2cf6378f8eaa4e394f9cb36d4e2680ac) Signed-off-by: Richard Purdie

package.bbclass: use single quotes for path passed to file in isELF()

2018-05-08T14:37:17+00:00

Apparently there are recipes in the wild which generate files with filenames containing '$' characters - which cause errors during packaging. Instead of adding another special case to escape '$' characters when constructing the command passed to oe.utils.getstatusoutput(), switch to using single quotes to quote the path - and therefore make isELF() consistent with the way filenames and paths are quoted by every other caller of oe.utils.getstatusoutput() in oe-core. (From OE-Core rev: 080f0ee910684beb8bc263d5a45d3aa39b6ee647) Signed-off-by: Andre McCurdy Signed-off-by: Ross Burton (cherry picked from commit 7877761534b0c2492da6289e9f2269d41b6ed464) Signed-off-by: Richard Purdie

Revert "package.bbclass: Add '-b' option to file call in isELF"

2018-05-08T14:37:17+00:00

This reverts commit 46ddc11a8be79515b4ab9f9f7568c3d624ac72fe. The change is good in master but became subtly broken during the backport to rocko. Either the path passed to file should be quoted using double quotes (with any " chars in the path being escaped) or the path should be quoted using single quotes (and then any " chars in the path should NOT be escaped). Escaping " chars and using single quotes will cause problems for filenames containing " chars. (From OE-Core rev: 534a4e6775e5b4030619b20ae1f6a319adadccf5) Signed-off-by: Andre McCurdy Signed-off-by: Richard Purdie

Revert "waf.bbclass: explicitly pass bindir and libdir if supported"

2018-05-07T14:57:37+00:00

* this doesn't work correctly as discussed in: http://lists.openembedded.org/pipermail/openembedded-commits/2018-January/218460.html * some of the issues were fixed in master since then but not all, so revert it until it's completely resolved This reverts commit eac21f981337bfaddb2d67161a1ff049158041ce. (From OE-Core rev: 74c26c2f63121d92d50b0cca4d3288b8d196b777) Signed-off-by: Martin Jansa Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

uninative: Set the dynamic linker to use at compile time

2018-05-03T08:53:49+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) (From OE-Core rev: cead3c4925d39f8adc328007d8a8c1b23cc72842) Signed-off-by: Richard Purdie Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

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

2018-05-03T08:53:49+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) (From OE-Core rev: 4545f5436a5a106154680825ecb1cb60437faa91) Signed-off-by: Richard Purdie [Clean up for Rocko context] Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

package.bbclass: Add '-b' option to file call in isELF

2018-05-03T08:53:49+00:00

The isELF function works by running: result = file if 'ELF' in result By default 'file' will prepend the result with the path name of the file that is being checked. This usually works fine, such as: $ file /home/foo/openembedded-core/meta/classes/package.bbclass /home/foo/openembedded-core/meta/classes/package.bbclass: Python script, ASCII text executable, with very long lines However, if the path includes 'ELF', ELF will end up in the result, and then the check will return positive. $ file /home/ELF/openembedded-core/meta/classes/package.bbclass /home/ELF/openembedded-core/meta/classes/package.bbclass: Python script, ASCII text executable, with very long lines This will then result in the isELF coming back true, and possibly causing the checks that use isELF, such as the 'is it already stripped' check, to do the incorrect thing. Adding the '-b' option to file will result in the path being omitted in the result: $ file /home/ELF/openembedded-core/meta/classes/package.bbclass Python script, ASCII text executable, with very long lines (From OE-Core rev: 5a324e9b2cf6378f8eaa4e394f9cb36d4e2680ac) (From OE-Core rev: 46ddc11a8be79515b4ab9f9f7568c3d624ac72fe) Signed-off-by: Mark Hatle Signed-off-by: Ross Burton Signed-off-by: Richard Purdie [fixup for Rocko] Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

gio-module-cache.bbclass: pass in ${libexecdir}

2018-05-03T08:53:48+00:00

When it was something else than /usr/libexec (e.g. when installing native SDK packages), things broke down. (From OE-Core rev: d99e819a6cbde6d1116c434ddba4c5f8eca7e6d8) (From OE-Core rev: 1c8c163bfb736518f66276eca5765c493b8cc787) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

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

2018-05-03T08:53:48+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) (From OE-Core rev: ca52b8e4f32063234815493746c4059392862af8) Signed-off-by: Cuero Bugot Signed-off-by: Richard Purdie Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

package_rpm: set _builddir to B not S

2018-05-03T08:53:48+00:00

Recipes which use a shared workdir (e.g. gcc-runtine and libgcc) can race over temporary files causing interesting build failures. Using B instead of S avoids this problem. [YOCTO #12605] (From OE-Core rev: d6c13a5ff441f7076eb327c0d0b747bd7603db0f) (From OE-Core rev: 9c72ddb605f1f4fc98fa427e37b5ba8c8758c6cd) Signed-off-by: Richard Purdie Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie