From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 04 Feb 2022 15:31:24 +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 1nFzcS-005bLB-8s for lore@lore.pengutronix.de; Fri, 04 Feb 2022 15:31:24 +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 1nFzcR-0002GN-Kq; Fri, 04 Feb 2022 15:31:23 +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 1nFzbw-0002Fy-PH; Fri, 04 Feb 2022 15:30:52 +0100 Received: from mol by ptx.hi.pengutronix.de with local (Exim 4.92) (envelope-from ) id 1nFzbw-0000aZ-8o; Fri, 04 Feb 2022 15:30:52 +0100 Date: Fri, 4 Feb 2022 15:30:52 +0100 From: Michael Olbrich To: Christian Melki Message-ID: <20220204143052.GM11273@pengutronix.de> Mail-Followup-To: Christian Melki , ptxdist@pengutronix.de References: <20211015142523.GL2239952@pengutronix.de> <9c398806-a063-f21e-74a6-21c15dab1738@t2data.com> <20220204104828.GG3897@pengutronix.de> <19b9ac68-fdaf-e628-31eb-8f965fdeccac@t2data.com> <20220204130050.GJ3897@pengutronix.de> <52b1a101-323c-66b2-b732-89a42e74418c@t2data.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <52b1a101-323c-66b2-b732-89a42e74418c@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: 15:23:24 up 55 days, 23:08, 89 users, load average: 0.10, 0.08, 0.12 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 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