Compilation failure with SBCL >= 2.3.9, using 2.0.1-debian as bootstrap

[Patrick Poitras]

Hello all,

Our docker compilation rig uses SBCL version 2.0.1-debian. In trying to compile versions SBCL 2.3.9 and above, the build fails with the following error:

```
; wrote /home/tester/ppoitras/sbcl/obj/from-host/src/compiler/generic/genesis.fasl-tmp
; compilation finished in 0:00:00.920
;
; compilation unit finished
; caught 3 STYLE-WARNING conditions
While evaluating the form starting at line 125, column 0
  of #P"/home/tester/ppoitras/sbcl/make-host-1.lisp":

debugger invoked on a SIMPLE-ERROR in thread
#<THREAD "main thread" RUNNING {1000510083}>:
  make-host-1 stopped due to unexpected STYLE-WARNING.

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [CONTINUE ] Proceed anyway
  1: [RETRY ] Retry EVAL of current toplevel form.
  2: Ignore error and continue loading file "/home/tester/ppoitras/sbcl/make-host-1.lisp".
  3: [ABORT ] Abort loading file "/home/tester/ppoitras/sbcl/make-host-1.lisp".
  4: [ABORT-BUILD] Abort building SBCL.
  5: Exit debugger, returning to top level.
```

By messing around with make-host-1.lisp, I made it print the style-warnings when they occurred, and they seem like they're all of the redefining BLARG in defmacro variety. There are a lot of them.

I was able to reproduce with SBCL 2.0.1, 2.0.9; subsequent version compile without problems. (checked
2.0.10, 2.1.2, 2.3.3)

The compilation is simply calling ./make.sh, with no flags.

Please let me know if I can provide further information.

uname -a : Linux ppoitras-desktop-sprint-2024-05-02 5.15.0-76-generic #83-Ubuntu SMP Thu Jun 15 19:16:32 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

[Patrick Poitras (pfpoitras)]

Note that a rather brutish fix, given that it works on 2.0.10 and not on 2.0.9 is to specify

(string>= (cl:lisp-implementation-version) "2.1")

rather than

(string>= (cl:lisp-implementation-version) "2")

in make-host-1.lisp: line 50.

This has the side-effect of disabling warnings on 2.0.10 and 2.0.11, a less restrictive version of this could be something like:

(or (string>= (cl:lisp-implementation-version) "2.1")
    (string= (cl:lisp-implementation-version) "2.0.10")
    (string= (cl:lisp-implementation-version) "2.0.11"))

But it's probably better to ignore just the redefinition in defmacro warnings.

[Douglas Katzman (dougk)]

please provide the entire output. Though I suspect this may be fixed already

[Patrick Poitras (pfpoitras)]

I still am getting this error, on 2.4.6 and 2.4.7.

Here's the output of the entire 2.4.6 build, as reported by docker

#19 0.378 This is SBCL 2.0.1.debian, an implementation of ANSI Common Lisp.
#19 0.378 More information about SBCL is available at <http://www.sbcl.org/>.
#19 0.378
#19 0.378 SBCL is free software, provided as is, with absolutely no warranty.
#19 0.378 It is mostly in the public domain; some portions are provided under
#19 0.378 BSD-style licenses. See the CREDITS and COPYING files in the
#19 0.378 distribution for more information.
#19 0.386 * "SBCL"
#19 0.386 * rm -f *~ *.bak *.orig \#*\# .\#* texput.log *.fasl
#19 0.471 rm -rf sbcl asdf "docstrings/"
#19 0.474 rm -f sbcl.html asdf.html
#19 0.475 rm -f contrib-docs.texi-temp
#19 0.477 rm -f package-locks.texi-temp
#19 0.478 rm -f variables.texinfo
#19 0.480 rm -f sbcl.ps asdf.ps sbcl.pdf asdf.pdf html-stamp tempfiles-stamp
#19 0.481 rm -f asdf.aux asdf.cp asdf.cps asdf.fn asdf.fns asdf.ky asdf.log asdf.pg asdf.toc asdf.tp asdf.tps asdf.vr asdf.vrs sbcl.aux sbcl.cp sbcl.cps sbcl.fn sbcl.fns sbcl.ky sbcl.log sbcl.pg sbcl.toc sbcl.tp sbcl.tps sbcl.vr sbcl.vrs
#19 0.483 rm -f sbcl.info sbcl.info-* asdf.info
#19 0.492 rm -rf *.include *.info *.pdf *~ *.cp *.fn *.ky *.log *.pg *.toc \
#19 0.492 *.tp *.vr *.aux *.eps *.png *.dvi *.ps *.txt *.fns \
#19 0.492 html-stamp sbcl-internals/
#19 0.540 //entering make-config.sh
#19 0.540 //ensuring the existence of output/ directory
#19 0.540 //guessing default target CPU architecture from host architecture
#19 0.541 //setting up CPU-architecture-dependent information
#19 0.541 sbcl_arch="x86-64"
#19 0.542 //initializing /opt/src/sbcl-2.4.6/local-target-features.lisp-expr
#19 0.543 //setting up OS-dependent information
#19 0.558 make: Entering directory '/opt/src/sbcl-2.4.6/tools-for-build'
#19 0.558 cc -I../src/runtime avx2.c -o avx2
#19 0.624 make: Leaving directory '/opt/src/sbcl-2.4.6/tools-for-build'
#19 0.629 make: Entering directory '/opt/src/sbcl-2.4.6/tools-for-build'
#19 0.629 cc -I../src/runtime -Wunused-parameter -fno-omit-frame-pointer -momit-leaf-frame-pointer determine-endianness.c -ldl -o determine-endianness
#19 0.710 make: Leaving directory '/opt/src/sbcl-2.4.6/tools-for-build'
#19 1.378 //finishing /opt/src/sbcl-2.4.6/local-target-features.lisp-expr
#19 1.390 //building host tools
#19 1.394 make: Entering directory '/opt/src/sbcl-2.4.6/tools-for-build'
#19 1.394 cc -DDEFINE_MAIN -I../src/runtime -o perfecthash ../src/runtime/perfecthash.c
#19 1.656 make: Leaving directory '/opt/src/sbcl-2.4.6/tools-for-build'
#19 1.658 //Starting build: Tue Aug 27 15:40:54 PDT 2024
#19 1.658 //Options: --prefix='/opt/sbcl' --xc-host='sbcl --no-userinit --no-sysinit'
#19 1.660 This is SBCL 2.0.1.debian, an implementation of ANSI Common Lisp.
#19 1.660 More information about SBCL is available at <http://www.sbcl.org/>.
#19 1.660
#19 1.660 SBCL is free software, provided as is, with absolutely no warranty.
#19 1.660 It is mostly in the public domain; some portions are provided under
#19 1.660 BSD-style licenses. See the CREDITS and COPYING files in the
#19 1.660 distribution for more information.
#19 1.669 * NIL
#19 1.6...

[Douglas Katzman (dougk)]

So the "rather brutish" patch is fine; I've pushed that.
The main consideration is that the newest released SBCL should not warn about compiling a newer sbcl.
As much as I'd have liked to, I could not verify any claims about the value to plug in for "2.1" as my C tools, libc, and OS kernel each don't like some aspect of the C code at years-old revisions and I gave up trying to find one that worked.
Incidentally, bug 2009493 is where I added the STRING>= in the first place, for the same reason.