bug#33848: Store references in SBCL-compiled code are "invisible"

[Ludovic Courtès]

Hello,

As discussed with Pierre at the R-B Summit, ‘sbcl-next’ lacks a
reference to ‘next-gtk-webkit’ even though is invokes it:

--8<---------------cut here---------------start------------->8---
$ guix gc --references $(type -P next) | grep next-
/gnu/store/9d66xb8wvggsp0x9pxj61mzqy007978f-sbcl-next-1.1.0
/gnu/store/pqy064fw3vkfld6lw95vi0zavj19zvrc-sbcl-next-1.1.0-lib
$ ./pre-inst-env guix run next

WARNING: Setting locale failed.
  Check the following variables for correct values:
  LANG=en_US.utf8
Unhandled SIMPLE-ERROR in thread #<SB-THREAD:THREAD "main thread" RUNNING
                                    {10005885B3}>:
  Couldn't execute 
"/gnu/store/7p6pbcmdgr53dff6033gcfl2jq0d762h-next-gtk-webkit-1.1.0/bin/next-gtk-webkit":
 No such file or directory
--8<---------------cut here---------------end--------------->8---

(Here ‘guix run’ runs ‘next’ in a container with exactly the closure of
‘next’, nothing more, and the ‘next’ binary is grafted.)

So the problem looks a lot like that this GCC issue we fixed a while
back: <https://bugs.gnu.org/24703>.

Looking at the ‘sbcl-next’ package, the reference to ‘next-gtk-webkit’
is inserted in gtk-webkit.lisp:

--8<---------------cut here---------------start------------->8---
(defvar *gtk-webkit-command* "next-gtk-webkit"
  "Path to the GTK-Webkit platform port executable.")
--8<---------------cut here---------------end--------------->8---

Through hexl-mode on the ‘next’ binary, we can find that reference:

--8<---------------cut here---------------start------------->8---
01d0bac0: 2f00 0000 6700 0000 6e00 0000 7500 0000  /...g...n...u...
01d0bad0: 2f00 0000 7300 0000 7400 0000 6f00 0000  /...s...t...o...
01d0bae0: 7200 0000 6500 0000 2f00 0000 3700 0000  r...e.../...7...
01d0baf0: 7000 0000 3600 0000 7000 0000 6200 0000  p...6...p...b...
01d0bb00: 6300 0000 6d00 0000 6400 0000 6700 0000  c...m...d...g...
01d0bb10: 7200 0000 3500 0000 3300 0000 6400 0000  r...5...3...d...
01d0bb20: 6600 0000 6600 0000 3600 0000 3000 0000  f...f...6...0...
01d0bb30: 3300 0000 3300 0000 6700 0000 6300 0000  3...3...g...c...
01d0bb40: 6600 0000 6c00 0000 3200 0000 6a00 0000  f...l...2...j...
01d0bb50: 7100 0000 3000 0000 6400 0000 3700 0000  q...0...d...7...
01d0bb60: 3600 0000 3200 0000 6800 0000 2d00 0000  6...2...h...-...
01d0bb70: 6e00 0000 6500 0000 7800 0000 7400 0000  n...e...x...t...
01d0bb80: 2d00 0000 6700 0000 7400 0000 6b00 0000  -...g...t...k...
01d0bb90: 2d00 0000 7700 0000 6500 0000 6200 0000  -...w...e...b...
01d0bba0: 6b00 0000 6900 0000 7400 0000 2d00 0000  k...i...t...-...
01d0bbb0: 3100 0000 2e00 0000 3100 0000 2e00 0000  1.......1.......
01d0bbc0: 3000 0000 2f00 0000 6200 0000 6900 0000  0.../...b...i...
01d0bbd0: 6e00 0000 2f00 0000 6e00 0000 6500 0000  n.../...n...e...
01d0bbe0: 7800 0000 7400 0000 2d00 0000 6700 0000  x...t...-...g...
01d0bbf0: 7400 0000 6b00 0000 2d00 0000 7700 0000  t...k...-...w...
01d0bc00: 6500 0000 6200 0000 6b00 0000 6900 0000  e...b...k...i...
01d0bc10: 7400 0000 0000 0000 0000 0000 0000 0000  t...............
01d0bc20: e100 0100 0000 0000 2800 0000 0000 0000  ........(.......
01d0bc30: 2a47 544b 2d57 4542 4b49 542d 434f 4d4d  *GTK-WEBKIT-COMM
01d0bc40: 414e 442a 0000 0000 0000 0000 0000 0000  AND*............
--8<---------------cut here---------------end--------------->8---

Apparently this string literal is stored as UTF-32 (UCS-4) or similar,
which prevents the reference scanner and the grafting code from finding
it, and problems ensue.  :-)

Pierre, Andy: is there any way to tell SBCL to store this literal as
ASCII/UTF-8?  That would be an easy fix, though we should discuss the
pros and cons and whether to enable that globally.

Thanks in advance!

Ludo’.