Re: [Matlisp-commit] [matlisp-git]matlisp branch master updated. 2012-02-23-12-gb4755e8

On 03/10/2012 10:24 PM, Raymond Toy wrote:
> On 3/10/12 8:36 AM, Akshay Srinivasan wrote:
>> On 03/10/2012 10:02 PM, Raymond Toy wrote:
>>> On 3/10/12 7:53 AM, Akshay Srinivasan wrote:
>>>> This is an automated email from the git hooks/post-receive 
>>>> script. It was generated because a ref change was pushed to
>>>> the repository containing the project "matlisp".
>>>> 
>>>> The branch, master has been updated via 
>>>> b4755e861709360bf208f0b9b479c388003274de (commit) from 
>>>> 035339c307401f593732418ecdba8fa6785b678d (commit)
>>>> 
>>>> Those revisions listed above that are new to this repository 
>>>> have not appeared on any other notification email; so we
>>>> list those revisions in full, below.
>>>> 
>>>> - Log 
>>>> -----------------------------------------------------------------
>>>>
>>>>
>>
>>>> 
commit b4755e861709360bf208f0b9b479c388003274de
>>>> Author: Akshay Srinivasan <[email protected]> Date: 
>>>> Sat Mar 10 21:13:48 2012 +0530
>>>> 
>>>> Made sure that CFFI loads our version of BLAS, when it is
>>>> asked to.
>>>> 
>>>> diff --git a/lib/lazy-loader.lisp.in
>>>> b/lib/lazy-loader.lisp.in index 11f3358..f67b5d0 100644 ---
>>>> a/lib/lazy-loader.lisp.in +++ b/lib/lazy-loader.lisp.in @@
>>>> -140,7 +140,7 @@ (unless @ATLAS_P@ ;; Use our blas and lapack
>>>> libraries (cffi:define-foreign-library blas -    (t (:default
>>>> "libblas")))) +    (t (:default "@libdir@/libblas"))))
>>>> 
>>> Somehow this doesn't look right.  Shouldn't cffi be looking in
>>>  *foreign-libraries-directories* first?  Is that not set up 
>>> correctly?
>> Doesn't look like it does. If I use the old version of the 
>> lazy-loader.lisp the tests for zdot fail (like in the ATLAS
>> build). Are you sure your version of CFFI isn't doing the same ?
>> 
>> I agree that it should look at *foreign-libraries-directories*
>> first; should report this as bug to CFFI.
>> 
> I'm almost 100% sure it's working.  Previously, *f-l-d* was set to 
> "lib/".  When I tried loading start.lisp from a lisp started from
> some other directory, loading the libraries failed.  When I changed
> *f-l-d* to the full path, I could load the libraries.
> 
> So make sure *f-l-d* has the full path to the matlisp lib
> directory. That should work.  Or temporarily rename the blas
> library in /usr/lib and see what's happening.
> 

This is apparently the way its supposed to work.
>From cffi/src/libraries.lisp :
------------------------------------------------------------------------
;;; Only after failing to find a library through the normal ways
;;; (eg: on Linux LD_LIBRARY_PATH, /etc/ld.so.cache, /usr/lib/, /lib)
;;; do we try to find the library ourselves.
------------------------------------------------------------------------


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/