Once upon a time, Kevin Kofler <kevin.kofler@xxxxxxxxx> 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@xxxxxxxxxx> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
