glibc 2.34 and Yocto Project's "uninative"

Richard Purdie
Fri Aug 20 14:37:55 GMT 2021


Yocto Project is a cross compiling build system used to build customised
Linux, RTOSs, firmware and more. It has some interesting technology. One piece
of it is "pseudo" ( which is an 
LD_PRELOAD which intercepts calls to libc and fakes root privileges. One way or
another we've managed to keep that working with multiple libc versions for the
last decade.

A second piece of technology is uninative. We build a lot binary artefacts, some
for the target, some as tools running natively on the build system. We have a
cache of these artefacts people can share and reuse. Uninative is our way of
allowing one binary to run on any host distro. We do that by shipping a ld+libc
binary shim and change the interpreter in the native binary to point at our own.
As long as the shim is the same version or later than system version, it works.

In glibc 2.34, the merge of libdl and libpthread into libc is causing a problem
for us. Basically, I've been able to make pseudo work and I can make uninative
work however I can't make them both work together with glibc 2.34.

Pseudo uses minimal dl calls from libdl (dlsym, dlvsym and dlerror) and has a
pthread mutex, therefore it links to -ldl and -lpthread.

The issue is that pseudo being an LD_PRELOAD, if linked against glibc 2.34
doesn't "see" symbols in libdl and just links to libc. I did try forcing older
versions of the symbols along the lines of:

__asm__(".symver dlerror,dlerror@GLIBC_" DLSYMVER);
__asm__(".symver dlvsym,dlvsym@GLIBC_" DLVSYMVER);
__asm__(".symver dlsym,dlsym@GLIBC_" DLSYMVER);

with some arch specific version number defines however even if I do this, and
put back a symlink to the lib, the linker ignores the weak wildcard
reference and links back to itself. When we then use this preloaded lib
on a system with an older libc:

relocation error: [...]/ symbol dlerror, version GLIBC_2.2.5 not defined in file with link time reference

I did try ensuring has a RUNPATH that includes our uninative libc
however the loader ignores that for loading libc. I did then add our uninative
libc path to LD_LIBRARY_PATH however that fails: symbol _dl_exception_create, version GLIBC_PRIVATE not defined in file with link time reference

since the ld being used doesn't match the libc.

Can anyone see a way we could make things work?



More information about the Libc-help mailing list