[GSLL-devel] GSLL handling lib name under CCL

[Liam Healy]

I have made this change removing the "lib/" part of the path for Darwin (in
the cffi-libffi branch, which is what I am maintaining now, and requires
the cffi-libffi branch of Antik and the fsbv branch of CFFI).  As far as
CFFI accepting a pathname is concerned, see this recent
email<http://lists.common-lisp.net/pipermail/cffi-devel/2012-February/003693.html>;
this should be a fixed problem in CFFI.  So do we need the
ccl:native-translated-namestring anymore?

Liam

Head:       2ea64e9044 - Rename dependent system cffi-libffi, fix Darwin
path


On Fri, Nov 25, 2011 at 11:48 PM, Yuan MEI <yuan.mei at gmail.com> wrote:

> I think it is a good idea.  (gsl-config-pathname
> "lib/libgslcblas.dylib") could be abandoned and (:darwin
> "libgslcblas.dylib") would just work fine.  I have already confirmed
> such change works on CCL 1.7 and SBCL 1.0.52 (both are x86-64, on
> MacOSX Lion).
>
> Yuan
>
> (cffi:define-foreign-library libgsl
>  (:darwin "libgsl.dylib")
>   (:cygwin "cyggsl-0.dll")
>  (:unix (:or "libgsl.so.0" "libgsl.so"))
>  (t (:default "libgsl")))
>
> On Thu, Nov 24, 2011 at 10:27 PM, Liam Healy <lhealy at common-lisp.net>
> wrote:
> > In light of this:
> >
> >
> http://lispcaveats.tumblr.com/post/13259176455/ffi-linking-against-shared-libraries
> >
> > I'd like to reconsider these changes.  Can we remove the special-case
> > :darwin :ccl conditional that has the literal path, and leave this up to
> > dlopen?
> >
> > Liam
> >
> > On Mon, Oct 17, 2011 at 11:16 PM, Liam Healy <lhealy at common-lisp.net>
> wrote:
> >>
> >> Yuan,
> >>
> >> Thanks for the patch.  I don't use MacOSX so I can't test it, but I've
> >> committed it.  If possible, in the future please join the mailing list
> >> and post your items there.  As far as your CFFI suggestions go, I
> >> encourage you to post them on the cffi-devel list; Mac users seem to
> >> have a lot of trouble with paths and anything that improves that
> >> situation should be welcome.
> >>
> >> Liam
> >>
> >> On Thu, Oct 13, 2011 at 5:46 PM, Yuan MEI <yuan.mei at gmail.com> wrote:
> >> > Hi Liam,
> >> >     I've started using GSLL.  It is wonderful!  I just discovered a
> >> > glitch though, when using CCL under MacOSX, it complains that a
> >> > #P"xxx.dylib" is not accepted.  I'd rather think cffi should be blamed
> >> > for not accepting a path, but I'd like to let you know that there is
> >> > this issue and here is a quick fix.  Actually a better portable way
> >> > should be implemented to translate #P"" to a string that cffi could
> >> > understand, or better cffi should be modified to accept #P in any CL
> >> > implementation on any platform.
> >> >
> >> > Thanks,
> >> >
> >> > Yuan Mei
> >> >
> >> > diff --git a/init/init.lisp b/init/init.lisp
> >> > index 41ef370..e632f09 100644
> >> > --- a/init/init.lisp
> >> > +++ b/init/init.lisp
> >> > @@ -66,7 +66,9 @@
> >> >      (merge-pathnames pn (pathname (format nil "~a/" (gsl-config
> >> > "--prefix"))))))
> >> >
> >> >  (cffi:define-foreign-library libgslcblas
> >> > -  (:darwin #.(gsl-config-pathname "lib/libgslcblas.dylib"))
> >> > +  (:darwin #+ccl #.(ccl:native-translated-namestring
> >> > +                     (gsl-config-pathname "lib/libgslcblas.dylib"))
> >> > +           #-ccl #.(gsl-config-pathname "lib/libgslcblas.dylib"))
> >> >    (:cygwin "cyggslcblas-0.dll")
> >> >    (:unix (:or "libgslcblas.so.0" "libgslcblas.so"))
> >> >    (t (:default "libgslcblas")))
> >> > @@ -80,9 +82,12 @@
> >> >  (cffi:load-foreign-library "/lib/lapack/cygblas.dll")
> >> >
> >> >  (cffi:define-foreign-library libgsl
> >> > -  (:darwin #. (gsl-config-pathname "lib/libgsl.dylib"))
> >> > +  (:darwin #+ccl #.(ccl:native-translated-namestring
> >> > +                     (gsl-config-pathname "lib/libgsl.dylib"))
> >> > +           #-ccl #.(gsl-config-pathname "lib/libgsl.dylib"))
> >> >    (:cygwin "cyggsl-0.dll")
> >> >    (:unix (:or "libgsl.so.0" "libgsl.so"))
> >> >    (t (:default "libgsl")))
> >> >
> >> >  (cffi:use-foreign-library libgsl)
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/gsll-devel/attachments/20120219/93918f9d/attachment.html>