Page MenuHomeFreeBSD

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

Authored by jhb on Aug 27 2025, 8:29 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Oct 9, 3:31 PM
Unknown Object (File)
Thu, Oct 9, 3:31 PM
Unknown Object (File)
Thu, Oct 9, 2:17 PM
Unknown Object (File)
Thu, Oct 9, 2:17 PM
Unknown Object (File)
Thu, Oct 9, 1:15 PM
Unknown Object (File)
Wed, Oct 8, 7:02 AM
Unknown Object (File)
Wed, Oct 1, 8:16 AM
Unknown Object (File)
Tue, Sep 30, 9:00 AM
Subscribers

Details

Reviewers
des
cy
emaste
ivy
Group Reviewers
krb5
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.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 66582
Build 63465: arc lint + arc unit

Event Timeline

jhb requested review of this revision.Aug 27 2025, 8:29 PM
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?

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

tools/build/mk/OptionalObsoleteFiles.inc
3699

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

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.

tools/build/mk/OptionalObsoleteFiles.inc
3699

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

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.

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.

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

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

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.