Re: [polyml] LInkage and the Foreign structure

Hi Phil, On 14/10/2018 15:03, Phil Clayton wrote: Hi David, Thanks for the explanation and updates.  I have tested this, including externalDataSymbol, and all appears to work on my Linux and Darwin systems. Initially I found that I wasn't seeing the new Foreign exception for an

Re: [polyml] LInkage and the Foreign structure

loadLibrary "" doesn't work in Windows either. It returns an error 87 - invalid parameter. David On 14/10/2018 15:07, Phil Clayton wrote: In fact `loadLibrary ""` doesn't work on Darwin, `loadExecutable ()` is required. Phil On 11/09/18 21:50, Phil Clayton wrote: Looking at polyffi.cpp it

Re: [polyml] LInkage and the Foreign structure

In fact `loadLibrary ""` doesn't work on Darwin, `loadExecutable ()` is required. Phil On 11/09/18 21:50, Phil Clayton wrote: Looking at polyffi.cpp it actually looks like `loadLibrary ""` ends up calling   dlopen ("", ...) whereas `loadExecutable ()` ends up calling   dlopen (NULL, ...) A

Re: [polyml] LInkage and the Foreign structure

Hi David, Thanks for the explanation and updates. I have tested this, including externalDataSymbol, and all appears to work on my Linux and Darwin systems. Initially I found that I wasn't seeing the new Foreign exception for an uninitalized external symbol, although there was no seg fault.

Re: [polyml] LInkage and the Foreign structure

Hi Phil, Thanks for that. I've made some changes and if it all seems to work out I'll merge it into master. I've added some comments below. On 05/10/2018 09:23, Phil Clayton wrote: I'm glad to see that Poly/ML does not include symbols in the object file that are referenced from ML but not

Re: [polyml] LInkage and the Foreign structure

Hi David, Thanks - this is useful. At the very least it will point out missing dependencies at link time rather than run time. That is, provided it is used correctly - see the issue below. I'm glad to see that Poly/ML does not include symbols in the object file that are referenced from ML

Re: [polyml] LInkage and the Foreign structure

I've been thinking about adding direct external references as an alternative to dynamic loading of libraries. The mechanism is all there now because the Poly/ML run-time library is linked to the exported code through external references. I've added Foreign.externalFunctionSymbol : string ->

Re: [polyml] LInkage and the Foreign structure

Looking at polyffi.cpp it actually looks like `loadLibrary ""` ends up calling dlopen ("", ...) whereas `loadExecutable ()` ends up calling dlopen (NULL, ...) A couple of things I have read suggest that these often give the same result, if not always. So for non-Windows platforms

Re: [polyml] LInkage and the Foreign structure

Excellent - thank you. I now have a script called poly_gsl: #!/bin/bash LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libgsl.so:/usr/lib/x86_64-linux-gnu/libgslcblas.so poly $* -- Mark On 09/10/2018 04:37 PM, Phil Clayton wrote: > Hi Mark, > > > (* symbol lookup error:

Re: [polyml] LInkage and the Foreign structure

Slight correction: using an empty string for the library has the effect of passing NULL to dlopen which means the handle passed to dlsym is the current program. On 10/09/18 15:29, Phil Clayton wrote: Hi Mark, > (* symbol lookup error: /usr/lib/x86_64-linux-gnu/libgsl.so: undefined >

Re: [polyml] LInkage and the Foreign structure

Hi Mark, > (* symbol lookup error: /usr/lib/x86_64-linux-gnu/libgsl.so: undefined > symbol: cblas_dgemm *) To avoid looking for the symbol "cblas_dgemm" in libgsl (which doesn't define it), you could let the dynamic linker look for it by using an empty string for the library which has the

[polyml] LInkage and the Foreign structure

I am enjoying using polyml's Foreign structure. However, in using the GNU Scientific Library (GSL), I have run into a problem with linkage. The GSL library (libgsl.so) calls standard cBLAS matrix functions with unknown symbols to allow the user to link with different cBLAS implementations (NB: