
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2017-03-05, at 9:27 AM, Brandon Allbery <<a href="mailto:allbery.b@gmail.com">allbery.b@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 5, 2017 at 11:43 AM, Michael <span dir="ltr"><<a href="mailto:keybounce@gmail.com" target="_blank">keybounce@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto;">Why does Macports generate libraries that follow the 1970-era linking strategy?</blockquote></div><br>... And we are not in a position to rewrite/reimplement stuff into a frameworks-based model, if upstream hasn't already done it.<br></div></div></blockquote><br></div><div>I wouldn't expect re-writing things.</div><div><br></div><div>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?</div><div><br></div><div>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?</div><div><br></div><div>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?</div><br><div>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")</div></body></html>