Re: [ptxdist] FYI glibc-2.34.

[Michael Olbrich <m.olbrich@pengutronix.de>]

On Fri, Feb 04, 2022 at 09:35:48AM +0100, Christian Melki wrote:
> On 2/4/22 9:10 AM, Michael Olbrich wrote:
> > On Tue, Feb 01, 2022 at 02:27:00PM +0100, Christian Melki wrote:
> > > With a large pinch of salt... I think there are several parts to this new
> > > glibc behavior.
> > > 
> > > 1. A couple of libraries are now integrated. There is no need to ask for
> > > linking with -lpthread, -ldl, -lutil, -lanl. But old binaries might have
> > > them as DT_NEEDED. So glibc provides them as .so files anyway.
> > 
> > Right, I heard about that.
> > 
> 
> That part seems rather non-intrusive so far. I've built a toolchain and code
> (atleast the stuff I've tested) seems fine building around it.
> 
> > > 2. If you want to run older (< 2.34) binaries, you're going to have to
> > > install the provided files anyway (braindead).
> > 
> > That's called binary compatibility :-)
> > 
> > > 3. Afaiu there is no real way of agnostically trying to determine the
> > > provided runtime file name (not linktime file name which is what gcc
> > > -print-file-name does) abi soname from something simple as a name.so
> > > softlink, whatever that may be. Atleast not anymore. This creates issues
> > > with finding and installing toolchain bits in ptxdist.
> > 
> > The mess in install_copy_toolchain.sh is something I always tried to touch
> > as little as possible because it's supposed to work with as many toolchains
> > as possible. It's somewhere on my todo list to rewrite this and it looks
> > like it's time to do that for glibc-2.34.
> > 
> > > 4. -print-file-name is a linktime dependency. Not a runtime one. Ptxdist
> > > intermixed those, as it was traditionally not an issue.
> > 
> > So what do you get for -print-file-name=libpthread.so? The path to libc.so?
> > I don't have a glibc-2.34 to test this.
> > 
> 
> It returns libpthread.so. So asking for the link name does not seem like an
> option anymore.

So where is the libpthread library? The one needed for binary
compatibility?
If there is no special handling, then -print-file-name= should just look
for the file in a toolchain specific search path.

> Regarding a glibc 2.34 toolchain. crosstool-ng will do fine for the test and
> if you're to busy I'll happily send you one.
> 
> > It looks like I need to do some refactoring here. But I need a glibc-2.34
> > toolchain first to test it. So it probably won't happen any time soon.
> > 
> 
> Mm.. ok. I think that my changes will work, but the part I'm uncertain about
> are the sonames longevity, over time and over architectures for example.

The problem I have with that, are the extra version numbers. I have no idea
what happens with that with older toolchains. So this needs testing.

Why is that needed anyways? I assume that -print-file-name= does not work
anymore without it? Are those symlinks gone in your toolchain?
Maybe try:

strace -eaccess gcc -print-file-name=...

You should see where gcc looks for the file.

Michael

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
To unsubscribe, send a mail with subject "unsubscribe" to ptxdist-request@pengutronix.de