[Ecls-list] usocket on ECL 9.4.0
Chun Tian (binghe)
binghe.lisp at gmail.com
Sat Apr 4 06:50:58 UTC 2009
Hi, ECL community
I met some problems when compiling usocket on ECL 9.4.0, below is the
error outputs:
=============
;;; gcc -g -O2 -fPIC -fno-common -D_THREAD_SAFE -Ddarwin -O "-I/
Users/binghe/include/" -w -c "/private/var/folders/3x/
3xMxiHaQGSqRfjv9Z200B++++TI/-Tmp-/ECLINIThcmJG7.c" -o "/private/var/
folders/3x/3xMxiHaQGSqRfjv9Z200B++++TI/-Tmp-/ECLINIThcmJG7.o"
;;; Note: Invoking external command:
Undefined symbols:
"_cl_alloc_atomic", referenced from:
_L2fdset_alloc in sbcl.o
_L7get_host_name in sbcl.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
(SYSTEM "gcc -o \"/Volumes/User/Lisp/usocket/trunk/backend/sbcl.fas\" -
L\"/Users/binghe/lib/\" \"/private/var/folders/3x/3xMxiHaQGSqRfjv9Z200B
++++TI/-Tmp-/ECLINIThcmJG7.o\" \"/Volumes/User/Lisp/usocket/trunk/
backend/sbcl.o\" -bundle -lecl -lpthread -lm ") returned non-
zero value 1
;;; gcc -o "/Volumes/User/Lisp/usocket/trunk/backend/sbcl.fas" -L"/
Users/binghe/lib/" "/private/var/folders/3x/3xMxiHaQGSqRfjv9Z200B+++
+TI/-Tmp-/ECLINIThcmJG7.o" "/Volumes/User/Lisp/usocket/trunk/backend/
sbcl.o" -bundle -lecl -lpthread -lm Broken at
SI:BYTECODES.Available restarts:
1. (CONTINUE) Continues anyway.
2. (TRY-RECOMPILING) Try recompiling sbcl
3. (RETRY) Retry performing #<ASDF:COMPILE-OP NIL 29930936> on
#<ASDF:CL-SOURCE-FILE "sbcl" "usocket" 29830384>.
4. (ACCEPT) Continue, treating #<ASDF:COMPILE-OP NIL 29930936> on
#<ASDF:CL-SOURCE-FILE "sbcl" "usocket" 29830384> as having been
successful.
=============
I think following code in usocket break above build:
(defun fdset-alloc ()
(ffi:c-inline () () :pointer-void
"cl_alloc_atomic(sizeof(fd_set))" :one-liner t))
It seems that the function "cl_alloc_atomic" doesn't exist anymore.
1. What should we (usocket) do instead in ECL 9.4.0?
2. Is there anyway to detect the exist of "cl_alloc_atomic" in any ECL
versions? (ECL doesn't put any version information in CL *features*,
and we (usocket) want to support more ECL versions as many as possible)
Regards,
Chun Tian (binghe)
More information about the ecl-devel
mailing list