compiling SBCL (sbcl-2.2.0-54-gd8d20c0af) with ECL (21.2.1) fails on Mingw (32-bit)

[alexis rivera]

When compiling SBCL version sbcl-2.2.0-54-gd8d20c0af with ECL version 21.2.1 on Mingw (32-bit windows) I get the following error:

;;; Compiling #<input stream src/compiler/x86/vm.lisp 0xb3f0cb8>.
;;; Loading "D:/Downloads/sbcl_latest/sbcl/obj/from-host/src/compiler/x86/vm.fasc"

Condition of type: SIMPLE-PACKAGE-ERROR
Cannot intern symbol "MAKE-SINGLE-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::HOST-CLOAD-STEM. In: #<process TOP-LEVEL 0x5b60fc0>.
 File: #P"D:/Downloads/sbcl_latest/sbcl/src/cold/shared.lisp" (Position #36095)
>>

real 2m17.134s
user 0m0.107s
sys 0m0.249s
//entering make-target-1.sh
//building runtime system and symbol table file
make: Entering directory '/d/Downloads/sbcl_latest/sbcl/src/runtime'
GNUmakefile:41: genesis/Makefile.features: No such file or directory
make: *** No rule to make target 'genesis/Makefile.features'. Stop.
make: Leaving directory '/d/Downloads/sbcl_latest/sbcl/src/runtime'

The command uname -a returns
MINGW32_NT-10.0-19042 DESKTOP-0ETM2HC 3.2.0-340.i686 2021-07-04 19:22 UTC i686 Msys

Attached is a file dump32.txt containing the compilation output.

I will appreciate your help, decoding the error.

[alexis rivera (riveraah)]

Compiled ECL as documented in https://bugs.launchpad.net/sbcl/+bug/1956876

[alexis rivera (riveraah)]

What does Condition of type: SIMPLE-PACKAGE-ERROR Cannot intern symbol "MAKE-SINGLE-FLOAT" in locked package mean? Is this a symptom of a compiler bug in ECL given that it works in Mingw64?

[alexis rivera (riveraah)]

I'm going to try compiling SBCL from the ECL develop branch code and see if that works.

[alexis rivera (riveraah)]

the ECL develop branch still has this issue.

[alexis rivera (riveraah)]

The ECL developers commented on this bug. They think it's a bug in SBCL and suggested a possible fix. Their analysis is documented on this issue report and ask for feedback.

https://gitlab.com/embeddable-common-lisp/ecl/-/issues/669

[alexis rivera (riveraah)]

SBCL compiles successfully when the fix in comment #6 is applied.

[Douglas Katzman (dougk)]

I'm slightly disinclined to take that analysis as gospel, because everybody and I do mean EVERYBODY gets confused by the fact that SBCL's self-build shadows the symbols SINGLE-FLOAT and DOUBLE-FLOAT, and then redefines them as new types (which is legal to do since it's a different symbol).
* (cl:symbol-package 'single-float)
#<PACKAGE "SB-XC">
* (cl:symbol-package 'double-float)
#<PACKAGE "SB-XC">
* (host-sb-ext:typexpand 'single-float)
(SATISFIES SINGLE-FLOAT-P)
T
* (host-sb-ext:typexpand 'double-float)
(SATISFIES DOUBLE-FLOAT-P)

As such, it shouldn't be illegal in any sense to attach any kind of print method that does anything whatsoever. It doesn't "have to" obey print-readable or anything.
Nonetheless I wouldn't say they're wrong, just that I think we don't have a grip on the problem yet. Why our code cares about the print-object method is actually confusing to me. I thought it was only as a debugging aid. On the other hand, maybe that's the right fix, even though no other lisp needs it. I need some time to think of whether I like that fix.

[Douglas Katzman (dougk)]

I've responded in the ECL issue tracker.
https://gitlab.com/embeddable-common-lisp/ecl/-/issues/669#note_815566744

[Christophe Rhodes (csr21-cantab)]

Douglas Katzman <email address hidden> writes:

> I've responded in the ECL issue tracker.
> https://gitlab.com/embeddable-common-lisp/ecl/-/issues/669#note_815566744

I don't have a gitlab account (or maybe I do and I've lost the
credentials). My understanding was that the failure mode was because
ECL's bytecode compiler (used by default on Win32 but not Linux) in some
way uses the printed representation, maybe with a
(with-standard-io-syntax (let ((*print-readably* ...)) ...) in the mix
somewhere. So when we emit

  #.(MAKE-SINGLE-FLOAT ...)

with no package prefix, the implicit assumption that this will never be
used anywhere except our own code is wrong, because of something a bit
similar to our own make-load-form, and something somewhere in the host
lisp is broken because our cross-compiler float "printer" doesn't
respect enough of the printer control variables.

[Douglas Katzman (dougk)]

My main point though is that these objects are never printed.
There is a make-load-form method on the sb-xc:float type. If it wants to externalize one, it has to go through the load-form, not the printer. So I think trying to re-internalize based on a printed representation can only be deemed a bug.
(And I only pointed out the issue with our make-load-form weirdness because I found it to be annoying, and borderline noncompliant. But yes wouldn't it be ironic though if it hinted at the nature of the problem with ECL)

[Douglas Katzman (dougk)]

Oh, one more thing - the host doesn't get to decide what our 'float-math.lisp-expr' file contains.
If that suggested diff were applied, then the next change to the journal file would cause a diff on every line. Relative to the host, we're running perfectly ordinary user code that chooses how to print its objects. I'll eat my hat if someone can explain how this is nonconforming user code.

[alexis rivera (riveraah)]

It is interesting that this error didn't occur when I built the code in the 64-bit MINGW. Is it because they don't use the bytecode compiler in that platform?

[Douglas Katzman (dougk)]

Sure maybe. Can't speculate on what the differences in ECL builds stem from. Resolving as not our bug.