1 ;;;; patches to work around 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.
15 ;;; as explained on #lisp ca. October 2003:
16 ;;; <Krystof> chandler: nope, I'm blaming another clisp bug
17 ;;; <Krystof> [8]> least-positive-short-float
18 ;;; <Krystof> 2.93874s-39
19 ;;; <Krystof> [9]> (coerce * 'single-float)
24 ;;; <mwh> tried that on clisp from fink:
25 ;;; <mwh> [1]> least-positive-short-float
27 ;;; <mwh> [2]> (coerce * 'single-float)
28 ;;; <mwh> *** - floating point underflow
30 ;;; <mwh> shall i not try to build sbcl with that?
31 ;;; <Krystof> if you turn off underflow traps, then you get 0.0
32 ;;; <mwh> well, that makes sense, i guess
34 ;;; <Krystof> (ext:without-package-lock ("SYSTEM")
35 ;;; <Krystof> (setf system::*inhibit-floating-point-underflow* t))
36 ;;; <Krystof> (in src/cold/ansify.lisp)
38 (ext:without-package-lock
("SYSTEM")
39 (setf system
::*inhibit-floating-point-underflow
* t
))
43 ;;; CMU CL, at least as of 18b, doesn't support PRINT-OBJECT. In
44 ;;; particular, it refuses to compile :PRINT-OBJECT options to
45 ;;; DEFSTRUCT, so we need to conditionalize such options on the
46 ;;; :NO-ANSI-PRINT-OBJECT feature in order to get the code to compile.
47 ;;; (It also fails to do anything useful with DEFMETHOD PRINT-OBJECT,
48 ;;; but that doesn't matter much, since it doesn't stop the
49 ;;; cross-compiler from working.)
52 (warn "CMU CL doesn't support the :PRINT-OBJECT option to DEFSTRUCT.~%")
53 (pushnew :no-ansi-print-object
*features
*))
55 ;;; KLUDGE: In CMU CL, at least as of 18b, READ-SEQUENCE is somewhat
56 ;;; dain-bramaged. Running
57 ;;; (defvar *buffer* (make-array (expt 10 6) :element-type 'character))
58 ;;; (with-open-file (s "/tmp/long-file.tmp")
59 ;;; (/show (read-sequence *buffer* s :start 0 :end 3000))
60 ;;; (/show (read-sequence *buffer* s :start 0 :end 15000))
61 ;;; (/show (read-sequence *buffer* s :start 0 :end 15000)))
62 ;;; on a large test file gives
63 ;;; /(READ-SEQUENCE *BUFFER* S :START 0 :END 3000)=3000
64 ;;; /(READ-SEQUENCE *BUFFER* S :START 0 :END 15000)=1096
65 ;;; /(READ-SEQUENCE *BUFFER* S :START 0 :END 15000)=0
68 (warn "CMU CL has a broken implementation of READ-SEQUENCE.")
69 (pushnew :no-ansi-read-sequence
*features
*))
71 ;;; This is apparently quite old, according to
72 ;;; <http://tunes.org/~nef/logs/lisp/03.10.22>:
73 ;;; <dan`b> (error "CMUCL on Alpha can't read floats in the format \"1.0l0\".
74 ;;; <dan`b> the warning relates to a random vinary produced from cvs of
75 ;;; around feb 2000, the corresponding sources to which I never found
76 ;;; (But it seems harmless to leave it here forever just in case.)
78 (unless (ignore-errors (read-from-string "1.0l0"))
79 (error "CMUCL on Alpha can't read floats in the format \"1.0l0\". Patch your core file~%~%"))
82 (ext:set-floating-point-modes
:traps
'(:overflow
:invalid
:divide-by-zero
))
86 ;;; This issue in OpenMCL led to some SBCL bug reports ca. late 2003.
88 (unless (ignore-errors (funcall (constantly t
) 1 2 3))
89 (error "please find a binary that understands CONSTANTLY to build from"))
91 ;;;; Self-hosted issues
95 (setq *compile-print
* nil
)
96 (load "src/cold/muffler.lisp")
97 ;; Let's just say we never care to see these.
98 (declaim (sb-ext:muffle-conditions
99 (satisfies unable-to-optimize-note-p
)
100 (satisfies optional
+key-style-warning-p
)
101 sb-ext
:code-deletion-note
)))
103 ;;;; general non-ANSI-ness
105 (in-package :sb-cold
)
107 (defmacro munging-cl-package
(&body body
)
108 #-clisp
`(progn ,@body
)
109 #+clisp
`(ext:without-package-lock
("CL")
112 ;;; Do the exports of COMMON-LISP conform to the standard? If not, try
113 ;;; to make them conform. (Of course, ANSI says that bashing symbols
114 ;;; in the COMMON-LISP package like this is undefined, but then if the
115 ;;; host Common Lisp were ANSI, we wouldn't be doing this, now would
116 ;;; we? "One dirty unportable hack deserves another.":-)
117 (let ((standard-ht (make-hash-table :test
'equal
))
118 (host-ht (make-hash-table :test
'equal
))
119 (cl (find-package "COMMON-LISP")))
120 (do-external-symbols (i cl
)
121 (setf (gethash (symbol-name i
) host-ht
) t
))
122 (dolist (i (read-from-file "common-lisp-exports.lisp-expr"))
123 (setf (gethash i standard-ht
) t
))
124 (maphash (lambda (key value
)
125 (declare (ignore value
))
126 (unless (gethash key standard-ht
)
127 (warn "removing non-ANSI export from package CL: ~S" key
)
129 (unexport (intern key cl
) cl
))))
131 (maphash (lambda (key value
)
132 (declare (ignore value
))
133 (unless (gethash key host-ht
)
134 (warn "adding required-by-ANSI export to package CL: ~S" key
)
136 (export (intern key cl
) cl
)))
138 ;; FIXME: My righteous indignation below was misplaced. ANSI sez
139 ;; (in 11.1.2.1, "The COMMON-LISP Package") that it's OK for
140 ;; COMMON-LISP things to have their home packages elsewhere.
141 ;; For now, the hack below works, but it's not good to rely
142 ;; on this nonstandardness. Ergo, I should fix things so that even
143 ;; when the cross-compilation host COMMON-LISP package has
144 ;; symbols with home packages elsewhere, genesis dumps out
145 ;; the correct stuff. (For each symbol dumped, check whether it's
146 ;; exported from COMMON-LISP, and if so, dump it as though its
147 ;; home package is COMMON-LISP regardless of whether it actually
150 ;; X CMU CL, at least the Debian versions ca. 2.4.9 that I'm
151 ;; X using as I write this, plays a sneaky trick on us by
152 ;; X putting DEBUG and FLOATING-POINT-INEXACT in the
153 ;; X EXTENSIONS package, then IMPORTing them into
154 ;; X COMMON-LISP, then reEXPORTing them from COMMON-LISP.
155 ;; X This leaves their home packages bogusly set to
156 ;; X EXTENSIONS, which confuses genesis into thinking that
157 ;; X the CMU CL EXTENSIONS package has to be dumped into the
158 ;; X target SBCL. (perhaps a last-ditch survival strategy
159 ;; X for the CMU CL "nooo! don't bootstrap from scratch!"
160 ;; X meme?) As far as I can see, there's no even slightly
161 ;; X portable way to undo the damage, so we'll play the "one
162 ;; X dirty unportable hack deserves another" game, only even
163 ;; X dirtierly and more unportably than before..
165 (let ((symbol (intern key cl
)))
166 (unless (eq (symbol-package symbol
) cl
)
167 (warn "using low-level hack to move ~S from ~S to ~S"
169 (symbol-package symbol
)
171 (kernel:%set-symbol-package symbol cl
))))