Re: [Matlisp-devel] foreign-library-directories (Was Re: [Matlisp-commit] [matlisp-git]matlisp branch master updated. 2012-02-23-12-gb4755e8)

[Raymond T. <toy...@gm...>]

On 3/11/12 11:13 AM, Akshay Srinivasan wrote:
> On 03/11/2012 11:24 PM, Raymond Toy wrote:
>> On 3/10/12 7:20 PM, Akshay Srinivasan wrote:
>>> On 03/11/2012 08:21 AM, Raymond Toy wrote:
>>>> On 3/10/12 9:35 AM, Akshay Srinivasan wrote:
>>>>> On 03/10/2012 10:54 PM, Raymond Toy wrote: Dang.  You're
>>>>> right. I read the description of *f-l-d* backwards. I think
>>>>> your solution is probably the right one, and we should add
>>>>> @libdir@ to all the library paths.
>>>>>
>>>>> I think the backward description makes more sense. Oh well.
>>>>> Added @libdir@ to all the library paths.
>>>>>
>>>> Unfortunately, this breaks matlisp for me on osx.  It tries to
>>>> load the library but can't find all the dependent fortran
>>>> libraries so it dies because of missing symbols.
>>> That's odd. Are you using gfortran ? BLAS compiled with gfortran
>>> on my machine looks like it has already been linked with the
>>> gfortran stuff.
>> Looks like an issue on Darwin (OSX).  Same thing happens with cmucl
>> and ccl.  For both, I used gfortran to build the code.  On linux
>> and sparc, ldd shows that the libraries include dependencies on the
>> fortran libraries.  On darwin, otool -L shows only the dependency
>> on libSystem.
>>
>> So, perhaps this is a bug in automake/autotools in building shared 
>> libraries on OSX.
>>
>> For now, I've worked around this by adding a :darwin feature to 
>> define-foreign-library.  Works fine on OSX, linux, and sparc.
> That reassures our faith in CFFI :)
>
>
Of course, if you use OSX and have the libraries somewhere else, this
issue will bite you.  I don't have that problem, so I'm ignoring it for now.

Also, I took a closer look at how the libraries are built.  Pretty much
the same command is used on linux and osx, and I can see that the shared
library is built with -L and -l options to specify the fortran
libraries.  But for whatever reason the information isn't (explicitly)
recorded in the lib.  At least otool doesn't show it, but, of course,
the fortran libraries do eventually get linked.  Not sure how that
works, though.

Ray