From: Christian Melki <christian.melki@t2data.com>
To: m.olbrich@pengutronix.de
Cc: ptxdist@pengutronix.de
Subject: Re: [ptxdist] FYI glibc-2.34.
Date: Fri, 4 Feb 2022 09:35:48 +0100 [thread overview]
Message-ID: <9c398806-a063-f21e-74a6-21c15dab1738@t2data.com> (raw)
In-Reply-To: <Yfzfdy7/IpKw6TnR@pengutronix.de>
On 2/4/22 9:10 AM, Michael Olbrich wrote:
> Hi,
>
> 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.
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.
> Michael
>
>> /Christian
>>
>> On 2/1/22 11:01 AM, Christian Melki wrote:
>>> Hi.
>>>
>>> I need to revisit the glibc-2.34 naming changes.
>>> Afaiu, no changes has been made regarding this topic.
>>> So, 2022.01 is still not glibc-2.34 compatible?
>>>
>>> glibc.make seems to get to libpthread. Ie, it completes these:
>>>
>>> ifdef PTXCONF_GLIBC_LD
>>> @$(call install_copy_toolchain_dl, glibc)
>>> endif
>>>
>>> ifdef PTXCONF_GLIBC_C
>>> @$(call install_copy_toolchain_lib, glibc, libc.so.6)
>>> endif
>>>
>>> ...
>>>
>>> So it finds ld-linux-x86-64.so.2 and libc.so.6, files without any
>>> softlinks.
>>>
>>> but:
>>>
>>> ifdef PTXCONF_GLIBC_PTHREAD
>>> @$(call install_copy_toolchain_lib, glibc, libpthread.so)
>>> endif
>>>
>>> fails, because it's named:
>>> sysroot/lib64/libpthread.so.0 without any other softlinks.
>>>
>>> ...
>>> lib - <snip>x-tools/x86_64-secplatform-linux-gnu/x86_64-secplatform-linux-gnu/sysroot/lib64/ld-linux-x86-64.so.2
>>>
>>> lib - <snip>/x-tools/x86_64-secplatform-linux-gnu/x86_64-secplatform-linux-gnu/sysroot/lib64/libc.so.6
>>>
>>> install_copy_toolchain_lib: libpthread.so not found
>>> make: *** [<snip>/lib/ptxdist-2022.01.0/rules/glibc.make:38:
>>> <snip>bin/platform-secplatform-x86_64/state/glibc.targetinstall] Error 1
>>>
>>>
>>>
>>> On 10/15/21 4:25 PM, Michael Olbrich wrote:
>>>> Hi,
>>>>
>>>> On Fri, Oct 15, 2021 at 10:25:45AM +0200, Christian Melki wrote:
>>>>> I did rollback my new toolchain to 2.33 and I didn't keep the
>>>>> 2.34 one. :\.
>>>>> I think it was rather simple, it didn't find the library and I
>>>>> didn't dig
>>>>> much deeper. I'm not in dire need of 2.34, it was just a
>>>>> maintenance bump.
>>>>>
>>>>> Maybe something to do with the platform PTXCONF_GLIBC_VERSION?
>>>>>
>>>>> "Specify the glibc version this BSP shall be built with. This
>>>>> information is
>>>>> used to guess the toolchain path if you use "ptxdist toolchain"
>>>>> without an
>>>>> argument, and to install the glibc into the target file"
>>>>>
>>>>> I can redo the toolchain. Do you have any suggestions?
>>>>
>>>> My guess is, that the heuristics in scripts/install_copy_toolchain.sh
>>>> cannot handle the changes in 2.34, but I'm not sure.
>>>>
>>>> Michael
>>>>
>>>>>
>>>>> Regards,
>>>>> Christian
>>>>>
>>>>> On 10/15/21 10:13 AM, Michael Olbrich wrote:
>>>>>> On Mon, Oct 11, 2021 at 01:08:01PM +0200, Christian Melki wrote:
>>>>>>> Quote from changelog:
>>>>>>>
>>>>>>> * Previously, glibc installed its various shared objects
>>>>>>> under versioned
>>>>>>> file names such as libc-2.33.so. The ABI sonames
>>>>>>> (e.g., libc.so.6)
>>>>>>> were provided as symbolic links. Starting with
>>>>>>> glibc 2.34, the shared
>>>>>>> objects are installed under their ABI sonames directly, without
>>>>>>> symbolic links. This increases compatibility with distribution
>>>>>>> package managers that delete removed files late during the package
>>>>>>> upgrade or downgrade process.
>>>>>>>
>>>>>>> Seems like glibc decided to be a trainwreck from one
>>>>>>> version to another with
>>>>>>> no apparent mean of restoring old behavior for a
>>>>>>> smoother transition period?
>>>>>>> Ptxdist glibc installation fails with this naming
>>>>>>> scheme. If anyone knows
>>>>>>> any better here, please enlighten me.
>>>>>>
>>>>>> Right, so PTXdist first tries to find the specified file,
>>>>>> e.g. libc.so.6,
>>>>>> and should then follow symlinks and deal with ld.so scripts.
>>>>>> I'm not sure
>>>>>> why that fails but it should be possible to fix it to handle
>>>>>> new and old
>>>>>> glibc versions.
>>>>>> What's the error that you get?
>>>>>>
>>>>>> Michael
>>>>>>
>>>>>>> (glibc-2.33 sysroot)
>>>>>>> ls -Gga ~/x-tools/x86_64-secplatform-linux-gnu/x86_64-secplatform-linux-gnu/sysroot/lib64
>>>>>>>
>>>>>>> total 58684
>>>>>>> dr-xr-xr-x 2 4096 okt 11 10:31 .
>>>>>>> dr-xr-xr-x 8 4096 okt 11 10:31 ..
>>>>>>> -r-xr-xr-x 1 1111208 okt 11 10:31 ld-2.33.so
>>>>>>> lrwxrwxrwx 1 10 okt 11 10:31 ld-linux-x86-64.so.2 -> ld-2.33.so
>>>>>>> -r-xr-xr-x 1 65912 okt 11 10:31 libanl-2.33.so
>>>>>>> lrwxrwxrwx 1 14 okt 11 10:31 libanl.so.1 -> libanl-2.33.so
>>>>>>> -r--r--r-- 1 312428 okt 11 10:31 libatomic.a
>>>>>>> lrwxrwxrwx 1 18 okt 11 10:31 libatomic.so -> libatomic.so.1.2.0
>>>>>>> lrwxrwxrwx 1 18 okt 11 10:31 libatomic.so.1 ->
>>>>>>> libatomic.so.1.2.0
>>>>>>> -r-xr-xr-x 1 109680 okt 11 10:31 libatomic.so.1.2.0
>>>>>>> -r-xr-xr-x 1 31672 okt 11 10:31 libBrokenLocale-2.33.so
>>>>>>> lrwxrwxrwx 1 23 okt 11 10:31 libBrokenLocale.so.1 ->
>>>>>>> libBrokenLocale-2.33.so
>>>>>>> -r-xr-xr-x 1 11319128 okt 11 10:31 libc-2.33.so
>>>>>>> -r-xr-xr-x 1 129808 okt 11 10:31 libcrypt-2.33.so
>>>>>>> lrwxrwxrwx 1 16 okt 11 10:31 libcrypt.so.1 -> libcrypt-2.33.so
>>>>>>> lrwxrwxrwx 1 12 okt 11 10:31 libc.so.6 -> libc-2.33.so
>>>>>>> -r-xr-xr-x 1 135648 okt 11 10:31 libdl-2.33.so
>>>>>>> lrwxrwxrwx 1 13 okt 11 10:31 libdl.so.2 -> libdl-2.33.so
>>>>>>> -r--r--r-- 1 132 okt 11 10:31 libgcc_s.so
>>>>>>> -r--r--r-- 1 401048 okt 11 10:31 libgcc_s.so.1
>>>>>>> -r--r--r-- 1 1202376 okt 11 10:31 libitm.a
>>>>>>> lrwxrwxrwx 1 15 okt 11 10:31 libitm.so -> libitm.so.1.0.0
>>>>>>> lrwxrwxrwx 1 15 okt 11 10:31 libitm.so.1 -> libitm.so.1.0.0
>>>>>>> -r-xr-xr-x 1 774416 okt 11 10:31 libitm.so.1.0.0
>>>>>>> -r--r--r-- 1 162 okt 11 10:31 libitm.spec
>>>>>>> -r-xr-xr-x 1 4455824 okt 11 10:31 libm-2.33.so
>>>>>>> -r-xr-xr-x 1 52016 okt 11 10:31 libmemusage.so
>>>>>>> lrwxrwxrwx 1 12 okt 11 10:31 libm.so.6 -> libm-2.33.so
>>>>>>> -r-xr-xr-x 1 549816 okt 11 10:31 libmvec-2.33.so
>>>>>>> lrwxrwxrwx 1 15 okt 11 10:31 libmvec.so.1 -> libmvec-2.33.so
>>>>>>> -r-xr-xr-x 1 510080 okt 11 10:31 libnsl-2.33.so
>>>>>>> lrwxrwxrwx 1 14 okt 11 10:31 libnsl.so.1 -> libnsl-2.33.so
>>>>>>> -r-xr-xr-x 1 163800 okt 11 10:31 libnss_compat-2.33.so
>>>>>>> lrwxrwxrwx 1 21 okt 11 10:31 libnss_compat.so.2 ->
>>>>>>> libnss_compat-2.33.so
>>>>>>> -r-xr-xr-x 1 144840 okt 11 10:31 libnss_db-2.33.so
>>>>>>> lrwxrwxrwx 1 17 okt 11 10:31 libnss_db.so.2 -> libnss_db-2.33.so
>>>>>>> -r-xr-xr-x 1 91024 okt 11 10:31 libnss_dns-2.33.so
>>>>>>> lrwxrwxrwx 1 18 okt 11 10:31 libnss_dns.so.2 ->
>>>>>>> libnss_dns-2.33.so
>>>>>>> -r-xr-xr-x 1 233784 okt 11 10:31 libnss_files-2.33.so
>>>>>>> lrwxrwxrwx 1 20 okt 11 10:31 libnss_files.so.2 ->
>>>>>>> libnss_files-2.33.so
>>>>>>> -r-xr-xr-x 1 81408 okt 11 10:31 libnss_hesiod-2.33.so
>>>>>>> lrwxrwxrwx 1 21 okt 11 10:31 libnss_hesiod.so.2 ->
>>>>>>> libnss_hesiod-2.33.so
>>>>>>> -r-xr-xr-x 1 22896 okt 11 10:31 libpcprofile.so
>>>>>>> -r-xr-xr-x 1 1148240 okt 11 10:31 libpthread-2.33.so
>>>>>>> lrwxrwxrwx 1 18 okt 11 10:31 libpthread.so.0 ->
>>>>>>> libpthread-2.33.so
>>>>>>> -r-xr-xr-x 1 356952 okt 11 10:31 libresolv-2.33.so
>>>>>>> lrwxrwxrwx 1 17 okt 11 10:31 libresolv.so.2 -> libresolv-2.33.so
>>>>>>> -r-xr-xr-x 1 203832 okt 11 10:31 librt-2.33.so
>>>>>>> lrwxrwxrwx 1 13 okt 11 10:31 librt.so.1 -> librt-2.33.so
>>>>>>> -r-xr-xr-x 1 69136 okt 11 10:31 libSegFault.so
>>>>>>> -r--r--r-- 1 19645422 okt 11 10:31 libstdc++.a
>>>>>>> -r--r--r-- 1 3393060 okt 11 10:31 libstdc++fs.a
>>>>>>> lrwxrwxrwx 1 19 okt 11 10:31 libstdc++.so -> libstdc++.so.6.0.29
>>>>>>> lrwxrwxrwx 1 19 okt 11 10:31 libstdc++.so.6 ->
>>>>>>> libstdc++.so.6.0.29
>>>>>>> -r-xr-xr-x 1 12057360 okt 11 10:31 libstdc++.so.6.0.29
>>>>>>> -r--r--r-- 1 2513 okt 11 10:31 libstdc++.so.6.0.29-gdb.py
>>>>>>> -r--r--r-- 1 928248 okt 11 10:31 libsupc++.a
>>>>>>> -r-xr-xr-x 1 268792 okt 11 10:31 libthread_db-1.0.so
>>>>>>> lrwxrwxrwx 1 19 okt 11 10:31 libthread_db.so.1 ->
>>>>>>> libthread_db-1.0.so
>>>>>>> -r-xr-xr-x 1 36944 okt 11 10:31 libutil-2.33.so
>>>>>>> lrwxrwxrwx 1 15 okt 11 10:31 libutil.so.1 -> libutil-2.33.so
>>>>>>>
>>>>>>> (glibc-2.34 sysroot):
>>>>>>> $ ls -Gga ~/x-tools/x86_64-secplatform-linux-gnu/x86_64-secplatform-linux-gnu/sysroot/lib64
>>>>>>>
>>>>>>> total 57276
>>>>>>> dr-xr-xr-x 2 4096 okt 11 12:37 .
>>>>>>> dr-xr-xr-x 8 4096 okt 11 12:35 ..
>>>>>>> -r-xr-xr-x 1 1223232 okt 11 12:35 ld-linux-x86-64.so.2
>>>>>>> -r-xr-xr-x 1 20144 okt 11 12:35 libanl.so.1
>>>>>>> -r--r--r-- 1 312428 okt 11 12:37 libatomic.a
>>>>>>> lrwxrwxrwx 1 18 okt 11 12:37 libatomic.so -> libatomic.so.1.2.0
>>>>>>> lrwxrwxrwx 1 18 okt 11 12:37 libatomic.so.1 ->
>>>>>>> libatomic.so.1.2.0
>>>>>>> -r-xr-xr-x 1 109680 okt 11 12:37 libatomic.so.1.2.0
>>>>>>> -r-xr-xr-x 1 31696 okt 11 12:35 libBrokenLocale.so.1
>>>>>>> -r-xr-xr-x 1 185680 okt 11 12:35 libc_malloc_debug.so.0
>>>>>>> -r-xr-xr-x 1 129656 okt 11 12:35 libcrypt.so.1
>>>>>>> -r-xr-xr-x 1 12496192 okt 11 12:35 libc.so.6
>>>>>>> -r-xr-xr-x 1 21496 okt 11 12:35 libdl.so.2
>>>>>>> -r--r--r-- 1 132 okt 11 12:37 libgcc_s.so
>>>>>>> -r--r--r-- 1 401096 okt 11 12:37 libgcc_s.so.1
>>>>>>> -r--r--r-- 1 1202416 okt 11 12:37 libitm.a
>>>>>>> lrwxrwxrwx 1 15 okt 11 12:37 libitm.so -> libitm.so.1.0.0
>>>>>>> lrwxrwxrwx 1 15 okt 11 12:37 libitm.so.1 -> libitm.so.1.0.0
>>>>>>> -r-xr-xr-x 1 774408 okt 11 12:37 libitm.so.1.0.0
>>>>>>> -r--r--r-- 1 162 okt 11 12:37 libitm.spec
>>>>>>> -r-xr-xr-x 1 52048 okt 11 12:35 libmemusage.so
>>>>>>> -r-xr-xr-x 1 3366704 okt 11 12:35 libm.so.6
>>>>>>> -r-xr-xr-x 1 582480 okt 11 12:35 libmvec.so.1
>>>>>>> -r-xr-xr-x 1 512040 okt 11 12:35 libnsl.so.1
>>>>>>> -r-xr-xr-x 1 171968 okt 11 12:35 libnss_compat.so.2
>>>>>>> -r-xr-xr-x 1 155232 okt 11 12:35 libnss_db.so.2
>>>>>>> -r-xr-xr-x 1 19312 okt 11 12:35 libnss_dns.so.2
>>>>>>> -r-xr-xr-x 1 19312 okt 11 12:35 libnss_files.so.2
>>>>>>> -r-xr-xr-x 1 81416 okt 11 12:35 libnss_hesiod.so.2
>>>>>>> -r-xr-xr-x 1 22920 okt 11 12:35 libpcprofile.so
>>>>>>> -r-xr-xr-x 1 21200 okt 11 12:35 libpthread.so.0
>>>>>>> -r-xr-xr-x 1 252296 okt 11 12:35 libresolv.so.2
>>>>>>> -r-xr-xr-x 1 26624 okt 11 12:35 librt.so.1
>>>>>>> -r-xr-xr-x 1 69720 okt 11 12:35 libSegFault.so
>>>>>>> -r--r--r-- 1 19645502 okt 11 12:37 libstdc++.a
>>>>>>> -r--r--r-- 1 3393124 okt 11 12:37 libstdc++fs.a
>>>>>>> lrwxrwxrwx 1 19 okt 11 12:37 libstdc++.so -> libstdc++.so.6.0.29
>>>>>>> lrwxrwxrwx 1 19 okt 11 12:37 libstdc++.so.6 ->
>>>>>>> libstdc++.so.6.0.29
>>>>>>> -r-xr-xr-x 1 12057664 okt 11 12:37 libstdc++.so.6.0.29
>>>>>>> -r--r--r-- 1 2513 okt 11 12:37 libstdc++.so.6.0.29-gdb.py
>>>>>>> -r--r--r-- 1 928248 okt 11 12:37 libsupc++.a
>>>>>>> -r-xr-xr-x 1 268904 okt 11 12:35 libthread_db.so.1
>>>>>>> -r-xr-xr-x 1 20152 okt 11 12:35 libutil.so.1
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> ptxdist mailing list
>>>>>>> ptxdist@pengutronix.de
>>>>>>> To unsubscribe, send a mail with subject "unsubscribe"
>>>>>>> to ptxdist-request@pengutronix.de
>>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> ptxdist mailing list
>>>>> ptxdist@pengutronix.de
>>>>> To unsubscribe, send a mail with subject "unsubscribe" to
>>>>> ptxdist-request@pengutronix.de
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> ptxdist mailing list
>>> ptxdist@pengutronix.de
>>> To unsubscribe, send a mail with subject "unsubscribe" to
>>> ptxdist-request@pengutronix.de
>>
>> _______________________________________________
>> ptxdist mailing list
>> ptxdist@pengutronix.de
>> To unsubscribe, send a mail with subject "unsubscribe" to ptxdist-request@pengutronix.de
>
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
To unsubscribe, send a mail with subject "unsubscribe" to ptxdist-request@pengutronix.de
next prev parent reply other threads:[~2022-02-04 8:37 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 [this message]
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
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=9c398806-a063-f21e-74a6-21c15dab1738@t2data.com \
--to=christian.melki@t2data.com \
--cc=m.olbrich@pengutronix.de \
--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