A question on dynamic linking / version-changing libraries

[Brandon Allbery]

On Sun, Mar 5, 2017 at 12:33 PM, Michael <keybounce at gmail.com> wrote:

> 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?


Mostly, because of Apple's ecosystem which is actively hostile to static
linking (left over from PPC days where the ABI essentially forbade static
linking; to understand why, you'd want to study the PPC CPU family closely)
and Apple-provided toolchain limitations (mainly ld, and while we do
replace ld sometimes for bug fixes, we are not in a position to alter its
basic behavior: in this case, version information is present but only used
for validation, and this has interactions with things like compatibility of
software across OS X versions. Or, more concretely: we already get
complaints when MP-built stuff doesn't play along with Matlab, and it'd get
far worse if Matlab's (ab)use of DYLD_LIBRARY_PATH ran headlong into
treating version information as part of a dylib name).

Also fixed-*path* libraries are part of the Mach-O format and the tooling
does not exist to override this well... and as of Sierra there are Mach-O
limitations coded into the kernel (link command table size limit) that
restrict your ability to override it (upstream ghc is already fighting with
this due to the way its dependencies work).

In short: most of this is not our call, and we are not in a position to
push on the people who could do it. MacPorts has to live with what *is*.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20170305/5c38ac5c/attachment.html>