Re: glibc 2.34 and Yocto Project's "uninative"

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2021-08-26 at 08:16 -0300, Adhemerval Zanella wrote:
> 
> On 25/08/2021 17:11, Richard Purdie wrote:
> > On Wed, 2021-08-25 at 12:05 -0300, Adhemerval Zanella wrote:
> > > 
> > > On 20/08/2021 11:37, Richard Purdie via Libc-help wrote:
> > > 
> > > > Can anyone see a way we could make things work?
> > > I don't have easy library based solution for the requisites you posed,
> > > building a newer glibc and running on a older one.  I think what *might*
> > > work is to provide a auditor library linked against the newer glibc and
> > > it then intercepts and routes the required library calls.  You will need
> > > to redistribute the libc which the auditor was linked against.
> > 
> > The other libc is already there so that bit is easy. I hadn't thought about
> > using an auditor library and I'll have to explore that.
> 
> The auditor interface work on some examples, but unfortunately we also found
> that they are fully correct on some more specific cases.  We are aiming to fix
> for 2.35 [1].
> 

I have to admit I've not used the auditor interface before so I've a little
learning to do there! Thanks for the pointer to the patchset, it is handy to
know there are known issues.

> > I was going to go down the route of dummy libraries to link against however I
> > realised it was easier for testing just to pull down 2.33 binaries and use those
> > to link against. I did have to replace use of pthread_atfork with
> > __register_atfork which is ugly but probably okish for our use as it has been
> > there since 2.3.2.
> 
> Yes, this is what I would suggest you (use an older glibc to link this against).
> 
> > 
> > That probably gets us out the immediate problem although it does highlight we're
> > doing something that isn't supported and could break again in ways we may
> > struggle to fix. We can probably replace the pthread linkage for the mutex with
> > direct code/syscall usage. We're going to need the libdl usage regardless though
> > so it may be worth us figuring out the dummy library to link against for that
> > piece.
> 
> Why do you need to build it on a recent glibc and potentially use it on an older
> one?  
> 

We build standalone (and relocatable at install) tarballs of tools that can be
used on older distros to support our builds where we need newer tools such as
binutils/gcc/tar. We build most of our binaries against a recent libc and then
include a libc in those tarballs. We also support sharing of our "native" tools
amongst ranges of host distros using our uninative mechanism which involves
changing the interpreter to our own and using a latest libc everywhere.

pseudo is our fakeroot intercept that works via an LD_PRELOAD. We build that
against our own libc as with everything else and it will likely be more recent
that the host distro it runs on. We can't change the interpreter of binaries
from the host distro but we do need to still intercept their libc calls and it
will end up in an environment where the libc versions can be mixed.

As such, the preload portion of pseudo needs to run against older libcs.

Cheers,

Richard