Menu
▾
▴
matlisp-devel
|
From: Raymond T. <toy...@gm...> - 2012-03-10 16:32:18
|
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 <aks...@gm...> > 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? Ray |
|
From: Akshay S. <aks...@gm...> - 2012-03-10 16:38:41
|
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 <aks...@gm...> 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. Akshay |
|
From: Raymond T. <toy...@gm...> - 2012-03-10 16:54:57
|
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 <aks...@gm...> 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. Ray |
|
From: Akshay S. <aks...@gm...> - 2012-03-10 17:10:23
|
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 <aks...@gm...> 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. > > Ray > Yes *f-l-d* has the full-path. Using (.. (t (:default "libblas"))) as before the commit, * Doing nothing else; zdotu/c tests fail. * Moving /usr/lib/libblas.so to something else; all tests pass. Akshay |
|
From: Akshay S. <aks...@gm...> - 2012-03-10 17:15:24
|
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 <aks...@gm...> 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 |
|
From: Raymond T. <toy...@gm...> - 2012-03-10 17:24:43
|
On 3/10/12 9:12 AM, Akshay Srinivasan wrote: > On 03/10/2012 10:24 PM, Raymond Toy wrote: > > 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. > ------------------------------------------------------------------------ > 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. Ray |
|
From: Akshay S. <aks...@gm...> - 2012-03-10 17:37:43
|
On 03/10/2012 10:54 PM, Raymond Toy wrote: > On 3/10/12 9:12 AM, Akshay Srinivasan wrote: >> On 03/10/2012 10:24 PM, Raymond Toy wrote: >> >> 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. >> ------------------------------------------------------------------------ >> > >> > 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. Akshay |
|
From: Raymond T. <toy...@gm...> - 2012-03-11 02:51:26
|
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. I think the only option we have is to undo this and set LD_LIBRARY_PATH to include libdir. This will work if you use make. If you do something else, this won't. We could add a script, matlisp, that sets up LD_LIBRARY_PATH correctly and runs the appropriate lisp. What do you think? Ray |
|
From: Akshay S. <aks...@gm...> - 2012-03-11 03:22:43
|
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. I wonder if this has something do with *darwin-framework-directories* in cffi. I'm not sure what it means though. > > I think the only option we have is to undo this and set > LD_LIBRARY_PATH to include libdir. This will work if you use make. > If you do something else, this won't. We could add a script, > matlisp, that sets up LD_LIBRARY_PATH correctly and runs the > appropriate lisp. I'm not happy with that because then it won't work, when loading matlisp on slime, unless I remember to set the LD_LIBRARY_PATH before actually opening Emacs. Can't we just set LD_LIBRARY_PATH through (run-system ..) inside start.lisp ? Akshay |
|
From: Raymond T. <toy...@gm...> - 2012-03-11 17:55:04
|
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 |
|
From: Akshay S. <aks...@gm...> - 2012-03-11 18:15:39
|
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 |
|
From: Raymond T. <toy...@gm...> - 2012-03-11 20:14:21
|
On 3/11/12 11:13 AM, Akshay Srinivasan wrote: > 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 :) > > Of course, if you use OSX and have the libraries somewhere else, this issue will bite you. I don't have that problem, so I'm ignoring it for now. Also, I took a closer look at how the libraries are built. Pretty much the same command is used on linux and osx, and I can see that the shared library is built with -L and -l options to specify the fortran libraries. But for whatever reason the information isn't (explicitly) recorded in the lib. At least otool doesn't show it, but, of course, the fortran libraries do eventually get linked. Not sure how that works, though. Ray |
Thanks for helping keep SourceForge clean.
X