...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.
