Re: FUDD on having multiple library versions. (was re: Snapshot 20210212 = full reinstall)
Windows gets around it by having multiple so's -- installing the 'so' that each program compiled with.
That's not really a solution though. Having ten copies of libpng on your harddisk means you will have to update ten copies of libpng when there is a vulnerability. ==== Found this looking for something else and didn't want this F.U.D.D. to continue. This isn't true. First point: those
On 2021/02/17 09:53, John Paul Adrian Glaubitz wrote: libraries aren't the entry point of an attack, the programs that use those libraries are. Second, it is the executable that needs to be updated and they will be linked with ONE new library that fixes the, vulnerability, not 10.
On Apr 9, 2021, at 7:18 AM, L A Walsh <suse@tlinx.org> wrote:
On 2021/02/17 09:53, John Paul Adrian Glaubitz wrote:
Windows gets around it by having multiple so's -- installing the 'so' that each program compiled with.
That's not really a solution though. Having ten copies of libpng on your harddisk means you will have to update ten copies of libpng when there is a vulnerability. ==== Found this looking for something else and didn't want this F.U.D.D. to continue. This isn't true. First point: those libraries aren't the entry point of an attack, the programs that use those libraries are. Second, it is the executable that needs to be updated and they will be linked with ONE new library that fixes the, vulnerability, not 10.
You may want to look up how shared libraries work as what you describe here is wrong. Shared libraries use a stable binary interface which is why you don’t have to update the programs using them if you make smaller changes such as security updates to the shared library which don’t alter the ABI. Thus, if you have multiple copies of a shared library on-disk, you must update all of them or delete all of them but one copy and update that one to make sure the vulnerability is fixed for all applications using that shared library. Disclaimer: I was a professional Windows application developer in my previous job, so I am actually speaking with some experience here. Adrian
Hello on Friday morning! Don't feed Fudd - except on casual Friday ;-) Enjoy the weekend! Johannes Meixner -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 - 90409 Nuernberg - Germany (HRB 36809, AG Nuernberg) GF: Felix Imendoerffer
On 2021/04/09 00:30, Adrian Glaubitz wrote:
You may want to look up how shared libraries work as what you describe here is wrong.
Shared libraries use a stable binary interface which is why you don’t have to update the programs using them if you make smaller changes such as security updates to the shared library which don’t alter the ABI.
you may want to look up how many programs had to be re-linked and re-released in the TW release where glibc changed. numbers. It doesn't matter if it is compatible or incompatible. Every "libc.so.6" user on the system need to be re-installed. That's the update nightmare. The 1 library release changes, and 100's of programs stop working. Not until you find a program that was statically linked can you hope to get back to a working system. Whatever model of shared library use that causes that is certainly not ideal. It has been that way for many years and yet still can't be fixed?
On 10.04.21 21:27, L A Walsh wrote:
you may want to look up how many programs had to be re-linked and re-released in the TW release where glibc changed. numbers. It doesn't matter if it is compatible or incompatible. Every "libc.so.6" user on the system need to be re-installed. That's the update nightmare.
The 1 library release changes, and 100's of programs stop working.
I do not remember a glibc update seriously breaking any of my old binaries. I run tumbleweed on my main machine and I often do partial updates without rebooting for practical reasons. The update that's always a no-brainer is the glibc & friends update. I just apply it and everything keeps working.
It has been that way for many years and yet still can't be > fixed?
It has never been that way for me. The more I read about your problems and then remember you telling us what you all have changed from the system defaults to make your system resemble an opensuse installation only very remotely, the more I tend to believe it's you who breaks your system all the time. Best regards, and good luck -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On Apr 10 2021, L A Walsh wrote:
you may want to look up how many programs had to be re-linked and re-released in the TW release where glibc changed.
That number was zero. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
On 2021/04/12 02:36, Andreas Schwab wrote:
On Apr 10 2021, L A Walsh wrote:
you may want to look up how many programs had to be re-linked and re-released in the TW release where glibc changed.
That number was zero.
Andreas. ======= -------- Original Message -------- Subject: Brace for impact: Snapshot 20210212 is a full rebuild based on glibc 2.33 Date: Tue, 16 Feb 2021 09:58:10 +0100 From: Dominique Leuenberger / DimStar To: opensuse-factory
Dear Tumbleweed users, I want to inform you upfront of a few specialties: * The snapshot is going to be large, in the number of packages to 'update' (mostly rebuild counters) and thus also megabytes. * The snapshot is the first to be based on glibc 2.33 https://sourceware.org/pipermail/libc-alpha/2021-February/122207.html ====== Because glibc changed to 2.33, a large number of packages had to be updated. Zero != large number.
On 4/12/21 12:20 PM, L A Walsh wrote:
Because glibc changed to 2.33, a large number of packages had to be updated.
Zero != large number.
This wasn't a "must", it was just done for performance reasons.
On 4/12/21 7:50 PM, L A Walsh wrote: > On 2021/04/12 02:36, Andreas Schwab wrote: >> On Apr 10 2021, L A Walsh wrote: >> >>> you may want to look up how many programs had to be re-linked and >>> re-released in the TW release where glibc changed. >> >> That number was zero. >> >> Andreas. > ======= > -------- Original Message -------- > Subject: Brace for impact: Snapshot 20210212 is a full rebuild based > on glibc 2.33 > Date: Tue, 16 Feb 2021 09:58:10 +0100 > From: Dominique Leuenberger / DimStar To: opensuse-factory > Dear Tumbleweed users, > I want to inform you upfront of a few specialties: > * The snapshot is going to be large, in the number of packages to > 'update' (mostly rebuild counters) and thus also megabytes. > * The snapshot is the first to be based on glibc 2.33 > https://sourceware.org/pipermail/libc-alpha/2021-February/122207.html > ====== > > Because glibc changed to 2.33, a large number of packages had to be > updated. Programs having to be relinked and packages being re released are two very different things, No program should have had to be relinked so binaries not from openSUSE RPM's did not have to be rebuilt, however by the current design in tumbleweed it did cause a large number of packages to be updated. Which isn't great for users because the package manager needs to download them all but that is part of the understanding of using tumbleweed. At the same time it also shouldn't have broken anything once they used zypper to update. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Apr 12 2021, L A Walsh wrote:
Because glibc changed to 2.33, a large number of packages had to be updated.
Nope. Nothing of that was necessary. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
On Apr 12 2021, L A Walsh wrote:
Because glibc changed to 2.33, a large number of packages had to be updated.
On 2021/04/12 05:04, Andreas Schwab wrote: Nope. Nothing of that was necessary. Andreas.
On 2021/04/12 03:24, John Paul Adrian Glaubitz wrote:
This wasn't a "must", it was just done for performance reasons.
--- Just to be sure I wasn't misremembering, I installed glibc to a non-global location, and set my LD_LIBRARY_PATH to the new location. In the lib-root, I found: etc/ lib64/ sbin/ usr/ var/ under lib64, I find (among others): ├── lib64 │ ├── ld-2.33.so │ ├── ld-linux-x86-64.so.2 -> ld-2.33.so │ ├── ld-lsb-x86-64.so.3 -> ld-linux-x86-64.so.2 │ ├── libc-2.33.so │ ├── libc.so.6 -> libc-2.33.so --- I'm glad I installed this under a non-root location, since it shows the same error as before -- all programs except statically linked ones disabled:
ls ls: relocation error: /tmp/glibc/root/glibc-2.33/lib64/libc.so.6: symbol _dl_fatal_printf version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference
Same message pops up for many if not most other programs needed to even copy or restore a file. Fortunately, this time, I was able to use 'unset LD_LIBRARY_PATH'. It sure looks to me, that if all the programs aren't relinked or rebuilt against the new glibc, they will fail. This is the problem I was talking about when I said that one should be able to add a new version of glibc and not have to update all programs on one's system. This is currently not the case. So, please explain how fixing a lib with multiple versions is worse than disabling all programs on the system that aren't updated at the same time. It shouldn't be necessary -- I agree. But it hasn't been my experience on SuSE for many years. How can it be fixed?
On 4/18/21 8:02 AM, L A Walsh wrote:
Just to be sure I wasn't misremembering, I installed glibc to a non-global location, and set my LD_LIBRARY_PATH to the new location. In the lib-root, I found: etc/ lib64/ sbin/ usr/ var/ under lib64, I find (among others): ├── lib64 │ ├── ld-2.33.so │ ├── ld-linux-x86-64.so.2 -> ld-2.33.so │ ├── ld-lsb-x86-64.so.3 -> ld-linux-x86-64.so.2 │ ├── libc-2.33.so │ ├── libc.so.6 -> libc-2.33.so --- I'm glad I installed this under a non-root location, since it shows the same error as before -- all programs except statically linked ones disabled:
ls ls: relocation error: /tmp/glibc/root/glibc-2.33/lib64/libc.so.6: symbol _dl_fatal_printf version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference
I'm not sure what you are trying to prove here. You are partially overwriting the shared library search path on your system causing it to use a mishmash of two different glibc versions which were also probably built with different options and local patches, and then you're complaining that this hack causes problems. How is that surprising? And what does that prove? And why do you complain that a rolling release distribution such as Tumbleweed is receiving large updates regularly? The whole point of Tumbleweed is to provide a testbed for the people who develop the whole distribution and naturally, this includes full archive rebuilds when a new version of the toolchain or GLIBC are uploaded. Both Debian and Fedora also have mass rebuilds in their unstable and rawhide distributions, although Debian does not rebuild the whole archive when switching to a new version GCC. We just perform a mass rebuild in AWS on arm64, x86_64 and ppc64el to see that there are no new build regressions with the new GCC version. The mass rebuilds allow the use of new optimizations and they help finding toolchain bugs and regressions when updating the toolchain and related components. That's why these are performed. If you don't want to experience such mass rebuilds, simply use a stable distribution such as openSUSE Leap or Debian stable. Adrian
On 2021/04/17 23:15, John Paul Adrian Glaubitz wrote:
On 4/18/21 8:02 AM, L A Walsh wrote:
Just to be sure I wasn't misremembering, I installed glibc to a non-global location, and set my LD_LIBRARY_PATH to the new location. In the lib-root, I found: etc/ lib64/ sbin/ usr/ var/ under lib64, I find (among others): ├── lib64 │ ├── ld-2.33.so │ ├── ld-linux-x86-64.so.2 -> ld-2.33.so │ ├── ld-lsb-x86-64.so.3 -> ld-linux-x86-64.so.2 │ ├── libc-2.33.so │ ├── libc.so.6 -> libc-2.33.so --- I'm glad I installed this under a non-root location, since it shows the same error as before -- all programs except statically linked ones disabled:
ls ls: relocation error: /tmp/glibc/root/glibc-2.33/lib64/libc.so.6: symbol _dl_fatal_printf version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference
I'm not sure what you are trying to prove here.
You said: -------- Original Message -------- From: John Paul Adrian Glaubitz <adrian.glaubitz@suse.com> On 4/12/21 12:20 PM, L A Walsh wrote:
Because glibc changed to 2.33, a large number of packages had to be updated.
Zero != large number.
This wasn't a "must", it was just done for performance reasons. ---- I said the programs needed to be updated along with glibc -- a large number. You claim it was just a performance reason. Yet I'm showing that it generates a fatal error -- which isn't a performance issue. Adrian claims relinking the apps also was unnecessary -- if that is true, then why won't the apps still run without relinking? You claim it is a security nightmare having to replace 1 lib that has multiple versions. It's already a nightmare since all the programs have to be replaced as well.
On Apr 18 2021, L A Walsh wrote:
why won't the apps still run without relinking?
They do. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
On 2021/04/18 02:06, Andreas Schwab wrote:
On Apr 18 2021, L A Walsh wrote:
why won't the apps still run without relinking?
They do. Andreas.
Um...when I try to run those apps they don't work with the newly installed library:
ls ls: relocation error: /tmp/glibc/root/glibc-2.33/lib64/libc.so.6: symbol _dl_fatal_printf version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference
If there is a way that makes them work without needing a new version, say of 'ls' (coreutils), please let me know. This isn't a new issue for me. I've seen similar errors before How can I make this setup work such that I don't get the above error, as getting an error such as above doesn't allow the program to work on my machine. Thanks! -linda
On Sunday 2021-04-18 21:11, L A Walsh wrote:
On 2021/04/18 02:06, Andreas Schwab wrote:
On Apr 18 2021, L A Walsh wrote:
why won't the apps still run without relinking?
They do. Andreas.
Um...when I try to run those apps they don't work with the newly installed library:
ls ls: relocation error: /tmp/glibc/root/glibc-2.33/lib64/libc.so.6: symbol _dl_fatal_printf version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference ---- If there is a way that makes them work
For the umpteenth time, stop mixing libc versions. Even if you set LD_LIBRARY_PATH to load libc.so.6 from /tmp, invoking "ls" still invokes the ELF interpreter set forth in that binary -- which is still /lib64/ld-linux-x86-64.so.2 rather than /tmp/glibc/root/glibc-2.33/lib64/ld-linux-x86-64.so.2.
On 4/18/21 12:11 PM, L A Walsh wrote:
On 2021/04/18 02:06, Andreas Schwab wrote:
On Apr 18 2021, L A Walsh wrote:
why won't the apps still run without relinking?
They do. Andreas.
Um...when I try to run those apps they don't work with the newly installed library:
ls ls: relocation error: /tmp/glibc/root/glibc-2.33/lib64/libc.so.6: symbol _dl_fatal_printf version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference
If there is a way that makes them work without needing a new version, say of 'ls' (coreutils), please let me know. This isn't a new issue for me. I've seen similar errors before How can I make this setup work such that I don't get the above error, as getting an error such as above doesn't allow the program to work on my machine.
Thanks! -linda
Linda, The C library, glibc, is I'm sure you know, a VERY low level library and it winds through nearly everything... All of the C standard functions are implemented in that library as well as most of the ancilliary C functions like name resolution (DNS etc) When the app originally compiled it had one set of symbols that are in the old libraries and they were used by the linker to tell the compiled binary how to find that function in the library that was installed at the time. The new library has a new set of symbols, and as the error points to, some no longer exist or are renamed in the new version. In any case,the compiled and linked binary can't find it's required functions in the new library. This is part of the reason that very "elemental" *IX (Linux, UNIX etc) programs like ls, ps, etc used to be installed in a staticlly linked version... They don't need external libraries to work that way, but they're bigger on disk. The one thing you CAN try is is a somewhat obscure thing, and you still need to have the old libraries to make it work: The LD_PRELOAD "trick": https://stackoverflow.com/questions/426230/what-is-the-ld-preload-trick To make a long story short, the linker universally sticks a hook into programs that looks for the environment variable LD_PRELOAD, and if present, uses the libraries found there before looking at LD_LIBRARY_PATH to resolve library loading.
On Sunday 2021-04-18 22:06, Bruce Ferrell wrote:
ls: relocation error: /tmp/glibc/root/glibc-2.33/lib64/libc.so.6: symbol _dl_fatal_printf version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference ----
When the app originally compiled it had one set of symbols
ls does not require "_dl_fatal_printf".
This is part of the reason that very "elemental" *IX (Linux, UNIX etc) programs like ls, ps, etc used to be installed in a staticlly linked version...
That is a red herring. The error stems from the dynamic linker unable to combine two versions of libc. If you were to attempt the same with a static link, that would equally fail. Static linking mode just doesn't fix stupid linking attempts in the first place.
To make a long story short, the linker universally sticks a hook into programs that looks for the environment variable LD_PRELOAD, and if present, uses the libraries found there before looking at LD_LIBRARY_PATH to resolve library loading.
No, not really, especially not for the case of dynamicly-linked executables. Analysis of LD_PRELOAD/LD_LIBRARY_PATH happens by ld-linux.so, which is not a hook but a program in its own right.
On 4/18/21 4:10 PM, Jan Engelhardt wrote:
On Sunday 2021-04-18 22:06, Bruce Ferrell wrote:
ls: relocation error: /tmp/glibc/root/glibc-2.33/lib64/libc.so.6: symbol _dl_fatal_printf version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference ---- When the app originally compiled it had one set of symbols ls does not require "_dl_fatal_printf".
This is part of the reason that very "elemental" *IX (Linux, UNIX etc) programs like ls, ps, etc used to be installed in a staticlly linked version... That is a red herring.
The error stems from the dynamic linker unable to combine two versions of libc. If you were to attempt the same with a static link, that would equally fail.
Static linking mode just doesn't fix stupid linking attempts in the first place.
If a program is statically linked at build time, attempts at loading additional dynamic link libraries at run time NEVER happens. If a "stupid link" errors has happened, the build never completes... The most common version is you don't have a version of the library that allows static linking. For all intents and purposes, in this circumstance, you don't get a binary you can even try to run.
To make a long story short, the linker universally sticks a hook into programs that looks for the environment variable LD_PRELOAD, and if present, uses the libraries found there before looking at LD_LIBRARY_PATH to resolve library loading. No, not really, especially not for the case of dynamicly-linked executables.
Analysis of LD_PRELOAD/LD_LIBRARY_PATH happens by ld-linux.so, which is not a hook but a program in its own right.
Good lord you're pedantic! ld-linux.so is a dynamic link library. The so extension means "shared object" and I know a DLL is windows nomenclature. I know the man page for ldd calls ld-linux a program. They serve the same purpose and I don't get hung up on anything BUT purpose. Just to be equally pedantic, it's placed by the linker, unless the --static option was specified during the build it's used only for resolving any other dynamic link libraries (shared objects) to be used. <library>.so is a dynamic link library/shared object intended for dynamic use. <library>.a is the same set of library functions in a format that can be statically linked. Once statically linked into the program, you can run the program without <library>.a present outside the of the program. In the example below, the same example used in the ldd man page, we can the exact shared objects linked in. we see linux-vdso.so, (see man vdso) a shared object for the kernel for support of the virtual ELF dynamic format. ELF support in the kernel configuration has to be specified... if happen you to build a kernel. we also see the full path to ld-linux and the rest of the shared objects used by ls ldd /usr/bin/ls linux-vdso.so.1 (0x00007ffc554df000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fc99bffa000) libcap.so.2 => /usr/lib64/libcap.so.2 (0x00007fc99bdf5000) libc.so.6 => /lib64/libc.so.6 (0x00007fc99ba3a000) libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00007fc99b7af000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fc99b5ab000) /lib64/ld-linux-x86-64.so.2 (0x00007fc99c445000) If any are missing or are not available, we get a "not found" If you happen to make an incorrect library version match up to what the ELF format of the process specifies for, it MAY try to run but is likely to have different errors at run time... I know, I've tried. Sometimes it works though. IF you use LD_PRELOAD, you can force an override of "normal" resolution... Cause different versions of libraries to be used. To digress for just a moment, there is one use of LD_PRELOAD for forcing a shared object that was never linked to load, that will cause the openssl library to dump session keys generated during the run and those can be used to decrypt TLS packets collected with tcpdump. Gawd! it's been a VERY long time since I've wanted to look at this stuff for other than minor functional reasons. I can't even remember why ELF is/was considered to be better than a.out anymore... But, it's what is done now. Thanks for the trip down memory lane!
On Monday 2021-04-19 02:21, Bruce Ferrell wrote:
If a program is statically linked at build time, attempts at loading additional dynamic link libraries at run time NEVER happens.
No, not "never". $ cat x.cpp #include <pwd.h> int main(){setpwent();} $ g++ x.cpp -static x.cpp:(.text+0x5): warning: Using 'setpwent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking $ strace -e open,openat ./a.out openat(AT_FDCWD, "/lib64/libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = 3
If a "stupid link" errors has happened, the build never completes...
Which was exactly my point. Linda has a stupid link error, it's just that it happens during runtime (but still with a linker).
No, not really, especially not for the case of dynamicly-linked executables.
Analysis of LD_PRELOAD/LD_LIBRARY_PATH happens by ld-linux.so, which is not a hook but a program in its own right.
Good lord you're pedantic!
ld-linux.so is a dynamic link library. The so extension means "shared object" and I know a DLL is windows nomenclature. I know the man page for ldd calls ld-linux a program.
One can actually run ld-linux-x86-64.so.2 from the command line and get something out of it, which is not the case for e.g. /lib64/libacl.so.1. So ld-linux exhibits a user-visible program characteristic like ls would. (It's also an example of a staticly-linked program that is, perhaps unintuitive to some, a shared object.) Second, one can run ld-linux without ls, but one can't run ls without ld-linux. So that would speak for ld-linux being the "program", and ls being the module/plugin that provides the hook (commonly "main" for C programs, but it's not necessarily fixed), rather than ld-linux being a set of hooks to ls.
In the example below, the same example used in the ldd man page, we can the exact shared objects linked in.
ldd is just some sh code that invokes ld-linux and instructs it to print-and-exit after having processed relocations.
IF you use LD_PRELOAD, you can force an override of "normal" resolution... Cause different versions of libraries to be used.
LD_PRELOAD has no effect on ld-linux.so itself. It cannot have, because the code to evaluate LD_PRELOAD in the first place already is in memory. So LD_PRELOAD (or LD_LIBRARY_PATH) don't affect _all_ shared objects in the process image. So your suggestion to "just use LD_PRELOAD" is completely bogus and utterly flawed.
On 4/19/21 1:44 AM, Jan Engelhardt wrote:
On Monday 2021-04-19 02:21, Bruce Ferrell wrote:
If a program is statically linked at build time, attempts at loading additional dynamic link libraries at run time NEVER happens. No, not "never".
$ cat x.cpp #include <pwd.h> int main(){setpwent();} $ g++ x.cpp -static x.cpp:(.text+0x5): warning: Using 'setpwent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking $ strace -e open,openat ./a.out openat(AT_FDCWD, "/lib64/libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = 3
If a "stupid link" errors has happened, the build never completes... Which was exactly my point. Linda has a stupid link error, it's just that it happens during runtime (but still with a linker).
No, not really, especially not for the case of dynamicly-linked executables.
Analysis of LD_PRELOAD/LD_LIBRARY_PATH happens by ld-linux.so, which is not a hook but a program in its own right. Good lord you're pedantic!
ld-linux.so is a dynamic link library. The so extension means "shared object" and I know a DLL is windows nomenclature. I know the man page for ldd calls ld-linux a program. One can actually run ld-linux-x86-64.so.2 from the command line and get something out of it, which is not the case for e.g. /lib64/libacl.so.1. So ld-linux exhibits a user-visible program characteristic like ls would. (It's also an example of a staticly-linked program that is, perhaps unintuitive to some, a shared object.)
Second, one can run ld-linux without ls, but one can't run ls without ld-linux. So that would speak for ld-linux being the "program", and ls being the module/plugin that provides the hook (commonly "main" for C programs, but it's not necessarily fixed), rather than ld-linux being a set of hooks to ls.
In the example below, the same example used in the ldd man page, we can the exact shared objects linked in. ldd is just some sh code that invokes ld-linux and instructs it to print-and-exit after having processed relocations.
IF you use LD_PRELOAD, you can force an override of "normal" resolution... Cause different versions of libraries to be used. LD_PRELOAD has no effect on ld-linux.so itself. It cannot have, because the code to evaluate LD_PRELOAD in the first place already is in memory. So LD_PRELOAD (or LD_LIBRARY_PATH) don't affect _all_ shared objects in the process image. So your suggestion to "just use LD_PRELOAD" is completely bogus and utterly flawed.
As I said before, pedantic. LD_PRELOAD doesn't affect shared objects... Only programs, even those that masquerade as shared objects (thanks for that. I never paid much attention to it before nor to the fact the ldd was "just" a shell script that invokes ld-linux... Good to know, but not particularly useful for the question that started this) ldd /lib64/ld-linux-x86-64.so.2 statically linked and that's why LD_PRELOAD has no effect on it... It's not just a program, it's a statically linked program that uses no external shared objects and has no need to resolve them. My entire point was that LD_PRELOAD effects programs the are dynamically linked (not those that are statically linked) and can be used, in conjunction with ld-linux and the rest of the ELF executable format to over ride library/shared object/program loading. I can only conclude by your demonstrated knowledge that you chose to ignore that point in order to continue to call people/situations name and "bike shed" the original question. I've spent enough time on you and this so I'm done with you and this discussion. Thanks for the trivia added to my store... it may be useful someday.
On Monday 2021-04-19 15:43, Bruce Ferrell wrote:
LD_PRELOAD doesn't affect shared objects... Only programs [...]
My entire point was that LD_PRELOAD effects programs the are dynamically linked (not those that are statically linked)
LD_PRELOAD=/lib64/libanl.so.1 /lib64/ld-linux-x86-64.so.2 --list /bin/true ld-linux is a program, and it is a shared object, and it also happens to be static (depfree). LD_PRELOAD influences the code's flow.
I can only conclude by your demonstrated knowledge that you chose to ignore that point in order to continue to call people/situations name and "bike shed" the original question.
The original question was long answered but you chose to ignore all that, bringing up how LD_PRELOAD is the holy grail to symbol problems::
The one thing you CAN try is is a somewhat obscure thing, and you still need to have the old libraries to make it work: The LD_PRELOAD "trick":
You basically asked to be disproven in the context of the problem (which was that an incorrect loader was used). Now stop wasting people's time.
|On 2021/04/12 02:36, Andreas Schwab wrote: |
On Apr 10 2021, L A Walsh wrote:
you may want to look up how many programs had to be re-linked and re-released in the TW release where glibc changed.
That number was zero.
Andreas. |Because glibc changed to 2.33, a large number of packages had to be updated.
|Zero != large number. As so often you misinterpret (on purpose?). The build service has to rebuild every package that depends on a changed package. So the package is recompiled and not simply relinked. In a running system only the newly built library usually needs to be updated if no binary accesses parts of the library it isn't supposed to. That is completely different from having to relink in a running system. The glibc developers worked hard over the decades to a) hide symbols that are only supposed to be used internal to the lib and b) version symbols. Philipp
On 4/11/21 4:57 AM, L A Walsh wrote:
On 2021/04/09 00:30, Adrian Glaubitz wrote:
You may want to look up how shared libraries work as what you describe here is wrong.
Shared libraries use a stable binary interface which is why you don’t have to update the programs using them if you make smaller changes such as security updates to the shared library which don’t alter the ABI.
you may want to look up how many programs had to be re-linked and re-released in the TW release where glibc changed. numbers. It doesn't matter if it is compatible or incompatible. Every "libc.so.6" user on the system need to be re-installed. That's the update nightmare.
Are you talking about "Had to be relinked" or "Had there package rebuilt because openSUSE chose to" the two are very different things. Strictly programs only have to be relinked if the so number changes, ie we go from "libc.so.6" to "libc.so.7" on openSUSE Tumbleweed we choose to rebuild a package whenever a dependency changes. We don't do this for Leap updates however and other distro's such as Debian also don't do this I believe.
The 1 library release changes, and 100's of programs stop working.
It would supprise me if this was true on "standard" openSUSE installs, where either the package manager takes care of it and installs all the new packages or a user has chosen to compile a binary from source in which case they would only need to rebuild if the sonumber changes.
Not until you find a program that was statically linked can you hope to get back to a working system. Whatever model of shared library use that causes that is certainly not ideal.
How do you define "working system" because for me everything I need for a "working system" comes from the package manager and therefore gets updated together. Even if something breaks these days we include busybox statically linked on all tumbleweed systems so you have access to basic tools to repair stuff.
It has been that way for many years and yet still can't be fixed?
I don't think its been fixed because it hasn't been seen as an issue, the rebuilds have some advantages and prevent some bugs from packages that don't correctly declare that the things using them need to rebuild and on standard tumbleweed setups it doesn't cause any issues because the package manager deals with it. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
participants (10)
-
Adrian Glaubitz -
Andreas Schwab -
Bruce Ferrell -
Jan Engelhardt -
Johannes Meixner -
John Paul Adrian Glaubitz
-
L A Walsh -
Philipp Thomas -
Simon Lees -
Stefan Seyfried