Hi Ken, On Tue 04 Aug 2009 11:26, Ken Raeburn <[email protected]> writes:
> After installing 1.9.1 on Mac OS X (10.5.7), and updating $PATH to point > to the installation 'bin' directory: > > % guile-tools compile -o ack.go ack.scm > ERROR: In procedure dynamic-link: > ERROR: file: "libguile-srfi-srfi-1-v-4", message: "dlopen(libguile- > srfi-srfi-1-v-4.so, 9): image not found" > % > > The correct suffix for dynamically-linked libraries on Mac OS X is > ".dylib". This is just a problem in the error message; the .so string comes from libltdl, not from Guile. > However, even if I make a symlink with the .so suffix, I still get the > same error reported. If I also set LD_LIBRARY_PATH to point to this > directory, then it works. Do you mean DYLD_LIBRARY_PATH, or DYLD_FALLBACK_LIBRARY_PATH ? There is also LTDL_LIBRARY_PATH, which is the one that I think should work, but I think in that case there is a libltdl bug on mac os that forces me to use DYLD_FALLBACK_LIBRARY_PATH on the machines that I'm interested in. > But this isn't necessary to simply invoke > the "guile" or "guile-tools" executables. Perhaps they should ensure > that the installation library directory gets searched via one of the > environment variables dlopen checks, or check that directory explicitly > if dlopen fails? They do have built-in knowledge of where to find the > Scheme code they want to load; why should the supplied executable > libraries be different? Good question. Probably scm_dynamic_link should ensure that the right dir is in ltdl's path. Care to submit a patch? :-) Andy -- http://wingolog.org/
