Clever Name TBD

Bob has an interesting post in his web log which includes some graphs that show the library dependencies in ls, python, and Mail.app.

ls links against two libraries (libncurses and libSystem) and picks up one extra from libSystem (libmathCommon... I'm not sure why that's a separate library, but there it is).

python links against libSystem as well as the CoreServices and Foundation frameworks, and picks up a fairly sizeable (perhaps a surprisingly large) number of extra libraries.

Mail links against some 14 libraries and frameworks and picks up more dependancies than one can look at without causing severe eye strain. I would guess that Mail uses a fraction of those libraries, but nevertheless loads all of them.

I've never been a fan of "umbrella frameworks" and this shows why. I'm even more distressed by the hiding of "subframework" so that I can't used them without loading up a crapload of libraries I don't care about.

Say, for example, that I want to write a program that uses the public API in CoreGraphics and nothing else. This should be straightforward, but I can't link to CoreGraphics; that framework is nested inside of the ApplicationServices framework and I have to link against that instead. So instead of loading one library, I am force to load a different library that loads the one I want plus twelve others, each of which links against some more libraries.

This severe library bloat, which is why Apple has put a lot of energy into optimizations in the linker such as prebinding and various loading tricks. These are good optimizations, mind you, but it would be nice if they weren't quite so necessary.