Yes, Jameson brings up a really important point; if you do end up mucking around with any of the LIBRARY_PATH variables, they have silent defaults that should be added in. You can read about it in the man page linked above, but modifying the RPATH of the binary is a better choice in virtually every case. -E
On Tue, Aug 12, 2014 at 1:14 PM, Jameson Nash <[email protected]> wrote: > Either of those variables an be modified, but in both cases you should be > attentive to the side effects. For example, IIRC, if the fallback path is > set, the link won't search the usual "fallback" locations, like /usr/lib > (unless you explicitly add them to your fallback path) > > The primary failure case for usage of either environment variable is the > same: having multiple possible libraries that could satisfy a dependency, > and ending up with multiple copies of the dylib loaded, with independent > global state. > > > On Tuesday, August 12, 2014, Elliot Saba <[email protected]> wrote: > >> Since Julia's libraries are in a non-standard directory, (usually >> <prefix>/lib/julia, where <prefix> is the root of your julia installation) >> we rely on a dynamic linker feature known as the RPATH to find these >> libraries at runtime. >> >> You can inspect the rpath of the julia executable with otool: >> >> $ otool -l julia | grep -A 2 LC_RPATH >> cmd LC_RPATH >> cmdsize 48 >> path @executable_path/../lib/julia (offset 12) >> -- >> cmd LC_RPATH >> cmdsize 40 >> path @executable_path/../lib (offset 12) >> >> This is encoded into the binary calling julia by putting in extra linker >> commands when compiling julia. Things like >> -Wl,-rpath,"@executable_path/../lib" >> >> I haven't played around with whether encoding RPATHS into libraries will >> work, so you either have to try one of the following: >> >> * Change the RPATH of the executable you're embedding julia into >> * Change the RPATH of libjulia itself >> * Tack things onto DYLD_FALLBACK_LIBRARY_PATH (Try to stay away from >> DYLD_LIBRARY_PATH, it's better to mess with the FALLBACK variant >> <http://stackoverflow.com/questions/3146274/is-it-ok-to-use-dyld-library-path-on-mac-os-x-and-whats-the-dynamic-library-s> >> when you can) >> * Move the libraries into an easier-to-find place. Either a place that >> is already on your executable's RPATH, or a location that is searched by >> default by the linker. The default locations are the default list of >> DYLD_FALLBACK_LIBRARY_PATH entries, listed in this man page >> <https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/dyld.1.html>, >> and are $(HOME)/lib:/usr/local/lib:/lib:/usr/lib. >> -E >> >> >> On Tue, Aug 12, 2014 at 3:12 AM, Jeff Waller <[email protected]> wrote: >> >>> This is on OS/X >>> >>> I do have a workaround, but I'd like to get to the bottom of it. I >>> don't see anywhere in the code where either of these 2 libraries are loaded >>> explicitly --- maybe it's in loading sys.ji? My workaround can be to set >>> an env variable, but it would be better to understand and address the >>> problem directly. >>> >>> If DYLD_LIBRARY_PATH is set to point to the Julia library directory, >>> then all works, but if this environment variable is not set, then the >>> following occurs >>> >>> ==== >>> >>> Warning: error initializing module LinAlg: >>> >>> ErrorException("error compiling __init__: error compiling check_blas: >>> error compiling blas_vendor: could not load module libopenblas: >>> dlopen(libopenblas.dylib, 1): image not found") >>> >>> Entropy pool not available to seed RNG; using ad-hoc entropy sources. >>> >>> Warning: error initializing module Random: >>> >>> ErrorException("could not load module libdSFMT: dlopen(libdSFMT.dylib, >>> 1): image not found") >>> === >>> >>> >>> Those additional errors I'm sure are just side effects cascading form >>> failing to load those libraries. The engine still does function, but the >>> linear algebra stuff is unavailable. I've tried various combinations of >>> jl_init and jl_init_with_image to no effect. >>> >>> -Jeff >>> >>> >>> >>> >>
