Re: Preparing for glibc 2.34: library locations
On Sun, 5 Sept 2021 at 01:48, Aurelien Jarno 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
Re: Preparing for glibc 2.34: library locations
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.
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.
Regards,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
Re: Preparing for glibc 2.34: library locations
* Michael Hudson-Doyle: > (but then, dpkg is not > impacted by the symbolic link issue as far as I know). > > Is this problem written up somewhere? I only subscribed to libc-alpha > a few weeks ago. I've written about it in various places. As far as I know, it's specific to how RPM performs package updates. Files removed in an update are only removed towards the end, after all work on *all* packages has been done. With the previous approach, this means that when downgrading from glibc 2.29 to glibc 2.28, during the update, there are files ld-2.28.so ld-2.29.so libc-2.28.so libc-2.29.so RPM immediately updates the dynamic linker symbolic link target from ld-2.29.so to ld-2.28.so. But if ldconfig is invoked, it will prefer libc-2.29.so over libc-2.28.so as the provider of the soname libc.so.6, and update the symbolic link and cache to point to libc-2.29.so. That is of course no good once the downgrade is finally completed and libc-2.29.so is removed. The dynamic linker and the libc.so.6 symbolic link can also become desynchronized, and then failures happen earlier during the update procedure. I believe dpkg handles file removals during upgrades/downgrades before running scripts, so it shouldn't suffer from this problem. But I believe the simplification is still worth it. Thanks, Florian
Re: Preparing for glibc 2.34: library locations
On Mon, 26 Jul 2021 at 19:16, Florian Weimer wrote: > * Michael Hudson-Doyle: > > > 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 agree that this layout is reasonable. Thanks for thinking about it! > The target of the remaining > symbolic link is stable, so it does not matter for the issues that we > tried to address with this upstream change Right, I'm not an expert in this stuff but I tried and failed to think of ways upgrades could go wrong. > (but then, dpkg is not > impacted by the symbolic link issue as far as I know). > Is this problem written up somewhere? I only subscribed to libc-alpha a few weeks ago. > Would you please consider contributing your multiarch patches upstream? > I see no problems in principle. As above though I've only been seriously involved in glibc maintenance for maybe a month so I'm a bit lacking in context :) Cheers, mwh > Thanks. > > Florian > >
Re: Preparing for glibc 2.34: library locations
* Michael Hudson-Doyle: > 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 agree that this layout is reasonable. The target of the remaining symbolic link is stable, so it does not matter for the issues that we tried to address with this upstream change (but then, dpkg is not impacted by the symbolic link issue as far as I know). Would you please consider contributing your multiarch patches upstream? Thanks. Florian
