site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com User-agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) Peter -- Peter O'Gorman - http://www.pogma.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... Paul Forgey wrote: DYLD_LIBRARY_PATH may help you get there, but it won't completely solve the problem. Let's say you have app which dynamically links to lib1 which links to lib2. lib1 and lib2 are in /that/directory although they have dylib names in /usr/lib. Setting DYLD_LIBRARY_PATH to include /that/directory will let the app link to lib1 without -L or -F, but it still won't find lib2. You can include both libraries in -l. While that's a pain to do because you have to anticipate the entire dependency graph, it might be easier than what you are doing now. DYLD_LIBRARY_PATH has nothing whatsoever to do with the linker. I would have thought that setting the NEXT_ROOT environment variable (which xcode does as far as I know) would fix this. This email sent to site_archiver@lists.apple.com