[poky] Yocto-2-2: native executables and libs pull symbols from wrong glibc.

[Kaz Kylheku (poky)]

Hi all,

I've discovered, in a Yocto-2.2-based system, that native executables 
and libraries are pulling in symbols from the build machine's own glibc.

Then when those programs and libs are executed, they use the "uninative" 
glibc that Yocto pulls from the tarball (because their built-in -rpath 
tells them to, and that -rpath is dynamically edited to point to the 
uninative stuff).

This mismatch is wrong and fails the build when those executables or 
libs have pulled in symbols from the build machine glibc that have newer 
versions than what is available in the older uninative glibc.

It seems to be case that when these programs are being linked by the 
recipe steps pulled in from native.bbclass, the linker is using the 
wrong libc.so image; it's not using the libc.so that is in 
sysroot-uninative that will be used at run-time.

Concretely, this leads to a failure when you build on a glibc-2.27 based 
system, like Ubuntu 18.04.

glibc-2.27 has advanced a number of symbols to the GLIBC_2.27 version 
node.  One of those symbols is the glob function.

glob is used in libpopt.so, libopkg.so and some other programs.

In my world, I have patched the handful of programs and libs which are 
involved in the build failure by adding this to them:

   __asm__(".symver glob,glob at GLIBC_2.2.5");

With that, I was able to build the world.  (It could be that many more 
programs are affected; but not in any way that contributes to a build 
problem in my world.)

In the case of libpopt.so, what fails is the "debugedit" utility from 
rpm-native. This utility is used by the do_package recipe of glibc, and 
so that recipe fails.

The .symver directive is an ugly workaround; this needs to be somehow 
fixed in the build system.

Cheers ...