Re: MacOS X is not Linux!

[Russell Standish]

Bill Northcott wrote:
> So why bother?  Alex made his life simple by linking everything static. 
> Why not do that and avoid all this nastiness?
> 
> Unfortunately, making it easy for the original programmer makes life 
> harder for the Users.   The whole philosophy of the Mac since day one of 
> the project back in 1979 was to make things easier for the user, even if 
> that meant a little extra complication for the programmers.  Back then, it 
> was serious complication.   One could only build MacOS code on a Lisa and 
> move it to the target machine over a serial link.  Debugging had to run 
> the same way!   Nowadays, this is not really a problem except for people 
> trying to port products like Swarm whose build system contains implicit 
> assumptions about the way dynamic libraries build and run.
> 
> Why does it make it hard for the users to build static?  Say we discover a 
> bug in tcl.  If we compiled static, we have to rebuild tcl, tk, blt, Swarm 
> and every bit of code built on them.  Life's too short!
> 
> OTOH if we built dynamic we just drop in the patched tcl library and 
> everything else inherits the fixes.  Indeed if we used Objective-C, this 
> works not just for fixes but for new features.  Now we are cooking.  That 
> is why we need eventually to port to GNUstep.  so we can use AppKit.
> Enter Frameworks.  If you build needed libraries as frameworks, there is 
> no need to worry about DYLD_LIBRARY_PATH.  Frameworks are in a hierarchy: 
> those in ~/Library/Frameworks will override those in /Library/Frameworks, 
> which will override /System/Library/Frameworks.  Yet there is more!  A 
> framework in an application bundle will override everything.  So you could 
> package a Swarm application with tcl/tk/blt/hdf5 and the Swarm libraries 
> in an bundle and distribute it as a drag and drop install.  Try that on 
> Linux!  We are not finished yet.  Since the Frameworks also contain the 
> headers, your drag and drop install application is also an SDK for the 
> libraries.
> 
> This stuff may have a learning curve but it is way cool when you come to 
> do real work.  Reusable software and all that.
> 
> Finally the usual caveat:  I may have got some of the above wrong, please 
> feel free to comment/correct me, but I do feel the fog has lifted for me 
> in the last couple of weeks.  I can now see a much clearer way forward.
> 
> Bill Northcott
> 

>From my experience, Linux seems to dynamically link everything under
the sun as well. Personally, I'm not all that convinced by dynamic
linking - unless its an incredibally base level library like libc,
most libraries will only have one running application using them, and
that will only be using one or two subroutines, so you end up with
more code being shoved into virtual memory than if you had statically
linked libraries.

I'm not entirely convinced of the latter benefits of dynamic libraries
- usually a library upgrade breaks the program, even if the API hasn't
changed in a relevant way, but because the dynamic loader only knows
that the version number has changed, and so the API might be
inconsistent. Thus one needs to recompile the application as well. The
same problem occurs in Windoze with the dreaded "DLL error", sometimes
meaning one cannot run certain combinations of applications on the
same system as they're closed source, and not available for recompilation.

Of course its entirely possible that OSX has a superior dynamic loader
system that eliminates this problem, however forgive me if I remain
sceptical.

                                                Cheers



----------------------------------------------------------------------------
A/Prof Russell Standish                  Director
High Performance Computing Support Unit, Phone 9385 6967, 8308 3119 (mobile)
UNSW SYDNEY 2052                         Fax   9385 6965, 0425 253119 (")
Australia                                address@hidden             
Room 2075, Red Centre                    http://parallel.hpc.unsw.edu.au/rks
            International prefix  +612, Interstate prefix 02
----------------------------------------------------------------------------

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.