Re: [ptxdist] FYI glibc-2.34.

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

On Fri, Feb 04, 2022 at 01:40:44PM +0100, Christian Melki wrote:
> On 2/4/22 11:48 AM, Michael Olbrich wrote:
> > 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.
> > 
> 
> They're there if you need them. But you can't ask for the previous symlink
> name, as it does not exist anymore. You can still ask for
> libsomething.so.version, ie the full soname. The rather convenient following
> of symlink which glibc provided with it's installation is no more. Well. For
> some libraries it's still there...
> And for the compatibility libraries.
> 
> $ ls -Ggh platform-secplatform-x86_64/root/usr/lib64
> total 4,9M
> drwxr-xr-x 3 4,0K feb  4 12:22 gconv
> -rwxr-xr-x 1 198K feb  4 12:22 ld-linux-x86-64.so.2
> -rwxr-xr-x 1  43K feb  4 12:22 libcrypt.so.1
> -rwxr-xr-x 1 2,0M feb  4 12:22 libc.so.6
> -rw-r--r-- 1  79K feb  4 12:05 libgcc_s.so.1
> -rwxr-xr-x 1 859K feb  4 12:22 libm.so.6
> -rwxr-xr-x 1  14K feb  4 12:22 libnss_dns.so.2
> -rwxr-xr-x 1  14K feb  4 12:22 libnss_files.so.2
> -rwxr-xr-x 1  63K feb  4 12:22 libresolv.so.2
> -rwxr-xr-x 1  15K feb  4 12:22 librt.so.1
> lrwxrwxrwx 1   19 feb  4 12:05 libstdc++.so -> libstdc++.so.6.0.29
> lrwxrwxrwx 1   19 feb  4 12:05 libstdc++.so.6 -> libstdc++.so.6.0.29
> -rwxr-xr-x 1 1,7M feb  4 12:05 libstdc++.so.6.0.29
> -rwxr-xr-x 1  35K feb  4 12:22 libthread_db.so.1
> 
> > > 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=...
> 
> Yes. Symlinks are gone. The rationale was atomicity in library
> install/removal for package managers in distributions.

Huh? But those symlinks are used at buildtime to find the library. So they
should be somewhere for all the libraries that are still needed at
build-time. Without it '-lm' or '-lcrypt' or something like that should
fail.

Can you send the output of 'tree /path/to/your/toolchain'?


Michael

> Apparently the did not care much if they broke any other usecase.
> Not enough so that they could have provided a classical install layout.
> 
> I've tried prodding the glibc people but they are utterly uninterested.
> 
> > You should see where gcc looks for the file.
> > 
> > Michael
> > 
> 
> _______________________________________________
> ptxdist mailing list
> ptxdist@pengutronix.de
> To unsubscribe, send a mail with subject "unsubscribe" to ptxdist-request@pengutronix.de
> 

-- 
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