[usocket-devel] CLISP problems

Hello, CLISP 2.41 gives me the following: ;; Loading file /home/sky/.sbcl/site/usocket-0.3.5/backend/clisp.fas ... ** - Continuable Error FFI::FIND-FOREIGN-FUNCTION: foreign function "gethostname" does not exist Changing backend/clisp.lisp thus (in pseudo-diff format): (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") + #+unix (:library "libc.so.6") (:language #-win32 :stdc #+win32 :stdc-stdcall) (:return-type ffi:int)) helps on my system. Is there some rationale behind the non-working code? And is there a particular reason that usocket doesn't use CFFI? Thanks! :) Leslie

Hi Leslie, On Mon, Apr 21, 2008 at 9:56 AM, <leslie.polzer@gmx.net> wrote:
Hello,
CLISP 2.41 gives me the following:
;; Loading file /home/sky/.sbcl/site/usocket-0.3.5/backend/clisp.fas ... ** - Continuable Error FFI::FIND-FOREIGN-FUNCTION: foreign function "gethostname" does not exist
Hrm. That's too bad.
Changing backend/clisp.lisp thus (in pseudo-diff format):
(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") + #+unix (:library "libc.so.6") (:language #-win32 :stdc #+win32 :stdc-stdcall) (:return-type ffi:int))
helps on my system.
Is there some rationale behind the non-working code?
Yes: it works on my system and not having libc.so.6 means it will work on more Unix platforms which have a C library with gethostname() loaded by default.
And is there a particular reason that usocket doesn't use CFFI?
Yes: I've been unable to use implementation-provided streams with self-created sockets. This means using CFFI would require me to fall back to gray streams *and* I would need to emulate any implementation-provided byte->character recoding (external format conversion) support. I'd rather avoid that can of worms, even at the expense of 7 different backends.
Thanks! :)
Welcome! BTW: What *is* your platform (other than CLISP on a Unix variant) exactly? I've seen this report before, but never have had any problems with it myself. Do you also get the error if you start CLISP as 'clisp -Kfull'? Thanks for your report! Bye, Erik.

Yes: I've been unable to use implementation-provided streams with self-created sockets. This means using CFFI would require me to fall back to gray streams *and* I would need to emulate any implementation-provided byte->character recoding (external format conversion) support. I'd rather avoid that can of worms, even at the expense of 7 different backends.
Yeah, that sucks.
BTW: What *is* your platform (other than CLISP on a Unix variant) exactly? I've seen this report before, but never have had any problems with it myself.
This is % uname -a Linux wintermute 2.6.24-ARCH #1 SMP PREEMPT Sun Mar 30 11:40:06 CEST 2008 i686 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ AuthenticAMD GNU/Linux # (Distribution: Arch Linux) % ls /lib/libc[-.]* /lib/libc-2.7.so /lib/libc.so.6 % pacman -Q glibc glibc 2.7-9
Do you also get the error if you start CLISP as 'clisp -Kfull'?
Just checked, and the answer is yes. Intriguingly it also doesn't help to define a default foreign lib in clisprc. I have to change usocket's source directly as outlined... I can test more things if you wish or give you a shell account. Leslie
participants (3)
-
Erik Huelsmann
-
Leslie P. Polzer
-
leslie.polzer@gmx.net