[I haven't confirmed this for dylibs-- but i'm pretty sure this remains true as a dylib is nothing more than a framework executable with a funky extension and no wrapper directory] None. The searching for dylibs only happens at link time... Wherever the dylib/framework is found, that is where it must be every time the executable is run. Actually, I lied. When building a framework, you can actually specify an "install name" (see -install_name on libtool). Basically, the install name is the full path to wherever the framework should be installed. By using the install name creatively, one can build entire trees of projects-- lots of frameworks and apps/tools-- someplace other than the final installation spot (see below). When a framework is built, the install name is actually encoded in the framework. As well, whenever a framework or other executable is linked, the full paths to all other frameworks/dylibs are included in the executable. You can see which frameworks are used and where they should be located by: Mac OS X: % otool -L executable Solaris: % ldd executable NT: right click teh executable, select Quick View and look at the import table. --- Why are the full paths encoded everywhere on Solaris and NT? To avoid serious risk of a security violation. If it were possible for the user to move and/or modify the framework or cause the app to link against a "fake" framework that dyna-loads the real thing, then it would be a relatively easy to task to violate the app in just about anyway one wanted. --- What is different about NT? NT does use a set of paths to search for DLLs on. It'll use the first one of any given name that it happens to find. This has advantages and disadvantages. Primary advantage is that you can shove DLLs anywhere and move 'em about freely-- as long as they are in the search path, they will be find. However, the disadvantages are numerous and have caused no end of hair pulling. I can't tell you how much time I or eithers I'm working with have lost because there was an old version of a DLL in the search path before the version under active development. Also, because the DLL must be in the search path, it means that development quality DLLs often end up in the search path and, if that DLL is used across multiple apps, may screw up other applications. Because the search path must have a set of directories, the DLL for a framework resides outside the framework-- typically in an Executables directory. This is a drag-- it means that it is impossible to consider a framework as a self contained resource. --- (see below) I have written something like OmniMake-- only a hell of a lot simpler-- that allows one to build standalone sets of frameworks and apps for testing/debugging purposes. It can also control information about install versions without necessarily having to adjust every single PB.project. It is a complete hacque, totally undocumented, and still requires a bit of tweakage to make work.... but has saved us a tremendous amount of time and is being used in production environments. If anyone wants to play, send me email. It requires WO 4.0 and the multiscript shell (see ftp://ftp.codefab.com/pub/unsupported/). b.bum justin armstrong wrote: > I've reduced my question down to one sentence: > In MacOS X Server, what paths are searched at run time for dynamic libraries?
