[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: using GSL with cblas via FFI
From: |
Thien-Thi Nguyen |
Subject: |
Re: using GSL with cblas via FFI |
Date: |
Mon, 04 Jun 2012 06:15:47 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) |
() 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?