mailarchive of the ptxdist mailing list
 help / color / mirror / Atom feed
From: Michael Olbrich <m.olbrich@pengutronix.de>
To: Christian Melki <christian.melki@t2data.com>
Cc: ptxdist@pengutronix.de
Subject: Re: [ptxdist] FYI glibc-2.34.
Date: Fri, 4 Feb 2022 15:30:52 +0100	[thread overview]
Message-ID: <20220204143052.GM11273@pengutronix.de> (raw)
In-Reply-To: <52b1a101-323c-66b2-b732-89a42e74418c@t2data.com>

On Fri, Feb 04, 2022 at 02:09:03PM +0100, Christian Melki wrote:
> 
> 
> On 2/4/22 2:00 PM, Michael Olbrich wrote:
> > 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'?
> > 
> 
> I assume that some of them are still there, for the compatibility.
> Anyway.
> 
> tree without options output as gzipped attachment.

Hmm, so there is still (for example) a libcrypt.so in the same place as
always. So the question is, why does "$(call install_copy_toolchain_lib,
glibc, libcrypt.so)" no longer work?

And i think it should be expected that there is no libpthread.so any more.
At least not as a symlink. Otherwise it will be picked up from -lpthread
and it's added to the needed libraries.
I expect that the pthread.a (it will be used because libpthread.so is
missing) is just a stub.

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


      reply	other threads:[~2022-02-04 14:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-11 11:08 Christian Melki
2021-10-15  8:13 ` Michael Olbrich
2021-10-15  8:25   ` Christian Melki
2021-10-15 14:25     ` Michael Olbrich
2022-02-01 10:01       ` Christian Melki
2022-02-01 13:27         ` Christian Melki
2022-02-04  8:10           ` Michael Olbrich
2022-02-04  8:35             ` Christian Melki
2022-02-04 10:48               ` Michael Olbrich
2022-02-04 12:40                 ` Christian Melki
2022-02-04 13:00                   ` Michael Olbrich
2022-02-04 13:09                     ` Christian Melki
2022-02-04 14:30                       ` Michael Olbrich [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220204143052.GM11273@pengutronix.de \
    --to=m.olbrich@pengutronix.de \
    --cc=christian.melki@t2data.com \
    --cc=ptxdist@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox