[MacPorts] #64621: sbcl: build hangs on Monterey
noreply at macports.org
Sun Sep 11 23:45:13 UTC 2022
#64621: sbcl: build hangs on Monterey
Reporter: pmetzger | Owner: easye
Type: defect | Status: assigned
Priority: Normal | Milestone:
Component: ports | Version: 2.7.2
Resolution: | Keywords: monterey
Port: sbcl |
Comment (by kakuhen):
CCL is no-go for me because it simply moves "future binary blob disasters"
to another port and lacks Apple Silicon support. If I understood the
ReproducibleBuilds guidelines, then any particular change to x86_64
requires a corresponding change to arm64.
CLISP has the issue of long pauses between releases, and Apple Silicon
support is probably not as well tested some of the more actively
maintained Common Lisp implementations. Any bugs in CLISP would take
months to fix and even more months to appear in a release.
If we must switch to an alternative compiler, then either ABCL or ECL will
be the sane options in my opinion. Neither of them are written entirely in
C/C++ (ABCL is in fact built on top of the JVM), but again, we may be
introducing possible bugs that arise from ABCL or ECL compiling SBCL. With
that said, most package managers--if they wish to avoid starting an SBCL
bootstrap from an older SBCL--will use ECL, so that particular compiler
has, anecdotally, the most support. I would personally prefer to keep
bootstrapping from SBCL for best results; I will start asking for updated
bootstrap binaries on MLs to see if that helps the situation.
There really isn't a viable interpreter written entirely in C/C++. In
fact, most Common Lisp implementations are compiler-only (i.e. no
interpreted mode). I do know of one implementation that is indeed 100% C
(npt), but its not on MacPorts, and its full of memory bugs, issues with
**tl;dr**: I recommend ECL, if any alternative host, but be aware of the
tradeoffs; I prefer no alternative hosts.
Ticket URL: <https://trac.macports.org/ticket/64621#comment:34>
Ports system for macOS
More information about the macports-tickets