* [ptxdist] FYI glibc-2.34.
@ 2021-10-11 11:08 Christian Melki
2021-10-15 8:13 ` Michael Olbrich
0 siblings, 1 reply; 13+ messages in thread
From: Christian Melki @ 2021-10-11 11:08 UTC (permalink / raw)
To: ptxdist
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.
(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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [ptxdist] FYI glibc-2.34.
2021-10-11 11:08 [ptxdist] FYI glibc-2.34 Christian Melki
@ 2021-10-15 8:13 ` Michael Olbrich
2021-10-15 8:25 ` Christian Melki
0 siblings, 1 reply; 13+ messages in thread
From: Michael Olbrich @ 2021-10-15 8:13 UTC (permalink / raw)
To: Christian Melki; +Cc: ptxdist
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
>
--
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [ptxdist] FYI glibc-2.34.
2021-10-15 8:13 ` Michael Olbrich
@ 2021-10-15 8:25 ` Christian Melki
2021-10-15 14:25 ` Michael Olbrich
0 siblings, 1 reply; 13+ messages in thread
From: Christian Melki @ 2021-10-15 8:25 UTC (permalink / raw)
To: ptxdist
Hi.
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?
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [ptxdist] FYI glibc-2.34.
2021-10-15 8:25 ` Christian Melki
@ 2021-10-15 14:25 ` Michael Olbrich
2022-02-01 10:01 ` Christian Melki
0 siblings, 1 reply; 13+ messages in thread
From: Michael Olbrich @ 2021-10-15 14:25 UTC (permalink / raw)
To: Christian Melki; +Cc: ptxdist
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
>
--
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [ptxdist] FYI glibc-2.34.
2021-10-15 14:25 ` Michael Olbrich
@ 2022-02-01 10:01 ` Christian Melki
2022-02-01 13:27 ` Christian Melki
0 siblings, 1 reply; 13+ messages in thread
From: Christian Melki @ 2022-02-01 10:01 UTC (permalink / raw)
To: m.olbrich; +Cc: ptxdist
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [ptxdist] FYI glibc-2.34.
2022-02-01 10:01 ` Christian Melki
@ 2022-02-01 13:27 ` Christian Melki
2022-02-04 8:10 ` Michael Olbrich
0 siblings, 1 reply; 13+ messages in thread
From: Christian Melki @ 2022-02-01 13:27 UTC (permalink / raw)
To: m.olbrich; +Cc: ptxdist
Hi.
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.
2. If you want to run older (< 2.34) binaries, you're going to have to
install the provided files anyway (braindead).
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.
4. -print-file-name is a linktime dependency. Not a runtime one. Ptxdist
intermixed those, as it was traditionally not an issue.
/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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [ptxdist] FYI glibc-2.34.
2022-02-01 13:27 ` Christian Melki
@ 2022-02-04 8:10 ` Michael Olbrich
2022-02-04 8:35 ` Christian Melki
0 siblings, 1 reply; 13+ messages in thread
From: Michael Olbrich @ 2022-02-04 8:10 UTC (permalink / raw)
To: Christian Melki; +Cc: ptxdist
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.
> 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 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.
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
--
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [ptxdist] FYI glibc-2.34.
2022-02-04 8:10 ` Michael Olbrich
@ 2022-02-04 8:35 ` Christian Melki
2022-02-04 10:48 ` Michael Olbrich
0 siblings, 1 reply; 13+ messages in thread
From: Christian Melki @ 2022-02-04 8:35 UTC (permalink / raw)
To: m.olbrich; +Cc: ptxdist
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [ptxdist] FYI glibc-2.34.
2022-02-04 8:35 ` Christian Melki
@ 2022-02-04 10:48 ` Michael Olbrich
2022-02-04 12:40 ` Christian Melki
0 siblings, 1 reply; 13+ messages in thread
From: Michael Olbrich @ 2022-02-04 10:48 UTC (permalink / raw)
To: Christian Melki; +Cc: ptxdist
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.
> 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=...
You should see where gcc looks for the file.
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [ptxdist] FYI glibc-2.34.
2022-02-04 10:48 ` Michael Olbrich
@ 2022-02-04 12:40 ` Christian Melki
2022-02-04 13:00 ` Michael Olbrich
0 siblings, 1 reply; 13+ messages in thread
From: Christian Melki @ 2022-02-04 12:40 UTC (permalink / raw)
To: ptxdist
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.
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [ptxdist] FYI glibc-2.34.
2022-02-04 12:40 ` Christian Melki
@ 2022-02-04 13:00 ` Michael Olbrich
2022-02-04 13:09 ` Christian Melki
0 siblings, 1 reply; 13+ messages in thread
From: Michael Olbrich @ 2022-02-04 13:00 UTC (permalink / raw)
To: Christian Melki; +Cc: ptxdist
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [ptxdist] FYI glibc-2.34.
2022-02-04 13:00 ` Michael Olbrich
@ 2022-02-04 13:09 ` Christian Melki
2022-02-04 14:30 ` Michael Olbrich
0 siblings, 1 reply; 13+ messages in thread
From: Christian Melki @ 2022-02-04 13:09 UTC (permalink / raw)
To: m.olbrich; +Cc: ptxdist
[-- Attachment #1: Type: text/plain, Size: 5445 bytes --]
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
>>
>
[-- Attachment #2: tree-x86_64-secplatform-linux-gnu.gz --]
[-- Type: application/gzip, Size: 20449 bytes --]
[-- Attachment #3: Type: text/plain, Size: 181 bytes --]
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
To unsubscribe, send a mail with subject "unsubscribe" to ptxdist-request@pengutronix.de
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [ptxdist] FYI glibc-2.34.
2022-02-04 13:09 ` Christian Melki
@ 2022-02-04 14:30 ` Michael Olbrich
0 siblings, 0 replies; 13+ messages in thread
From: Michael Olbrich @ 2022-02-04 14:30 UTC (permalink / raw)
To: Christian Melki; +Cc: ptxdist
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
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2022-02-04 14:31 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-11 11:08 [ptxdist] FYI glibc-2.34 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
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox