public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: libc-help@sourceware.org
Subject: glibc 2.34 and Yocto Project's "uninative"
Date: Fri, 20 Aug 2021 15:37:55 +0100	[thread overview]
Message-ID: <978104bdbebcd09d159f1713499cf1315edf40f2.camel@linuxfoundation.org> (raw)

Hi,

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" (http://git.yoctoproject.org/cgit.cgi/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 libdl.so symlink to the lib, the linker ignores the weak wildcard
reference and links back to libc.so itself. When we then use this preloaded lib
on a system with an older libc:

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

I did try ensuring libpseudo.so 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:

libc.so.6: symbol _dl_exception_create, version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference

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

Can anyone see a way we could make things work?

Cheers,

Richard



             reply	other threads:[~2021-08-20 14:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-20 14:37 Richard Purdie [this message]
2021-08-25 15:05 ` Adhemerval Zanella
2021-08-25 20:11   ` Richard Purdie
2021-08-26 11:16     ` Adhemerval Zanella
2021-08-26 11:29       ` Richard Purdie
2021-08-30  6:55 ` Mike Frysinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=978104bdbebcd09d159f1713499cf1315edf40f2.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=libc-help@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).