From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 04 Feb 2022 14:00:59 +0100 Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33]) by lore.white.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nFyCx-005Xjn-0z for lore@lore.pengutronix.de; Fri, 04 Feb 2022 14:00:59 +0100 Received: from localhost ([127.0.0.1] helo=metis.ext.pengutronix.de) by metis.ext.pengutronix.de with esmtp (Exim 4.92) (envelope-from ) id 1nFyCw-0007ut-EC; Fri, 04 Feb 2022 14:00:58 +0100 Received: from ptx.hi.pengutronix.de ([2001:67c:670:100:1d::c0]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nFyCo-0007uN-W1; Fri, 04 Feb 2022 14:00:50 +0100 Received: from mol by ptx.hi.pengutronix.de with local (Exim 4.92) (envelope-from ) id 1nFyCo-0003AZ-JT; Fri, 04 Feb 2022 14:00:50 +0100 Date: Fri, 4 Feb 2022 14:00:50 +0100 From: Michael Olbrich To: Christian Melki Message-ID: <20220204130050.GJ3897@pengutronix.de> Mail-Followup-To: Christian Melki , ptxdist@pengutronix.de References: <20211015081333.GC2239952@pengutronix.de> <20211015142523.GL2239952@pengutronix.de> <9c398806-a063-f21e-74a6-21c15dab1738@t2data.com> <20220204104828.GG3897@pengutronix.de> <19b9ac68-fdaf-e628-31eb-8f965fdeccac@t2data.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <19b9ac68-fdaf-e628-31eb-8f965fdeccac@t2data.com> X-Sent-From: Pengutronix Hildesheim X-URL: http://www.pengutronix.de/ X-IRC: #ptxdist @freenode X-Accept-Language: de,en X-Accept-Content-Type: text/plain X-Uptime: 13:52:59 up 55 days, 21:38, 88 users, load average: 0.20, 0.17, 0.11 User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [ptxdist] FYI glibc-2.34. X-BeenThere: ptxdist@pengutronix.de X-Mailman-Version: 2.1.29 Precedence: list List-Id: PTXdist Development Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: ptxdist@pengutronix.de Cc: ptxdist@pengutronix.de Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "ptxdist" X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: ptxdist-bounces@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false 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