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

[Akshay S. <aks...@gm...>]

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

Akshay