1 ;;;; patches to hide some implementation idiosyncrasies in our
2 ;;;; cross-compilation host
4 ;;;; This software is part of the SBCL system. See the README file for
7 ;;;; This software is derived from the CMU CL system, which was
8 ;;;; written at Carnegie Mellon University and released into the
9 ;;;; public domain. The software is in the public domain and is
10 ;;;; provided with absolutely no warranty. See the COPYING and CREDITS
11 ;;;; files for more information.
16 (in-package "COMMON-LISP")
18 ;; no longer needed in CLISP 1999-01-08, hurrah!
20 ;; ANSI specifies that package LISP defines the type BOOLEAN, and the CMU CL
21 ;; compiler uses it a lot. This should be trivial to patch in CLISP, except
22 ;; that CLISP defines FFI:BOOLEAN, which conflicts. Gads.. Here we try to fix
23 ;; it with some package hacking. (Please do not take this as an example of
24 ;; good package hacking, I just messed with it until it seemed to work well
25 ;; enough to bootstrap CMU CL, because I'm highly unmotivated to make elegant
26 ;; fixes for nonstandard behavior. -- WHN)
27 (shadow 'ffi:boolean "FFI")
28 (deftype cl::boolean () '(member t nil))
29 (export 'boolean "LISP")
32 ;; I gave up on using CLISP-1999-01-08 as a cross-compilation host because of
33 ;; problems that I don't have workarounds for:
34 (error "can't use CLISP -- no MAKE-LOAD-FORM")
35 (error "can't use CLISP -- no (FUNCTION (SETF SYMBOL-FUNCTION))")
38 ;;; CMU CL, at least as of 18b, doesn't support PRINT-OBJECT. In
39 ;;; particular, it refuses to compile :PRINT-OBJECT options to
40 ;;; DEFSTRUCT, so we need to conditionalize such options on the
41 ;;; :NO-ANSI-PRINT-OBJECT feature in order to get the code to compile.
42 ;;; (It also fails to do anything useful with DEFMETHOD PRINT-OBJECT,
43 ;;; but that doesn't matter much, since it doesn't stop the
44 ;;; cross-compiler from working.)
47 (warn "CMU CL doesn't support the :PRINT-OBJECT option to DEFSTRUCT.~%")
48 (pushnew :no-ansi-print-object *features*))
50 ;;; KLUDGE: In CMU CL, at least as of 18b, READ-SEQUENCE is somewhat
51 ;;; dain-bramaged. Running
52 ;;; (defvar *buffer* (make-array (expt 10 6) :element-type 'character))
53 ;;; (with-open-file (s "/tmp/long-file.tmp")
54 ;;; (/show (read-sequence *buffer* s :start 0 :end 3000))
55 ;;; (/show (read-sequence *buffer* s :start 0 :end 15000))
56 ;;; (/show (read-sequence *buffer* s :start 0 :end 15000)))
57 ;;; on a large test file gives
58 ;;; /(READ-SEQUENCE *BUFFER* S :START 0 :END 3000)=3000
59 ;;; /(READ-SEQUENCE *BUFFER* S :START 0 :END 15000)=1096
60 ;;; /(READ-SEQUENCE *BUFFER* S :START 0 :END 15000)=0
63 (warn "CMU CL has a broken implementation of READ-SEQUENCE.")
64 (pushnew :no-ansi-read-sequence *features*))
66 ;;; Do the exports of COMMON-LISP conform to the standard? If not, try
67 ;;; to make them conform. (Of course, ANSI says that bashing symbols
68 ;;; in the COMMON-LISP package like this is undefined, but then if the
69 ;;; host Common Lisp were ANSI, we wouldn't be doing this, now would
70 ;;; we? "One dirty unportable hack deserves another.":-)
71 (let ((standard-ht (make-hash-table :test 'equal))
72 (host-ht (make-hash-table :test 'equal))
73 (cl (find-package "COMMON-LISP")))
74 (do-external-symbols (i cl)
75 (setf (gethash (symbol-name i) host-ht) t))
76 (dolist (i (read-from-file "common-lisp-exports.lisp-expr"))
77 (setf (gethash i standard-ht) t))
78 (maphash (lambda (key value)
79 (declare (ignore value))
80 (unless (gethash key standard-ht)
81 (warn "removing non-ANSI export from package CL: ~S" key)
82 (unexport (intern key cl) cl)))
84 (maphash (lambda (key value)
85 (declare (ignore value))
86 (unless (gethash key host-ht)
87 (warn "adding required-by-ANSI export to package CL: ~S" key)
88 (export (intern key cl) cl))
89 ;; FIXME: My righteous indignation below was misplaced. ANSI sez
90 ;; (in 11.1.2.1, "The COMMON-LISP Package") that it's OK for
91 ;; COMMON-LISP things to have their home packages elsewhere.
92 ;; For now, the hack below works, but it's not good to rely
93 ;; on this nonstandardness. Ergo, I should fix things so that even
94 ;; when the cross-compilation host COMMON-LISP package has
95 ;; symbols with home packages elsewhere, genesis dumps out
96 ;; the correct stuff. (For each symbol dumped, check whether it's
97 ;; exported from COMMON-LISP, and if so, dump it as though its
98 ;; home package is COMMON-LISP regardless of whether it actually
101 ;; X CMU CL, at least the Debian versions ca. 2.4.9 that I'm
102 ;; X using as I write this, plays a sneaky trick on us by
103 ;; X putting DEBUG and FLOATING-POINT-INEXACT in the
104 ;; X EXTENSIONS package, then IMPORTing them into
105 ;; X COMMON-LISP, then reEXPORTing them from COMMON-LISP.
106 ;; X This leaves their home packages bogusly set to
107 ;; X EXTENSIONS, which confuses genesis into thinking that
108 ;; X the CMU CL EXTENSIONS package has to be dumped into the
109 ;; X target SBCL. (perhaps a last-ditch survival strategy
110 ;; X for the CMU CL "nooo! don't bootstrap from scratch!"
111 ;; X meme?) As far as I can see, there's no even slightly
112 ;; X portable way to undo the damage, so we'll play the "one
113 ;; X dirty unportable hack deserves another" game, only even
114 ;; X dirtierly and more unportably than before..
116 (let ((symbol (intern key cl)))
117 (unless (eq (symbol-package symbol) cl)
118 (warn "using low-level hack to move ~S from ~S to ~S"
120 (symbol-package symbol)
122 (kernel:%set-symbol-package symbol cl))))
126 (unless (ignore-errors (read-from-string "1.0l0"))
127 (error "CMUCL on Alpha can't read floats in the format \"1.0l0\". Patch your core file~%~%"))