Linux)
printf ' :linux' >> $ltf
sbcl_os="linux"
- ln -s Config.$sbcl_arch-linux Config
+ if [ $sbcl_arch = "x86-64" ]; then
+ ln -s Config.x86_64-linux Config
+ else
+ ln -s Config.$sbcl_arch-linux Config
+ fi
ln -s $sbcl_arch-linux-os.h target-arch-os.h
ln -s linux-os.h target-os.h
;;
;;; versions which break binary compatibility. But it certainly should
;;; be incremented for release versions which break binary
;;; compatibility.
-(def!constant +fasl-file-version+ 53)
+(def!constant +fasl-file-version+ 54)
;;; (record of versions before 2003 deleted in 2003-04-26/0.pre8.107 or so)
;;; 38: (2003-01-05) changed names of internal SORT machinery
;;; 39: (2003-02-20) in 0.7.12.1 a slot was added to
;;; 53: (2005-02-22) Something introduced in SBCL 0.8.19.26 (give or take
;;; a couple of patches) invalidated some FFI-related fasls. Probably
;;; caused by "lazy alien resolution improvements".
+;;; 54: (2005-03-22) At least "0.8.20.6: Make FILE-STREAM and STRING-STREAM
+;;; potential mixins in CLOS" and "0.8.20.21: Add immediate single-floats
+;;; on x86-64."
;;; the conventional file extension for our fasl files
(declaim (type simple-string *fasl-file-type*))
;;; checkins which aren't released. (And occasionally for internal
;;; versions, especially for internal versions off the main CVS
;;; branch, it gets hairier, e.g. "0.pre7.14.flaky4.13".)
-"0.8.20.30"
+"0.8.20.31"