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.1Regarding 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.
MichaelApparently 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 [email protected] To unsubscribe, send a mail with subject "unsubscribe" to [email protected]
tree-x86_64-secplatform-linux-gnu.gz
Description: application/gzip
_______________________________________________ ptxdist mailing list [email protected] To unsubscribe, send a mail with subject "unsubscribe" to [email protected]
