views:

65

answers:

2

I'm trying to compile a version of convert (one of the ImageMagick tools) for distribution with a Cocoa app I'm writing, and I've mistakenly bundled a version that relies on shared libraries my users don't have (twice, already). Thus, I'm trying to pare down the list. After stripping out everything I didn't need, running otool -L convert gives me the following list:

/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4)
/usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

and for another tool bundled with the same app, I'm also using:

    /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0)

Is it safe to assume that any out-of-the-box installation of Leopard or above will have these libraries on board? (More generally, my google-fu has failed me, so if anyone can point me to a resource that would answer these questions for me, I'd be eternally grateful!)

A: 

Yes, on my Snow Leopard box that has no changes to /usr/lib, all of these libraries exist

Paul Betts
Thanks guys! Appreciate the help.
Winawer
+1  A: 

If the library path is /usr/lib, it should be available on a vanilla OS X of the level you're running on (and presumably above). Third-party apps and installers should not be installing into /usr/lib.

Ned Deily
Yeah, but if you're building your own stuff with Automake, it's really easy to sudo make install stuff into /usr/lib by accident
Paul Betts
Unless you consider ./configure --prefix=/usr an accident, they would rather go into /usr/local
0xced