OptionalObsoleteFiles.inc: Don't include shared libraries in OLD_FILES

[jhb]

Summary

Always use OLD_LIBS for shared libraries so that they are only deleted
by make delete-old-libs, not make delete-old.

Treat the runtime loader (ld-elf<NN>.so.1) for compat libraries as a
shared library as well since the compat shared libraries are treated
as libraries.

[jhb]

tools/build/mk/OptionalObsoleteFiles.inc

2853

I nearly bricked my laptop running main due to this entry today since it deleted libwind.so.11 needed by libcurl.so.4 and thus git (so I had no working git binary until I obtained a copy from another machine).

3699

My reasoning here is that we use OLD_LIBS for pam, etc. plugins as well.

8140

Curiously in the clause above this for MK_TESTS==no, these entries are correct. These might also be missing the .2 versions in the earlier clause?

[des]

tools/build/mk/OptionalObsoleteFiles.inc

3815

this is not a library, this is the run-time linker

8140

I believe this is intentional as libatf was never meant to be public, it's a private library now

[emaste]

tools/build/mk/OptionalObsoleteFiles.inc

3699

I think that's reasonable, even if these plugins don't really need to be handled as LIBS.

[ivy]

tools/build/mk/OptionalObsoleteFiles.inc

2853

sorry about that. for consistency, please move this entry to live with the other OLD_LIBS entries at the end of this block (line 3618).

3699

i believe we do this for PAM modules because we provide 32-bit versions in /usr/lib32, and using OLD_LIBS takes care of those automatically. since there are no 32-bit KDC plugins, we don't need that here.

however i don't feel very strongly about this one way or the other.

[emaste]

tools/build/mk/OptionalObsoleteFiles.inc

3699

Fair point. Maybe we should have a comment on the PAM entries referencing this.

[jhb]

tools/build/mk/OptionalObsoleteFiles.inc

3699

I think the point is should these be deferred to make delete-old-libs or not. That is, if 'lib<mumble>.so.122' is going to dlopen() these specific files, then they are dependencies of lib<mumble>.so.122 and shouldn't be deleted until lib<mumble>.so.122 is deleted. In that case, they need to be in OLD_LIBS just like the lib<mumble>.so.122 that depends on them.

3815

Yes, I specifically called it out in the commit log. It makes no sense to delete the runtime loader with OLD_FILES but still leave the shared libraries around via OLD_LIBS as you can't use those shared libraries without having the runtime loader. That is, if I do make delete-old WITHOUT_LIB32=yes today it will delete ld-elf32.so.1, but leave /usr/lib32/lib*.so.*, but without a way to make use of those libraries. In that regard, rtld is a kind of shared library (it's even built as PIC, etc.)

8140

Well, but if you look at this block of code, it's really odd. It's roughly:

.if ${MK_TESTS} == "yes"
# delete various files
.else
# delete many of the same files, but not exactly the same
.endif

This is in the else clause. The if clause uses OLD_LIBS and also lists usr/lib/libatf-c++.so.2. Arguably, the files listed in both places aren't conditional at all and are just truly-old files that should be in src/Obsoletefiles.inc. That is certainly true for /usr/lib/libatf* which became private over a decade ago (2014). The SHLIB_MAJOR bump from 1 to 2 for libatf-c++.so was also in 2014 so clearly the .1 versions should just be OLD_LIBS in src/Obsoletefiles.inc. However, there are several other duplicates in the two clauses that should also probably move. I kind of gave up on trying to understand / fix this as the logic is rather confusing and not at all clear.

[ivy]

tools/build/mk/OptionalObsoleteFiles.inc

3699

i believe these can only be loaded by /usr/libexec/krb5kdc, which is in OLD_FILES, so i would lean on the side of deleting the plugins along with the KDC binary since nothing else uses them.

@cy is the person to ask about this though.

[jhb]

tools/build/mk/OptionalObsoleteFiles.inc

3699

That would be a good reason for OLD_FILES, yes. It depends on what dlopens them. For pam modules it is libpam, so that is the reason for using OLD_LIBS rather than lib32, though the library loading is also why you end up with lib32 versions (so the two are correlated).

[jhb]

For now I will split some parts of this out into separate reviews.

[des]

tools/build/mk/OptionalObsoleteFiles.inc

3699

There's another aspect here, does krb5kdc know about versioning? libpam does and will look for pam_foo.so.N before pam_foo.so, but that's not standard practice. If krb5kdc doesn't know about versioning, then the symlink also needs to be in OLD_LIBS, because krb5kdc will never find the versioned plugins without the unversioned symlink. The bottom line is that OLD_LIBS wasn't really designed with plugins in mind and may not dtrt.

btw the obsolete.sh script I started working on a while back moves libraries to a backup directory instead of deleting them.