Re: guile dlopen problems on Mac OS X

[Ken Raeburn]

On Aug 4, 2009, at 15:22, Andy Wingo wrote:
> > 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.

If I adjust LD_LIBRARY_PATH but don't create the .so symlink, "guile- 
tools compile ..." fails.
If I adjust LD_LIBRARY_PATH and create the .so symlink, it works.
So, I think it really is searching for the file with the .so suffix.


> > 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.

The dlopen man page on 10.5 says it checks $LD_LIBRARY_PATH,  
$DYLD_LIBRARY_PATH, the current working directory, and  
$DYLD_FALLBACK_LIBRARY_PATH, in that order, if there's no slash in the  
name.  If there is a slash, the handling is a bit different, and  
LD_LIBRARY_PATH is not used.  I changed LD_LIBRARY_PATH in my test.

> > 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? :-)

Thinking about it. :-)  It'll get me away from the Emacs code for a  
little while....

Ken