When compiling usocket 0.3.7 on CLISP 2.46, I get this error:
;; Loading file /Users/xach/src/zs3-test/source/usocket-0.3.7/backend/clisp.fas ... ** - Continuable Error FFI::FIND-FOREIGN-FUNCTION: foreign function "gethostname" does not exist
Any ideas?
Zach
When compiling usocket 0.3.7 on CLISP 2.46, I get this error:
;; Loading file /Users/xach/src/zs3-test/source/usocket-0.3.7/backend/clisp.fas ... ** - Continuable Error FFI::FIND-FOREIGN-FUNCTION: foreign function "gethostname" does not exist
Any ideas?
Does it work if you put this:
(ffi:default-foreign-language :stdc) (ffi:default-foreign-library "libc.so.6") ;; or whatever your libc is
into your ~/.clisprc ?
Leslie
Does it work if you put this:
(ffi:default-foreign-language :stdc) (ffi:default-foreign-library "libc.so.6") ;; or whatever your libc is
into your ~/.clisprc ?
If this doesn't help, try adding
#+unix (:library "libc.so.6") ;; or darwin if you need it
in backend/clisp.lisp, right below:
(FFI:DEF-CALL-OUT get-host-name-internal (:name "gethostname") (:arguments (name (FFI:C-PTR (FFI:C-ARRAY-MAX ffi:character 256)) :OUT :ALLOCA) (len ffi:int)) #+win32 (:library "WS2_32")
On Sun, Sep 28, 2008 at 12:37:37AM +0200, Leslie P. Polzer wrote:
Does it work if you put this:
(ffi:default-foreign-language :stdc) (ffi:default-foreign-library "libc.so.6") ;; or whatever your libc is
into your ~/.clisprc ?
If this doesn't help, try adding
#+unix (:library "libc.so.6") ;; or darwin if you need it
in backend/clisp.lisp, right below:
(FFI:DEF-CALL-OUT get-host-name-internal (:name "gethostname") (:arguments (name (FFI:C-PTR (FFI:C-ARRAY-MAX ffi:character 256)) :OUT :ALLOCA) (len ffi:int)) #+win32 (:library "WS2_32")
I used #+macos (:library "libc.dylib") and it did the trick, thanks. I think a similar trick may be needed on non-Mac Unixes.
Zach
On Sun, Sep 28, 2008 at 1:54 AM, Zach Beane xach@xach.com wrote:
On Sun, Sep 28, 2008 at 12:37:37AM +0200, Leslie P. Polzer wrote:
Does it work if you put this:
(ffi:default-foreign-language :stdc) (ffi:default-foreign-library "libc.so.6") ;; or whatever your libc is
into your ~/.clisprc ?
If this doesn't help, try adding
#+unix (:library "libc.so.6") ;; or darwin if you need it
in backend/clisp.lisp, right below:
(FFI:DEF-CALL-OUT get-host-name-internal (:name "gethostname") (:arguments (name (FFI:C-PTR (FFI:C-ARRAY-MAX ffi:character 256)) :OUT :ALLOCA) (len ffi:int)) #+win32 (:library "WS2_32")
I used #+macos (:library "libc.dylib") and it did the trick, thanks. I think a similar trick may be needed on non-Mac Unixes.
The reason it's not there yet is that I'm unaware of a good way to detect which libc version is installed on a system. Or would it always be libc.so.6?
Bye,
Erik.
The reason it's not there yet is that I'm unaware of a good way to detect which libc version is installed on a system. Or would it always be libc.so.6?
I suppose libc5 is outdated enough to forget about it and a libc7 is still far away. :)
So the libc6 statement would work for 99% of UNIX users whereas the current situation works for 0% of CLISP users.
Leslie
On Tue, Sep 30, 2008 at 10:22 AM, Leslie P. Polzer sky@viridian-project.de wrote:
The reason it's not there yet is that I'm unaware of a good way to detect which libc version is installed on a system. Or would it always be libc.so.6?
I suppose libc5 is outdated enough to forget about it and a libc7 is still far away. :)
So the libc6 statement would work for 99% of UNIX users
Unix or Linux? What statement would we need on Solaris/ *BSD?
whereas the current situation works for 0% of CLISP users.
Well, if it really didn't work, I wouldn't have included it in the distribution. It's definitely working for me: Debian/Etch on x86. Are any of you also using Debian yet experiencing problems?
If so, maybe we need to figure out the difference between our installations?
Bye,
Erik.
On Tue, Sep 30, 2008 at 07:49:54PM +0200, Erik Huelsmann wrote:
On Tue, Sep 30, 2008 at 10:22 AM, Leslie P. Polzer sky@viridian-project.de wrote:
The reason it's not there yet is that I'm unaware of a good way to detect which libc version is installed on a system. Or would it always be libc.so.6?
I suppose libc5 is outdated enough to forget about it and a libc7 is still far away. :)
So the libc6 statement would work for 99% of UNIX users
Unix or Linux? What statement would we need on Solaris/ *BSD?
whereas the current situation works for 0% of CLISP users.
Well, if it really didn't work, I wouldn't have included it in the distribution. It's definitely working for me: Debian/Etch on x86. Are any of you also using Debian yet experiencing problems?
If so, maybe we need to figure out the difference between our installations?
The current release doesn't compile on CLISP for me on Mac OS X 10.5 or Ubuntu Linux 8.04.
Zach
-
Erik Huelsmann -
Leslie P. Polzer -
Zach Beane