Re: foreign-library-directories (Was Re: [Matlisp-commit] [matlisp-git]matlisp branch master updated. 2012-02-23-12-gb4755e8)
Raymond Toy <[email protected]> Sun, 11 Mar 2012 10:54:53 -0700
| Newsgroups | gmane.lisp.matlisp.devel |
|---|---|
| Message-ID | <[email protected]> |
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. Ray ------------------------------------------------------------------------------ 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/