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

GNU bug report logs - #33848
Store references in SBCL-compiled code are "invisible"

Package: guix;

Reported by: Ludovic Courtès <ludo <at> gnu.org>

Date: Sun, 23 Dec 2018 14:21:02 UTC

Severity: important

Tags: fixed

Done: Ludovic Courtès <ludo <at> gnu.org>

Bug is archived. No further changes may be made.

View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org> To: 33848 <at> debbugs.gnu.org Cc: Pierre Neidhardt <mail <at> ambrevar.xyz>, Andy Patterson <ajpatter <at> uwaterloo.ca> Subject: bug#33848: Store references in SBCL-compiled code are "invisible" Date: Sun, 23 Dec 2018 15:19:30 +0100

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’.

This bug report was last modified 4 years and 7 days ago.

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.

GNU bug report logs - #33848 Store references in SBCL-compiled code are "invisible"

GNU bug report logs - #33848
Store references in SBCL-compiled code are "invisible"