From: Mehul S. <meh...@gm...> - 2013-07-01 15:27:30
|
I am trying to get CLISP built from source on my laptop. It fails when doing "make check" as shown below in the BEGIN OUTPUT section. What can I do to isolate the problem that may be indicated ? At this point I am not sure if its a LISP issue, a system issue, or something else. It consistently fails at the same place. I had initially started with the Debian packages for CLISP as that is what I wanted to use for StumpWM. Due to the way the packing had changed with Debian/wheezy, something about the way modules were packaged, I was unable to get StumpWM to build/work with CLISP. I tried to build CLISP from source, but ran into the problem below. I ended up using SBCL. For the most recent build, which was done last night after doing 'hg pull -u', I deleted ~/.cache/common-lisp/clisp*, commented out everything in ~/.clisprc.lisp, did a make clean, re-ran configure with no options, and from src directory ran 'make'. ---- BEGIN SYSTEM INFORMATION ---- OS: Debian/testing (jessie) Architecture: x86_64 prompt% ./clisp --version GNU CLISP 2.49+ (2010-07-17) (built 3581670178) (memory 3581670273) Software: GNU C 4.7.3 gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wreturn-type -Wmissing-declarations -Wimplicit -Wno-sign-compare -Wno-format-nonliteral -O -falign-functions=4 -DENABLE_UNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES libgnu.a -lreadline -lncurses -ldl -lavcall -lcallback -lsigsegv SAFETY=0 TYPECODES WIDE_HARD GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY libsigsegv 2.9 libreadline 6.2 libffcall 1.11 Features: (READLINE REGEXP WILDCARD SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER LOGICAL-PATHNAMES SOCKETS GENERIC-STREAMS SCREEN FFI GETTEXT UNICODE BASE-CHAR=CHARACTER WORD-SIZE=64 PC386 UNIX) C Modules: (clisp i18n syscalls regexp readline) Installation directory: /usr/local/src/clisp/src/ User language: ENGLISH Machine: X86_64 (X86_64) msanghvi-lap [127.0.1.1] ------ END SYSTEM INFORMATION ---- ----- BEGIN OUTPUT: make check ----- EQL-OK: ERROR (PROGN (DEF-CALL-OUT C-SELF (:NAME "ffi_identity") (:ARGUMENTS (FIRST (C-ARRAY-PTR UINT8))) (:RETURN-TYPE (C-PTR-NULL CHARACTER)) (:LANGUAGE :STDC)) (C-SELF #(97 98 99 100 101 102 103 104 105))) EQL-OK: #\a (PROGN (DEF-CALL-OUT C-SELF (:NAME "ffi_identity") (:ARGUMENTS (FIRST (C-ARRAY-PTR UINT8))) (:RETURN-TYPE (C-PTR-NULL CHARACTER)) (:LANGUAGE :STDC)) (C-SELF #(230 151 165 230 156 172 232 170 158))) [SIMPLE-CHARSET-TYPE-ERROR]: FFI::FOREIGN-CALL-OUT: Invalid byte #xE6 in CHARSET:ASCII conversion EQL-OK: ERROR (PROGN (DEF-CALL-OUT C-SELF (:NAME "ffi_identity") (:ARGUMENTS (FIRST C-STRING)) (:RETURN-TYPE (C-ARRAY-PTR UINT8)) (:LANGUAGE :STDC)) (C-SELF "日本語")) EQUALP-OK: #(230 151 165 230 156 172 232 170 158) (PROGN (DEF-CALL-OUT C-SELF (:NAME "ffi_identity") (:ARGUMENTS (FIRST (C-PTR (C-ARRAY CHARACTER 9)))) (:RETURN-TYPE (C-PTR (C-ARRAY UINT8 9))) (:LANGUAGE :STDC)) (C-SELF "日本語")) EQUALP-OK: #(230 151 165 230 156 172 232 170 158) (PROGN (DEF-CALL-OUT C-SELF (:NAME "ffi_identity") (:ARGUMENTS (FIRST (C-PTR (C-ARRAY-MAX CHARACTER 20)))) (:RETURN-TYPE (C-ARRAY-PTR UINT8)) (:LANGUAGE :STDC)) (C-SELF "日本語")) EQUALP-OK: #(230 151 165 230 156 172 232 170 158) (PROGN (DEF-CALL-OUT C-SELF (:NAME "ffi_identity") (:ARGUMENTS (FIRST (C-PTR (C-ARRAY-MAX CHARACTER 7)))) (:RETURN-TYPE (C-ARRAY-PTR UINT8)) (:LANGUAGE :STDC)) (C-SELF "日本語")) EQUALP-OK: #(230 151 165 230 156 172) (PROGN (DEF-CALL-OUT C-SELF (:NAME "ffi_identity") (:ARGUMENTS (FIRST (C-ARRAY-PTR CHARACTER))) (:RETURN-TYPE (C-ARRAY-PTR UINT8)) (:LANGUAGE :STDC)) (C-SELF "日本語")) EQUALP-OK: #(230 151 165 230 156 172 232 170 158) (PROGN (DEF-CALL-OUT C-SELF (:NAME "ffi_identity") (:ARGUMENTS (FIRST CHARACTER)) (:RETURN-TYPE UINT8) (:LANGUAGE :STDC)) (C-SELF #\a)) EQL-OK: 97 (PROGN (DEF-CALL-OUT C-SELF (:NAME "ffi_identity") (:ARGUMENTS (FIRST CHARACTER)) (:RETURN-TYPE UINT8) (:LANGUAGE :STDC)) (C-SELF #\LATIN_SMALL_LETTER_O_WITH_STROKE)) [SIMPLE-CHARSET-TYPE-ERROR]: FFI::FOREIGN-CALL-OUT: Character #\u00F8 cannot be represented in the character set CHARSET:ASCII EQL-OK: ERROR (PROGN (DEF-CALL-OUT C-SELF (:NAME "ffi_identity") (:ARGUMENTS (FIRST (C-PTR (C-ARRAY CHARACTER (3 3))))) (:RETURN-TYPE (C-PTR (C-ARRAY UINT8 9))) (:LANGUAGE :STDC)) (C-SELF #2A("abc" "def" "ghi"))) EQUALP-OK: #(97 98 99 100 101 102 103 104 105) (PROGN (DEF-CALL-OUT C-SELF (:NAME "ffi_identity") (:ARGUMENTS (FIRST (C-PTR (C-ARRAY CHARACTER (3 3))))) (:RETURN-TYPE (C-PTR (C-ARRAY UINT8 9))) (:LANGUAGE :STDC)) (C-SELF #2A("日本語" "Tür" "kçe"))) [SIMPLE-CHARSET-TYPE-ERROR]: FFI::FOREIGN-CALL-OUT: Character #\u65E5 cannot be represented in the character set CHARSET:ASCII EQL-OK: ERROR (PROGN (DEF-CALL-OUT C-SELF (:NAME "ffi_identity") (:ARGUMENTS (FIRST (C-PTR (C-ARRAY CHARACTER (3 3))))) (:RETURN-TYPE (C-PTR (C-ARRAY UINT8 9))) (:LANGUAGE :STDC)) (C-SELF #2A("日" "本" "語"))) [SIMPLE-ERROR]: FFI::FOREIGN-CALL-OUT: #2A("日" "本" "語") cannot be converted to the foreign type #(C-ARRAY CHARACTER 3 3) EQL-OK: ERROR (PROGN (DEF-CALL-OUT C-SELF (:NAME "ffi_identity") (:ARGUMENTS (FIRST (C-PTR CHARACTER))) (:RETURN-TYPE (C-PTR (C-ARRAY UINT8 1))) (:LANGUAGE :STDC)) (C-SELF #\a)) EQUALP-OK: #(97) (PROGN (DEF-CALL-OUT C-SELF (:NAME "ffi_identity") (:ARGUMENTS (FIRST (C-PTR CHARACTER))) (:RETURN-TYPE (C-PTR (C-ARRAY UINT8 1))) (:LANGUAGE :STDC)) (C-SELF #\LATIN_SMALL_LETTER_O_WITH_STROKE)) [SIMPLE-CHARSET-TYPE-ERROR]: FFI::FOREIGN-CALL-OUT: Character #\u00F8 cannot be represented in the character set CHARSET:ASCII EQL-OK: ERROR (PROGN (DEF-CALL-OUT C-SELF (:NAME "ffi_identity") (:ARGUMENTS (FIRST (C-PTR-NULL CHARACTER))) (:RETURN-TYPE (C-PTR (C-ARRAY UINT8 1))) (:LANGUAGE :STDC)) (C-SELF #\a)) EQUALP-OK: #(97) (PROGN (DEF-CALL-OUT C-SELF (:NAME "ffi_identity") (:ARGUMENTS (FIRST (C-PTR-NULL CHARACTER))) (:RETURN-TYPE (C-PTR (C-ARRAY UINT8 1))) (:LANGUAGE :STDC)) (C-SELF #\LATIN_SMALL_LETTER_O_WITH_STROKE)) [SIMPLE-CHARSET-TYPE-ERROR]: FFI::FOREIGN-CALL-OUT: Character #\u00F8 cannot be represented in the character set CHARSET:ASCII EQL-OK: ERROR (PROGN (DEF-CALL-OUT C-SELF (:NAME "ffi_identity") (:ARGUMENTS (FIRST C-STRING) (OBJ (C-PTR (C-ARRAY SINT16 4)) :IN-OUT)) (:RETURN-TYPE NIL) (:LANGUAGE :STDC)) (C-SELF "abc" #(-32768 -255 0 -256))) EQUALP-OK: #(-32768 -255 0 -256) (PROGN (DEF-CALL-OUT C-SELF (:NAME "ffi_identity") (:ARGUMENTS (FIRST C-STRING) (OBJ (C-PTR (C-ARRAY UINT32 4)) :IN-OUT)) (:RETURN-TYPE NIL) (:LANGUAGE :STDC)) (C-SELF NIL #(4294967295 16777215 0 127))) EQUALP-OK: #(4294967295 16777215 0 127) (PROGN (DEF-CALL-OUT C-SELF (:NAME "ffi_identity") (:ARGUMENTS (OBJ (C-PTR (C-ARRAY-MAX SINT16 17)) :OUT)) (:RETURN-TYPE NIL) (:LANGUAGE :STDC)) (C-SELF)) EQUALP-OK: #() (WITH-FOREIGN-OBJECT (FV 'LONG -12345678) (TYPEP FV 'FOREIGN-VARIABLE)) EQL-OK: T (PROGN (DEFPARAMETER *X* 0) (DEFUN CALLBACK (X) (SETF *X* (THE (UNSIGNED-BYTE 16) X)) (THE (UNSIGNED-BYTE 16) (1+ (* 2 X)))) *X*) EQL-OK: 0 (DEF-C-TYPE UINT->UINT (C-FUNCTION (:ARGUMENTS (X UINT)) (:RETURN-TYPE UINT) (:LANGUAGE :STDC))) EQL-OK: UINT->UINT (DEFPARAMETER *CALLBACKF* (WITH-C-VAR (X 'UINT->UINT #'CALLBACK) X)) EQL-OK: *CALLBACKF* (LIST (FUNCALL *CALLBACKF* 32767) *X*) *** - handle_fault error2 ! address = 0x0 not in [0x33439c000,0x334685420) ! SIGSEGV cannot be cured. Fault address = 0x0. GC count: 280 Space collected by GC: 325905984 Run time: 14 836927 Real time: 15 190216 GC time: 1 20068 Permanently allocated: 158648 bytes. Currently in use: 7543520 bytes. Free space: 190060 bytes. make[1]: *** [tests] Segmentation fault make[1]: Leaving directory `/usr/local/src/clisp/src/tests' make: *** [check-tests] Error 2 --------- END OUTPUT: make check ------ -- Mehul N. Sanghvi email: meh...@gm... |
From: Pascal J. B. <pj...@in...> - 2013-07-01 20:27:16
|
Mehul Sanghvi <meh...@gm...> writes: > I am trying to get CLISP built from source on my laptop. It fails when > doing "make check" as > shown below in the BEGIN OUTPUT section. What can I do to isolate the > problem that may > be indicated ? At this point I am not sure if its a LISP issue, a system > issue, or something else. > > It consistently fails at the same place. I had initially started with the > Debian packages for CLISP as that is what I wanted to use for StumpWM. Due > to the way the packing had changed with Debian/wheezy, something about the > way modules were packaged, I was unable to get StumpWM to build/work with > CLISP. I tried to build CLISP from source, but ran into the problem > below. I ended up using SBCL. It breaks testing the FFI. It's probable the problem is in the libffcall library. You're using 1.11; perhaps you could try the previous version 1.10? > libsigsegv 2.9 > libreadline 6.2 > libffcall 1.11 > > > (DEFPARAMETER *CALLBACKF* (WITH-C-VAR (X 'UINT->UINT #'CALLBACK) X)) > > EQL-OK: *CALLBACKF* > > (LIST (FUNCALL *CALLBACKF* 32767) *X*) Unfortunately, libffcall is in need of a maintainer. -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}. You know you've been lisping too long when you see a recent picture of George Lucas and think "Wait, I thought John McCarthy was dead!" -- Dalek_Baldwin |
From: Sam S. <sd...@gn...> - 2013-07-03 16:35:48
|
> * Pascal J. Bourguignon <cwo@vasbezngvzntb.pbz> [2013-07-01 22:26:57 +0200]: > > It breaks testing the FFI. It's probable the problem is in the > libffcall library. You're using 1.11; perhaps you could try the > previous version 1.10? it's exactly the other way around. you need to use the CVS head of libffcall, not the released version. >> libsigsegv 2.9 >> libreadline 6.2 >> libffcall 1.11 >> >> > (DEFPARAMETER *CALLBACKF* (WITH-C-VAR (X 'UINT->UINT #'CALLBACK) X)) >> > EQL-OK: *CALLBACKF* >> > (LIST (FUNCALL *CALLBACKF* 32767) *X*) > > Unfortunately, libffcall is in need of a maintainer. _YES_! -- Sam Steingold (http://sds.podval.org/) on Ubuntu 13.04 (raring) X 11.0.11303000 http://www.childpsy.net/ http://americancensorship.org http://memri.org http://pmw.org.il http://mideasttruth.com http://dhimmi.com A philosophical argument is won by the first to pull the trigger. |
From: Mehul S. <meh...@gm...> - 2013-07-01 21:09:11
|
On Mon, Jul 1, 2013 at 4:26 PM, Pascal J. Bourguignon <pj...@in... > wrote: > Mehul Sanghvi <meh...@gm...> writes: > > > I am trying to get CLISP built from source on my laptop. It fails when > > doing "make check" as > > shown below in the BEGIN OUTPUT section. What can I do to isolate the > > problem that may > > be indicated ? At this point I am not sure if its a LISP issue, a > system > > issue, or something else. > > > > It consistently fails at the same place. I had initially started with > the > > Debian packages for CLISP as that is what I wanted to use for StumpWM. > Due > > to the way the packing had changed with Debian/wheezy, something about > the > > way modules were packaged, I was unable to get StumpWM to build/work > with > > CLISP. I tried to build CLISP from source, but ran into the problem > > below. I ended up using SBCL. > > It breaks testing the FFI. It's probable the problem is in the > libffcall library. You're using 1.11; perhaps you could try the > previous version 1.10? > > I will try to get libffcall downgraded from 1.11 and see what happens. Thanks for the pointer. -- Mehul N. Sanghvi email: meh...@gm... |
From: Mehul S. <meh...@gm...> - 2013-07-02 05:22:01
|
On Mon, Jul 1, 2013 at 5:09 PM, Mehul Sanghvi <meh...@gm...>wrote: > On Mon, Jul 1, 2013 at 4:26 PM, Pascal J. Bourguignon < > pj...@in...> wrote: > >> Mehul Sanghvi <meh...@gm...> writes: >> >> > I am trying to get CLISP built from source on my laptop. It fails when >> > doing "make check" as >> > shown below in the BEGIN OUTPUT section. What can I do to isolate the >> > problem that may >> > be indicated ? At this point I am not sure if its a LISP issue, a >> system >> > issue, or something else. >> > >> > It consistently fails at the same place. I had initially started with >> the >> > Debian packages for CLISP as that is what I wanted to use for StumpWM. >> Due >> > to the way the packing had changed with Debian/wheezy, something about >> the >> > way modules were packaged, I was unable to get StumpWM to build/work >> with >> > CLISP. I tried to build CLISP from source, but ran into the problem >> > below. I ended up using SBCL. >> >> It breaks testing the FFI. It's probable the problem is in the >> libffcall library. You're using 1.11; perhaps you could try the >> previous version 1.10? >> >> > I will try to get libffcall downgraded from 1.11 and see what happens. > Thanks for > the pointer. > I looked into this. I have version 1.10+cvs20100619-2 of libffcall installed on my system. Where is version 1.11 coming from than ? I did a configure --with-libffcall-prefix=/usr but that still picks up version 1.11 -- Mehul N. Sanghvi email: meh...@gm... |
From: Mehul S. <meh...@gm...> - 2013-07-02 16:14:30
|
On Tue, Jul 2, 2013 at 1:21 AM, Mehul Sanghvi <meh...@gm...>wrote: > On Mon, Jul 1, 2013 at 5:09 PM, Mehul Sanghvi <meh...@gm...>wrote: > >> On Mon, Jul 1, 2013 at 4:26 PM, Pascal J. Bourguignon < >> pj...@in...> wrote: >> >>> Mehul Sanghvi <meh...@gm...> writes: >>> >>> > I am trying to get CLISP built from source on my laptop. It fails >>> when >>> > doing "make check" as >>> > shown below in the BEGIN OUTPUT section. What can I do to isolate the >>> > problem that may >>> > be indicated ? At this point I am not sure if its a LISP issue, a >>> system >>> > issue, or something else. >>> > >>> > It consistently fails at the same place. I had initially started with >>> the >>> > Debian packages for CLISP as that is what I wanted to use for StumpWM. >>> Due >>> > to the way the packing had changed with Debian/wheezy, something >>> about the >>> > way modules were packaged, I was unable to get StumpWM to build/work >>> with >>> > CLISP. I tried to build CLISP from source, but ran into the problem >>> > below. I ended up using SBCL. >>> >>> It breaks testing the FFI. It's probable the problem is in the >>> libffcall library. You're using 1.11; perhaps you could try the >>> previous version 1.10? >>> >>> >> I will try to get libffcall downgraded from 1.11 and see what happens. >> Thanks for >> the pointer. >> > > I looked into this. I have version 1.10+cvs20100619-2 of libffcall > installed on my system. > Where is version 1.11 coming from than ? > > I did a configure --with-libffcall-prefix=/usr but that still picks up > version 1.11 > Does CLISP come with its own version of FFCALL ? cheers, mehul -- Mehul N. Sanghvi email: meh...@gm... |
From: Pascal J. B. <pj...@in...> - 2013-07-02 19:51:00
|
Mehul Sanghvi <meh...@gm...> writes: > I looked into this. I have version 1.10+cvs20100619-2 of libffcall > installed on my system. > Where is version 1.11 coming from than ? If it's a version from cvs, it's possible that the version number has been bumbed in the repository? > I did a configure --with-libffcall-prefix=/usr but that still picks up > version 1.11 In those cases, I often have had success by downloading and compiling all the dependencies myself. Sometimes, distributions will patch packages, with adverse effects. -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}. You know you've been lisping too long when you see a recent picture of George Lucas and think "Wait, I thought John McCarthy was dead!" -- Dalek_Baldwin |
From: Mehul S. <meh...@gm...> - 2013-07-03 05:07:12
|
On Tue, Jul 2, 2013 at 3:50 PM, Pascal J. Bourguignon <pj...@in... > wrote: > Mehul Sanghvi <meh...@gm...> writes: > > > I looked into this. I have version 1.10+cvs20100619-2 of libffcall > > installed on my system. > > Where is version 1.11 coming from than ? > > If it's a version from cvs, it's possible that the version number has > been bumbed in the repository? > > > I did a configure --with-libffcall-prefix=/usr but that still picks up > > version 1.11 > > In those cases, I often have had success by downloading and compiling all > the > dependencies myself. Sometimes, distributions will patch packages, with > adverse effects. > > So I got it to work. It compiled and passed 'make check'. As long as I use a static version of libffcall. If I use the dynamic version of libffcall than I get the error I've reported previously. Is there a way to prevent configure from using the libffcall shared library, and only using the static one ? -- Mehul N. Sanghvi email: meh...@gm... |