From: "Ludovic Courtès" <ludo@gnu.org>
To: 33848@debbugs.gnu.org
Cc: Pierre Neidhardt <mail@ambrevar.xyz>
Subject: bug#33848: Store references in SBCL-compiled code are "invisible"
Date: Sun, 23 Dec 2018 15:19:30 +0100 [thread overview]
Message-ID: <87r2e8jpfx.fsf@gnu.org> (raw)
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’.
next reply other threads:[~2018-12-23 14:22 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-23 14:19 Ludovic Courtès [this message]
2018-12-23 15:05 ` bug#33848: Store references in SBCL-compiled code are "invisible" Pierre Neidhardt
2018-12-24 14:57 ` Ludovic Courtès
2018-12-23 16:45 ` Mark H Weaver
2018-12-23 17:32 ` Ludovic Courtès
2018-12-23 22:01 ` Pierre Neidhardt
2018-12-24 15:06 ` Ludovic Courtès
2018-12-24 17:08 ` Pierre Neidhardt
2018-12-26 16:07 ` Ludovic Courtès
2018-12-24 18:12 ` Mark H Weaver
2018-12-24 23:58 ` Pierre Neidhardt
2018-12-26 16:14 ` Ludovic Courtès
2018-12-27 10:37 ` Pierre Neidhardt
2018-12-27 14:03 ` Mark H Weaver
2018-12-27 14:45 ` Ludovic Courtès
2018-12-27 15:02 ` Pierre Neidhardt
2018-12-27 16:15 ` Pierre Neidhardt
2018-12-27 17:03 ` Ludovic Courtès
2018-12-27 18:57 ` Pierre Neidhardt
2018-12-27 21:54 ` Ludovic Courtès
2018-12-27 22:05 ` Pierre Neidhardt
2018-12-27 22:59 ` Ludovic Courtès
2018-12-28 7:47 ` Pierre Neidhardt
2021-03-30 10:15 ` Pierre Neidhardt
2021-03-30 20:09 ` Ludovic Courtès
2021-03-31 7:10 ` Pierre Neidhardt
2021-03-31 16:12 ` Pierre Neidhardt
2021-03-31 20:42 ` Ludovic Courtès
2021-03-31 20:57 ` Pierre Neidhardt
2021-04-01 17:23 ` Mark H Weaver
2021-04-02 15:13 ` Ludovic Courtès
2021-04-01 6:03 ` Mark H Weaver
2021-04-01 7:13 ` Pierre Neidhardt
2021-04-01 7:57 ` Ludovic Courtès
2021-04-01 8:48 ` Pierre Neidhardt
2021-04-01 9:07 ` Guillaume Le Vaillant
2021-04-01 9:13 ` Pierre Neidhardt
2021-04-01 9:52 ` Guillaume Le Vaillant
2021-04-01 10:06 ` Pierre Neidhardt
2021-04-01 10:07 ` Pierre Neidhardt
2021-04-01 15:24 ` Ludovic Courtès
2021-04-01 17:33 ` Mark H Weaver
2021-04-02 22:46 ` Mark H Weaver
2021-04-03 6:51 ` Pierre Neidhardt
2021-04-03 20:10 ` Mark H Weaver
2021-04-05 19:45 ` Ludovic Courtès
2021-04-05 23:04 ` Mark H Weaver
2021-04-06 8:16 ` Ludovic Courtès
2021-04-06 8:23 ` Pierre Neidhardt
2021-04-30 20:03 ` Mark H Weaver
2021-05-01 9:22 ` Pierre Neidhardt
2021-05-11 8:46 ` Ludovic Courtès
2021-04-06 17:23 ` Leo Famulari
2021-04-06 23:21 ` Mark H Weaver
2021-04-06 11:19 ` Mark H Weaver
2021-04-08 10:13 ` Ludovic Courtès
2021-04-13 20:06 ` Mark H Weaver
2021-04-14 10:55 ` Ludovic Courtès
2021-04-14 22:37 ` Leo Famulari
2021-04-15 7:26 ` Mark H Weaver
2021-04-16 9:44 ` Pierre Neidhardt
2018-12-27 13:52 ` Danny Milosavljevic
2018-12-27 14:29 ` Mark H Weaver
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r2e8jpfx.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=33848@debbugs.gnu.org \
--cc=mail@ambrevar.xyz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).