Google Summer of Code 2009: Mentors needed!

Jordan K. Hubbard jkh at apple.com
Wed Mar 11 17:25:20 PDT 2009


On Mar 11, 2009, at 1:47 PM, Daniel J. Luke wrote:

> On Mar 11, 2009, at 4:04 PM, Jordan K. Hubbard wrote:
>> More to the point, there are already scenarios today (and far more  
>> in FreeBSD's ports collection, where the efforts to address this  
>> have taken on an increasingly desperate and hacky nature) where you  
>> simply cannot have two desired ports installed at the same time due  
>> to conflicting, mutually-exclusive dependencies.  Port Foo depends  
>> on library Bar, version X.  Port Blah depends on library Bar,  
>> version Y.  X and Y are incompatible with eachother, and Foo cannot  
>> be easily ported to Bar-Y, just as Blah cannot be easily ported to  
>> Bar-X (we're talking about some old software in many situations,  
>> where there's just no one available to fix things "correctly" by  
>> adapting to the latest revision of Bar).
>
> 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.  This is why static archives are generally  
discouraged on MacOSX - you want the extra level of indirection in  
fulfilling the API contract.

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

- Jordan



More information about the macports-dev mailing list