On Mar 23, 2009, at 12:11 AM, Jay A. Kreibich wrote: > Not exactly. A dylib doesn't know where it is, but it does like a > full path to the things it links to (i.e. libgcc, libSystem). You > can dig through the MachO header with otool(1). > > The big sticky point with dylib files vs ELF .so files is that Apple > provides no simple tool to re-write the paths inside the dylib file > (IIRC, libtool under Linux will do this).
install_name_tool does this >> Using a static library means the sqlite program can be installed >> whereever the user likes, as long as they know how to run it (ie >> it's in >> their PATH). No admin permissions needed. > > Outside of the minor detail that Mach-O has no concept of a "static > library", There is static vs shared linking, at compile time. OSX does have both of these. There is also static vs dynamic loading, at run time. OSX can do both of these also. >> With a dylib, the program can still be anywhere, but the dylib >> needs to >> be where the program expects it, normally in /usr/local/lib, which >> needs >> admin permissions. Either a script to copy it there could work >> (again, >> there's the issue of us being Mac users), or a Mac installer >> package is >> needed. > > For stuff like this, I don't think anyone is expecting an installer. > If you need one, you should be using some kind of package management > system for installing SQLite. > > After all, neither the Windows SQLite3.DLL nor the Linux > libsqlite3.so > download distributions have any kind of install scripts-- the > downloads are just the raw library files. No reason for a Mac OS X > .dylib distribution to be any different than the Linux .so > distribution. > People either know what the files are and what to do with them, or > they're better off being confused. > OSX is OSX. Windows is Windows. Linux is Linux. The others may be simpler to allow just copying the binaries to wherever you like, but, in a default build at least, a library must be put in a particular place if you don't want to muck around with DYLD_LIBRARY_PATH. You could post-process the library with install_name_tool to make the program use a relative path - @executable_path/libsqlite.3.dylib - and then the program can be right next to the library. > BTW, part of the reason I'm asking these questions is that I'm trying > to write some docs having to do with the build/install process of > SQLite on different platforms. I've got a lot of UNIX experience, so > the Linux/Mac stuff is pretty easy, but I'm a bit of a newbie on > Windows. If there are any folks out there that have some cross > platform experience (i.e. speak UNIX) but spend a fair amount of time > under Windows, I'd love to hear from you. Well, if you're writing installation instructions, then that's simple - copy the program to whereever you like and use it. I don't think the binaries are intended for developer use of the library, no headers are included. So a shared library is not needed. ----- William Kyngesburye <kyngchaos*at*kyngchaos*dot*com> http://www.kyngchaos.com/ Earth: "Mostly harmless" - revised entry in the HitchHiker's Guide to the Galaxy _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
