A question on dynamic linking / version-changing libraries

[Michael]

On 2017-03-05, at 9:27 AM, Brandon Allbery <allbery.b at gmail.com> wrote:

> 
> On Sun, Mar 5, 2017 at 11:43 AM, Michael <keybounce at gmail.com> wrote:
> Why does Macports generate libraries that follow the 1970-era linking strategy?
> 
> ... And we are not in a position to rewrite/reimplement stuff into a frameworks-based model, if upstream hasn't already done it.

I wouldn't expect re-writing things.

I'm curious more as to: Why do we still generate code that links against a fixed-name library? Why does that name not include a version/API reference? Why not make static linked stuff, so that changes in the libraries don't break things?

If dynamic linking is good/desired even now, why do we link to "libpng.a" or "libicu.a" or "libarchive.a", and not "libpng-0.98.a" vs "libpng-1.0.a", etc?

If dynamic linking has the inherent, unavoidable problem of "Can't mix two different programs that want different versions of a system library on the same installation", why not use static linking?

The question of "Why do frameworks behave differently and link so differently" is similar, but not identical. (And I don't understand the whole idea of "Ship separate, unlinked copies of the frameworks, that will not be shared with anyone else, but still have all the startup overhead of runtime linking")
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20170305/f0a42194/attachment.html>