On Mar 11, 2009, at 8:25 PM, Jordan K. Hubbard wrote:
or port foo could just statically link to version X of the library and port blah can statically (or dynamically) link to version Y. (the build process for port foo could even build the old version X lib).That wouldn't work as a general rule, since back when "foo" was created, X would also likely be the "latest and greatest" and, of course, you would want to ship that as a .dylib since shipping it as a static archive would mean that every client embedded a copy of X within itself, leading to bloated memory consumption and no opportunity to ever update X in-place for security reasons, as previously discussed.
Right, so when X is latest and greatest, you don't statically link, but when you have to keep around old foo because it won't be updated for Y, you can just rebuild foo and statically link foo with the old X.
The problems you mention (bloated memory consumption, and hard to do security updates) are also present with the more complex solution of having every version available for linking in the depot. At least with statically linking the old and unmaintained program, the choice is not automatic and the brokenness is contained to that program.
This is why static archives are generally discouraged on MacOSX - you want the extra level of indirection in fulfilling the API contract.
indeed. In the case where you're installing an old and unmaintained library, though, I think it's desirable to limit it to only the old and unmaintained application that requires it, instead of having it generally available on the system.
I don't really want every version of every library on my system available for things to link to. Even if we somehow only track ABI changes, I still probably don't want every ABI version around.Maybe *you* don't, but anyone who needs every library on their system available for other reasons, and does a halfway reasonable job of garbage collection once in awhile, is not going to share that opinion at all.
until they get rooted because one version of the old lib they have (and didn't realize things were linked to) had a bug that never got fixed in that old version (since it was fixed in a 'supported' version, and not the obsolete one that was still around).
If the only benefit is keeping older applications running even when newer libs change the ABI or API and the older application can't be updated to use the new lib, then I don't see how the extra complication of having every version around and available for linking is the best solution.
Maybe there's some other problem it solves that I'm not seeing? -- Daniel J. Luke +========================================================+ | *---------------- [email protected] ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
