LD Changes To Implicit DSO Linking Update

[Chris Adams]

Once upon a time, Kevin Kofler <kevin.kofler at chello.at> said:
> And this makes this ld (mis)feature particularly silly, ld now gratuitously 
> errors on "undefined" symbols which would be found just fine at runtime.

No, it errors on undefined symbols that may or may not be found at
runtime.  Why do you want binaries that may or may not work, depending
on the configuration of shared libraries from other projects?

For example, let's say you have a program foo that uses routines from
libm but doesn't link with -lm.  Program foo does link with an image
processing library libbar that uses libm internally.  Now libbar
releases an update that drops the dependency on libm (maybe somebody
found a more efficient way to do the processing with integer math).
Since libbar still exports the same ABI (-lm vs. integer math is an
internal change), they don't change the so version.

The libbar update goes into Fedora, and suddenly program foo breaks
(when it hits certain code paths), for no obvious reason (maybe program
foo hasn't been updated in months).

You could even end up with an update respin where the necessary shared
library isn't even installed because neither foo nor libbar depend on it
(not the case for libm, but could be for other dependencies).

I like deterministic linking, not linking that says "well, maybe it'll
work, we'll let the user tell us if it breaks later".
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.