Re: using GSL with cblas via FFI

[Thien-Thi Nguyen]

() cong gu <address@hidden>
() 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?