Re: foreign-library-directories (Was Re: [Matlisp-commit] [matlisp-git]matlisp branch master updated. 2012-02-23-12-gb4755e8)
Akshay Srinivasan <[email protected]> Sun, 11 Mar 2012 23:43:02 +0530
| Newsgroups | gmane.lisp.matlisp.devel |
|---|---|
| Message-ID | <[email protected]> |
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 ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/