On Sun, 5 Sept 2021 at 01:48, Aurelien Jarno <aurel...@aurel32.net> wrote:
> Hi,
>
> On 2021-07-15 11:11, Michael Hudson-Doyle wrote:
> > Hi,
> >
> > I know it won't be relevant to Debian for a while, but we're planning to
> > upload to the upcoming glibc 2.34 release in Ubuntu fairly soon and I
> want
> > to make sure we adapt to an upstream way in a way that is aligned with
> any
> > plans for Debian.
> >
> > The issue is this: 2.33 and previous releases install the dynamic linker
> > and libc as files with names like ld-${GLIBC_VERSION}.so and
> > libc-${GLIBC_VERSION}.so and makes symlinks from the SONAME to these
> files
> > (for example ld-linux-x86-64.so.2 -> ld-2.31.so, libc.so.6 ->
> libc-2.31.so).
> > 2.34 and later will just install the libraries directly to the SONAME
> > location.
> >
> > There is another wrinkle of course in that Debian/Ubuntu install these
> > files to /lib/$multiarch/, not /lib or /lib64 as upstream expects.
> >
> > What I've implemented[0] for Ubuntu (only for testing so far) is to
> install
> > libc to /lib/$multiarch/libc.so.6, the dynamic linker to
> > /lib/$multiarch/$dynamic_linker_soname, and then have a symlink from the
> > ABI-mandated dynamic linker path to the new path for the dynamic linker.
> > This feels like a reasonable compromise between the upstream changes and
> > what Debian does to me but I'm certainly interested in hearing other
> > opinions (ideally before Ubuntu feature freeze :-p).
>
> I think all the issues above are not really due to multiarch, but are
> created by the local-rtlddir-cross.diff patch that we have dropped in
> Debian as it introduces many issues. This makes the cross-toolchain-base
> maintainer unhappy, but I do not think we should introduce complexity in
> the libc6 package just to make dpkg-cross simpler.
>
We dropped this patch in Ubuntu a while ago too.
> With that patch dropped, there is no symlink to add, you can just use
> the upstream makefile do their jobs. The dynamic linker is installed
> directly in the ABI-mandated dynamic linker and there is no need for
> symlinks.
>
That would be simpler, indeed, and I can't really think of any particular
downsides. The only changes 2.34 will require then are the changes around
fixperms.
Cheers,
mwh
