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