Alright, I worked up a little proof-of-concept demo here <https://github.com/staticfloat/dltest/tree/master>, but the long and the short of it is that you should be able to alter the rpath of YOUR library to include whatever paths you need, (probably relative to @loader_path so that your library just needs to know the relative path to openblas and friends) and you'll then be able to dlopen these guys to your heart's content.
If you have any questions about this, please feel free to ask, but it should be as simple as adding a -Wl,-rpath,@loader_path/../lib or whatever to the linker options for your library. -E On Tue, Aug 12, 2014 at 2:02 PM, Jeff Waller <truth...@gmail.com> wrote: > > > On Tuesday, August 12, 2014 12:40:02 PM UTC-4, Elliot Saba 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) >> >> > Nice, this is a useful. I knew about rpath and am using it, but not the > option and the grep to pull it out of compiled binary for verification. > I've verified that rpath is part of the object code created and is the > right value (or at least corresponds to a value of DYLD_LIBRARY_PATH) that > makes things work. > > > >> 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 >> > > I think this is the critical problem. I did try that, BUT. I'm not > creating an executable but another dynamically loaded library -- a module > -- which is loaded by another system at runtime. I have no control of that > other system, only the module. > > >> * Change the RPATH of libjulia itself >> > > I have no control over that; this is for others. This has to work with > any deployment, but I am able to control how my thing is compiled. I can > insert any flags, constants, or run any sort configuration gathering script > I want as a pre-compilation step (within reason of course). > > >> * 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) >> > > Well this looks like what I will have to do for the time being at least. > I agree this is the least desirable. > > >> * 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 >> > > Likewise as above, I have no control over that. > > >> >> >> On Tue, Aug 12, 2014 at 3:12 AM, Jeff Waller <trut...@gmail.com> 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 >>> >>> >>> >>> >>
