Re: using GSL with cblas via FFI

[cong gu <gucong43216@gmail.com>]

On Sun, Jun 3, 2012 at 11:15 PM, Thien-Thi Nguyen <ttn@gnuvola.org> wrote:
> () cong gu <gucong43216@gmail.com>
> () Sun, 3 Jun 2012 17:04:29 -0500
>
>   I found libtool offers a way to make a shared library globally
>   available.  So I wrote a patch that provides `dynamic-link-global'.
>   A call like `(dynamic-link-global "libgslcblas")' should make
>   things work.
>
>   I don't know whether it is portable, though.  Documentation of
>   libtool mentioned that not all loaders are able to act upon this
>   `advice'.
>
> Aside from portability, there is also coherence in design to consider.
> In (info "(libtool) Libltdl interface") i see seven funcs that take
> ‘lt_dladvise *ADVISE’:
>
>  lt_dladvise_init
>  lt_dladvise_destroy
>  lt_dladvise_ext
>  lt_dladvise_global
>  lt_dladvise_local
>  lt_dladvise_resident
>  lt_dladvise_preload
>
> The first two manage the object; the last five mutate its internals.
>
> Your proposal sequences ‘lt_dladvise_ext’ and ‘lt_dladvise_global’
> with ‘lt_dlopenadvise’, essentially.  This is fine for your needs
> today, no doubt.  How about further on, when you need _resident
> or _preload, or _FOO (in some future libtool release), or when you
> want _global but not _ext?
>
> With five bits, you have 32 combinations (actually less, as not all
> combinations are meaningful, e.g., _global and _local together).  It
> would be awkward to eventually find all these combinations wrapped
> individually, in C and exposed to Scheme.  What is a better way?

Yes, I addmit this is a quick hack to the problem at hand.  And your
consideration is absolutely right.

Firstly, I think this feature is essential to a more useful dynamic
FFI.  A shared library may require another shared library to actually
run some function, for example in the case of libgsl and libgslcblas.
It is annoying to link them into one object before I can use the
library.  This patch is just a proof of idea or a working hack.  I
really hope this can serve as an inspriation to someone more familiar
with guile's design, and this functionality will someday be
incorprated in guile in a better way.  At the moment, I can write and
live with a extension module doing the job.

Back to the design, the original `dynamic-link' is just equivalent to
calling only `lt_dladvise_ext' and leave other "advise" unspecified or
platform dependent. Maybe we can add some optional argument to specify
those "advise".  Some test maybe needed to see whether the loader act
upon these "advise", either during configuration or dynamically. .

-- 
Cong Gu