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

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