only thing is, im not sure yet what i would set LD_LIBRARY_PATH to, as the
following are all the library files gsl installs:
gsl /usr/lib/libgsl.so
gsl /usr/lib/libgsl.so.23
gsl /usr/lib/libgsl.so.23.1.0
gsl /usr/lib/libgslcblas.so
gsl /usr/lib/libgslcblas.so.0
gsl /usr/lib/libgslcblas.so.0.0.0
ldd output is
ldd /usr/lib/libgsl.so
linux-vdso.so.1 (0x00007ffeb5ded000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007f804bc32000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f804ba6e000)
/usr/lib64/ld-linux-x86-64.so.2 (0x00007f804c282000)
something that works in my c test program is preloading libgslcblas with
RTLD_GLOBAL.
void* a = dlopen("/usr/lib/libgslcblas.so", RTLD_NOW | RTLD_GLOBAL);
void* b = dlopen("/usr/lib/libgsl.so", RTLD_NOW);
but guile uses libtool of course. as far as i understand it, libgslcblas is a
cblas implementation that can be replaced with other ones, and that is why it
is separate.
the RTLD_GLOBAL feature has been referenced in a mailing list post from 2012 "Re:
using GSL with cblas via FFI"
https://lists.gnu.org/archive/html/guile-user/2012-06/msg00008.html
https://lists.gnu.org/archive/html/guile-user/2011-03/msg00071.html
what might eventually work is to compile gsl myself with the dependency
excluded or statically linked. or using a c extension instead of the ffi.
but it is interesting also how the example from the manual does not work and gives the
same error message. (define libm (dynamic-link "libm"))
https://www.gnu.org/software/guile/manual/html_node/Dynamic-FFI.html
it would be interesting to know if it works for others.
