...not on Windows, I'm afraid: my automation isn't up to that yet.
But all tests passed on Mac OS X. On linux, though, I got the following:
Unexpected test failures on these implementations: build/results/allegro8-test.text build/results/allegromodern8-test.text build/results/allegromodern-test.text build/results/allegro-test.text build/results/cmucl-test.text
For Allegro, I see test-program failing:
TEST ABORTED: In (GETENV-PATHNAME "ALLEGRO"), invalid pathname #P"alisp8/": Expected an absolute pathname Evaluation stack: Warning: while extracting symbols from /lib/i386-linux-gnu/librt.so.1: couldn't find .symtab section Warning: while extracting symbols from /lib/i386-linux-gnu/libm.so.6: couldn't find .symtab section Warning: while extracting symbols from /lib/i386-linux-gnu/libdl.so.2: couldn't find .symtab section Warning: while extracting symbols from /lib/i386-linux-gnu/libc.so.6: couldn't find .symtab section Warning: while extracting symbols from /lib/ld-linux.so.2: couldn't find .symtab section Warning: while extracting symbols from /lib/i386-linux-gnu/libnss_files.so.2: couldn't find .symtab section Warning: while extracting symbols from /lib/i386-linux-gnu/libnss_compat.so.2: couldn't find .symtab section Warning: while extracting symbols from /lib/i386-linux-gnu/libnsl.so.1: couldn't find .symtab section Warning: while extracting symbols from /lib/i386-linux-gnu/libnss_nis.so.2: couldn't find .symtab section
Above backtrace due to this condition: In (UIOP/FILESYSTEM:GETENV-PATHNAME "ALLEGRO"), invalid pathname #P"alisp/": Expected an absolute pathname
The .symtab errors imply we are trying to build a program assuming a 32-bit execution model, instead of a 64-bit one. I have had this problem on Allegro before. I see that warning on allegro8-test.text, allegromodern-test.text, allegromodern8-test.text, but not on allegro-test.text. That's my fault, because I replaced my old 32-bit license with a 64-bit one, and it looks like there's some way to find the old license.
This is a potential real issue, though: we have often found problems linking with C code on Allegro when we have only 32-bit Allegro on a 64-bit platform. It's getting less and less common to rig up one's 64-bit linux box with a full 32-bit build environment as well as the 64-bit one.
CMUCL has a different error:
stderr: This is make-hello-world, testing its stderr. 0: RUN-PROGRAM returned NIL NIL 0 - then use this executable image 0: (RUN-PROGRAM
("/home/rpg/common-lisp/asdf/build/fasls/cmu-20f___20f_unicode_-linux-x86/asdf/test/hello-world-example--all-systems.image" "-quiet" "-noinit" "-batch" "-eval" ...) :OUTPUT :LINES :ERROR-OUTPUT ...) 0: RUN-PROGRAM returned ("hello, world") NIL 0 - now, use this executable image with arguments 0: TEST ABORTED: Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER: #<Function EQ {100138F1}> is not of type SEQUENCE 0: (DEBUG:BACKTRACE 69 #<Synonym Stream to SYSTEM:*STDOUT*>) 1: (UIOP/IMAGE:RAW-PRINT-BACKTRACE :STREAM #<Synonym Stream to SYSTEM:*STDOUT*> :COUNT 69 :CONDITION #<unused-arg>) 2: ("WITH-UPGRADABILITY NIL") 3: ("WITH-UPGRADABILITY NIL") 4: (LISP::%WITH-STANDARD-IO-SYNTAX #<Closure Over Function "WITH-UPGRADABILITY NIL" {585234D1}>) 5: (UIOP/IMAGE:PRINT-CONDITION-BACKTRACE #<TYPE-ERROR {5850089D}> :STREAM #<Synonym Stream to SYSTEM:*STDOUT*> :COUNT 69) 6: (NIL #<TYPE-ERROR {5850089D}>) 7: (NIL #<TYPE-ERROR {5850089D}>) 8: (SIGNAL #<TYPE-ERROR {5850089D}>) 9: (ERROR TYPE-ERROR :FUNCTION-NAME REVERSE :DATUM #<Function EQ {100138F1}> :EXPECTED-TYPE SEQUENCE) 10: (KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER REVERSE #<System-Area-Pointer: #x3FFFB864> #<Alien (* SYSTEM:SYSTEM-AREA-POINTER) at #x3FFFB40C> (144 16)) 11: (KERNEL::INTERNAL-ERROR #<System-Area-Pointer: #x3FFFB40C> #<unused-arg>) 12: ("call_into_lisp+#x74 [#x8059750] /usr/local/bin/cmucl") 13: ("funcall2+#x2C [#x805927C] /usr/local/bin/cmucl") 14: ("interrupt_internal_error+#x7A [#x805201A] /usr/local/bin/cmucl") 15: ("sigtrap_handler+#x183 [#x8059593] /usr/local/bin/cmucl") 16: (REVERSE 1 #<Function EQ {100138F1}>)[:EXTERNAL] 17: (DEBUG::PRINT-FRAME-CALL-1 #<Compiled-Frame UIOP/RUN-PROGRAM:RUN-PROGRAM>) 18: (DEBUG::PRINT-FRAME-CALL #<Compiled-Frame UIOP/RUN-PROGRAM:RUN-PROGRAM> :PRINT-LENGTH NIL :PRINT-LEVEL NIL :VERBOSITY 1 :NUMBER NIL) 19: ("DEFUN TRACE-START-BREAKPOINT-FUN" #<Compiled-Frame UIOP/RUN-PROGRAM:RUN-PROGRAM> #<unused-arg>) 20: (DEBUG-INTERNALS::INVOKE-BREAKPOINT-HOOKS (#<Breakpoint UIOP/RUN-PROGRAM:RUN-PROGRAM:FUNCTION-START> #<Breakpoint UIOP/RUN-PROGRAM:RUN-PROGRAM:FUNCTION-START>) #<Code Object "WITH-UPGRADABILITY NIL" {581163D7}> 617) 21: (DEBUG-INTERNALS::HANDLE-BREAKPOINT-AUX (#<Breakpoint UIOP/RUN-PROGRAM:RUN-PROGRAM:FUNCTION-START> #<Breakpoint UIOP/RUN-PROGRAM:RUN-PROGRAM:FUNCTION-START>) #<Breakpoint-Data UIOP/RUN-PROGRAM:RUN-PROGRAM at 617> 617 #<Code Object "WITH-UPGRADABILITY NIL" {581163D7}> #<System-Area-Pointer: #x3FFFBF4C>) 22: ("call_into_lisp+#x74 [#x8059750] /usr/local/bin/cmucl") 23: Above backtrace due to this condition: Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER: #<Function EQ {100138F1}> is not of type SEQUENCE Script failed
I'm not seeing an obvious explanation for this failure. Looks like it would be some kind of place where EQ appears in the wrong position, but the backtrace is unhelpful, and I don't know how to work through all the intricacies of LISP-INVOCATION.
When I try to make this run at the command line, I fail as follows:
cmucl -core
/home/rpg/common-lisp/asdf/build/fasls/cmu-20f___20f_unicode_-linux-x86/asdf/test/hello-world-example--all-systems.image
Invalid magic number: 0x464c457f should have been 0x434f5245.
...but that seems like a different error, since the above transcript seems to suggest that the lisp invocation worked, but then we tried to test some result and encountered an error.