On 2017-03-05, at 9:27 AM, Brandon Allbery <[email protected]> wrote:
> > On Sun, Mar 5, 2017 at 11:43 AM, Michael <[email protected]> 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")
