Yaroslav Kavenchuk wrote:
Oh boy!
Why there is no opportunity to specify from what library link function?
You probably mean in CFFI? UFFI has :module and CLISP has :library
And if I shall link some libraries with identical names of functions - what to do?
"Implementation-dependent" and underspecified On many UNIX systems, the more recently opened libraries probably shadow older ones. Now, do you know in which order the libraries where opened? The general answer is "no". E.g. did you read somewhere in clisp impnotes in what order it's reopening libraries when restarting from an image? Do you know what libraries got loaded in what order, when you're just a library programmer and don't know what the user is doing (and what s/he loaded)? No, you don't.
There are several reasons why I prefer programmers to state which library or module thex expect a function to come from. It helps do the right thing. (But the most important reason back in 1995 was that the Amiga had no introspection of shared libraries. You *had* to tell you want e.g. Close from *that* specific library, and it was a reasonably way to avoid conflicts).
I do not know what library contains bad sprintf function.
Maybe you can figure it out using (foreign-address #<foreign-function>) and see if you can relate that to the addresses of the .dll loaded into the current process?
Regards, Jorg Hohle
Hoehle, Joerg-Cyril wrote:
Why there is no opportunity to specify from what library link function?
You probably mean in CFFI? UFFI has :module and CLISP has :library
CFFI of course
<skip>
no perfection in the world :(
I shall try...
Thanks!
Yaroslav Kavenchuk kavenchuk@jenty.by writes:
I would like, eventually, to extend CFFI to allow for this case, as it would come up all the time in a program that wanted to load "plugin" style shared objects.
For example, one way to handle this would be for LOAD-FOREIGN-LIBRARY to return a cookie that can be used to refer to a specific shared library. Then, functions defined with DEFCFUN could take an extra :library keyword argument that would be used to specify which library to resolve the function in. (We'd need a way to extend FOREIGN-FUNCALL to do this too: probably a FOREIGN-FUNCALL-IN-LIBRARY operator or something.)
I'm not sure what the status of implementation support on something like this would be...
James
I have found it! This is ntdll.dll (in this library still more many other functions). F&%k!
It is caused from ole32.dll.
win32 *.dll hell...
Use CFFI with Windows without cpecification of library is problematic :(
Thanks!
On 2006-jan-06, at 10:48, Yaroslav Kavenchuk wrote:
Use CFFI with Windows without cpecification of library is problematic :(
Try (cffi:load-foreign-library "msvcrt.dll") before trying to call sprintf or something standard C function. That should work.
Luís Oliveira wrote:
[1]> (asdf:operate 'asdf:load-op 'cffi) ... NIL [2]> (cffi:load-foreign-library "msvcrt.dll") #<FOREIGN-POINTER #x78000000> [3]> (in-package :cffi) #<PACKAGE CFFI> CFFI[4]> (with-foreign-pointer-as-string (s 100) (setf (mem-ref s :char) 0) (foreign-funcall "sprintf" :pointer s :string "%.2f" :double (coerce pi 'double-float) :void)) "4{Ъ↓сЭI"
:(
Yaroslav Kavenchuk kavenchuk@jenty.by writes:
Hmm, that sounds awful.
What sort of interface should CFFI export for this? I've been reluctant to add this because several Lisps don't support it at all, but perhaps silently ignoring :LIBRARY options on those implementations and proceeding with the global lookup is okay for now...
If we added an option syntax to DEFCFUN (I know everyone hates this syntax, but it's backwards compatible), we could have something like:
(defcfun "sprintf" :int :library "msvcrt.dll" (fmt :string) ...)
If we want to break everyone and change the syntax of DEFCFUN, we can make it look like DEFCLASS:
(defcfun "sprintf" :int ((fmt :string) ...) (:library "msvcrt.dll"))
Or, for a completely different approach, what about:
(with-default-library ("msvcrt.dll") (defcfun "sprintf" :int (fmt :string) ...))
Thoughts?
James
On Fri, 2006-01-06 at 03:41 -0800, James Bielman wrote:
I forget whether define-foreign-library will have a Lisp name, but if so, it would be nice for :library to accept this as well. Of course, CLISP's :library option is unevalled ....
Am 06.01.2006 um 12:41 schrieb James Bielman:
This sounds OK for me, really.
Looks OK.
Looks better.
Handy...
Let's do the Better and Handy approaches - just my vote. And yes, I think it is OK to "break everyone" because we do version CFFI and also because there's not that many CFFI based packages out there yet (ouch - that might get some serious reponses ;-)
Thoughts?
Yeah, these were mine. Glad someone works on this now. I really had a hard time with these issues and would love to see a clean solution.
Thanks for your work and ideas.
Frank