2.3.11 broken on macOS 14 x86_64

[Kirill A. Korinskiy]

MacPorts build bots discovered a regression between 7e5c8161aeb33a11f6e853c40a7eedb6a6c38971 sbcl-2.3.11: https://github.com/sbcl/sbcl/compare/7e5c8161aeb33a11...sbcl-2.3.11

It fails as:

;;; Loading #P"/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_sbcl/sbcl/work/sbcl-2.3.11/obj/from-host/src/compiler/float-tran.fas"

Condition of type: SIMPLE-PACKAGE-ERROR
Cannot intern symbol "MAKE-DOUBLE-FLOAT" in locked package #<"COMMON-LISP" package>.
Available restarts:

1. (CONTINUE) Ignore lock and proceed.
2. (RECOMPILE) Recompile
3. (ABORT-BUILD) Abort building SBCL.
4. (RESTART-TOPLEVEL) Go back to Top-Level REPL.

Broken at SB-COLD::LOAD-OR-CLOAD-XCOMPILER. In: #<process TOP-LEVEL 0x105240ee0>.
 File: #P"/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_sbcl/sbcl/work/sbcl-2.3.11/src/cold/defun-load-or-cload-xcompiler.lisp" (Position #5133)
>>

[Sergey Fedorov (barracuda156)]

`sbcl` 2.3.11 also broken on Sonoma aarch64.

[Sergey Fedorov (barracuda156)]

sbcl build log from Sonoma / aarch64

[Kirill A. Korinskiy (catap)]

BTW I've tried to build 2.3.11 by the same ECL on macOS 12 and it works very well.

[Douglas Katzman (dougk)]

This is surely a problem in ECL, not SBCL.

The file 'float-tran.lisp' contains exactly two source lines with an explicit CL: package prefix, not counting the 1 comment line that has it. The symbols referred to are CL:LONG-FLOAT, CL:DOUBLE-FLOAT, and CL:SINGLE-FLOAT. So how pray tell does ECL believe that the SBCL code is trying to intern "MAKE-DOUBLE-FLOAT" in the COMMON-LISP package? There's no explicit call to INTERN, so it's likely a bug in the ECL loader (since it looks like COMPILE-FILE finished).
And regarding the complaints about DEFTRANSFORM which is SBCL's macro, why is it trying to say that the argument types are wrong?

I use CCL to compile SBCL, and that worked, so to suppose that both CCL and SBCL have "counteracting bugs" (i.e. a bug which allows the thing begin compiled to actually intern a new symbol in the CL package), you should really take this up with the ECL folks. Now that said, if you can identify a specific breaking change in SBCL, it's conceivable we might be able to find a workaround by expressing something differently.

[Stas Boukarev (stassats)]

Old ECL on github builds SBCL fine.

[Kirill A. Korinskiy (catap)]

Stas, the same version if ECL builds SBCL-2.3.10 on macOS 12 just fine. The issue is macOS 14.

BTW if you may distribute a binary which works on macOS 14, it allows to avoid using ECL to bootstrap SBCL.

[Stas Boukarev (stassats)]

It's not, I grabbed ecl from git and I get the same error on linux.

[Kirill A. Korinskiy (catap)]

I can reproduce the issue on macOS 13 with Xcode 15, and I can't reproduce this issue on different ECL.

So, this defently not SBCL issue

[Kirill A. Korinskiy (catap)]

Yes, deently ECL, see: https://gitlab.com/embeddable-common-lisp/ecl/-/issues/727