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.

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