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/