Hello,
I'd like to suggest a change to %load-foreign-library in lispworks.
:dlopen-flags in fli:register-module is default to :local-lazy, which means setting RTLD_LOCAL || RTLD_LAZY flag when calling dlopen. This will not allow me to open shared libraries in sequential that depends on previously loaded ones.
So I suggest to set :dlopen-flags to :global-lazy as default in % load-foreign-library in cffi-lispworks.lisp.
The code will look like:
(defun %load-foreign-library (name path) "Load the foreign library NAME." (fli:register-module (or name path) :connection-style :immediate :real-name path + :dlopen-flags :global-lazy))
P.S. Here's the Lispworks documentation:
http://www.lispworks.com/documentation/lw51/FLI/html/fli-120.htm#marker-1058...
Cheers, Jianshi
On Thu, 14 May 2009 17:22:08 +0900, HUANG, Jianshi said:
Hello,
I'd like to suggest a change to %load-foreign-library in lispworks.
:dlopen-flags in fli:register-module is default to :local-lazy, which means setting RTLD_LOCAL || RTLD_LAZY flag when calling dlopen. This will not allow me to open shared libraries in sequential that depends on previously loaded ones.
So I suggest to set :dlopen-flags to :global-lazy as default in % load-foreign-library in cffi-lispworks.lisp.
Which libraries are you loading?
A library should normally load its own dependencies (defined when it was built).
Hi Martin,
On Thu, 14 May 2009 11:46:45 +0100 Martin Simmons martin@lispworks.com wrote:
Which libraries are you loading?
A library should normally load its own dependencies (defined when it was built).
Usually that's the case, but I'm using Intel MKL, which asks you to choose a combination of different libraries.
-- Martin Simmons LispWorks Ltd http://www.lispworks.com/
On Fri, 15 May 2009 09:01:22 +0900, HUANG, Jianshi said:
Hi Martin,
On Thu, 14 May 2009 11:46:45 +0100 Martin Simmons martin@lispworks.com wrote:
Which libraries are you loading?
A library should normally load its own dependencies (defined when it was built).
Usually that's the case, but I'm using Intel MKL, which asks you to choose a combination of different libraries.
Ah, I see.
Another way around this problem is to make a dummy library (using ld) that references the others and load the dummy library first.
I don't like the idea of setting :dlopen-flags to :global-lazy because it breaks situations where the same symbol is defined in more than one library.
Martin Simmons martin@lispworks.com writes: [...]
Ah, I see.
Another way around this problem is to make a dummy library (using ld) that references the others and load the dummy library first.
I don't like the idea of setting :dlopen-flags to :global-lazy because it breaks situations where the same symbol is defined in more than one library.
That's all very well, but as other Lisps (SBCL, Allegro, etc.) with CFFI load-foreign-library use global binding, why should Lispworks be the exception?
On Mon, 18 May 2009 10:26:57 +0900, John Fremlin said:
Martin Simmons martin@lispworks.com writes: [...]
Ah, I see.
Another way around this problem is to make a dummy library (using ld) that references the others and load the dummy library first.
I don't like the idea of setting :dlopen-flags to :global-lazy because it breaks situations where the same symbol is defined in more than one library.
That's all very well, but as other Lisps (SBCL, Allegro, etc.) with CFFI load-foreign-library use global binding, why should Lispworks be the exception?
It is up to CFFI maintainers what they decide, but we have found local to be more useful than global.
I can't comment on other implmentations...
-
HUANG, Jianshi -
John Fremlin -
Martin Simmons