GNU bug report logs

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

PackageSource(s)Maintainer(s)
guix PTS Buildd Popcon
Full log

Message #115 received at 33848@debbugs.gnu.org (full text, mbox, reply):

Received: (at 33848) by debbugs.gnu.org; 1 Apr 2021 09:13:16 +0000
From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 01 05:13:16 2021
Received: from localhost ([127.0.0.1]:56298 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces@debbugs.gnu.org>)
	id 1lRtO8-0001HB-FA
	for submit@debbugs.gnu.org; Thu, 01 Apr 2021 05:13:16 -0400
Received: from relay6-d.mail.gandi.net ([217.70.183.198]:45993)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mail@ambrevar.xyz>) id 1lRtO6-0001Gv-Ed
 for 33848@debbugs.gnu.org; Thu, 01 Apr 2021 05:13:14 -0400
X-Originating-IP: 92.169.147.163
Received: from bababa (lfbn-idf2-1-1335-163.w92-169.abo.wanadoo.fr
 [92.169.147.163]) (Authenticated sender: mail@ambrevar.xyz)
 by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 16076C000F;
 Thu,  1 Apr 2021 09:13:07 +0000 (UTC)
From: Pierre Neidhardt <mail@ambrevar.xyz>
To: Guillaume Le Vaillant <glv@posteo.net>, Ludovic Courtès
 <ludo@gnu.org>
Subject: Re: bug#33848: Store references in SBCL-compiled code are "invisible"
In-Reply-To: <87im56l6es.fsf@yamatai>
References: <87r2e8jpfx.fsf@gnu.org> <874lb3kin6.fsf@ambrevar.xyz>
 <87sgynezha.fsf@gnu.org> <87tvj2yesd.fsf@netris.org>
 <877efwe04u.fsf@gnu.org> <8736qji7c1.fsf@ambrevar.xyz>
 <87tvizvzgk.fsf@netris.org> <87o9979gfn.fsf@gnu.org>
 <87tvizgghs.fsf@ambrevar.xyz> <87k1juaomo.fsf@gnu.org>
 <87muoqhk62.fsf@ambrevar.xyz> <87zhsq8wkj.fsf@gnu.org>
 <87d0pmhbgn.fsf@ambrevar.xyz> <87r2e28tkv.fsf@gnu.org>
 <874laygkiy.fsf@ambrevar.xyz> <87lfa5eymf.fsf@ambrevar.xyz>
 <87tuoscsk9.fsf@gnu.org> <87im57b8u7.fsf@ambrevar.xyz>
 <87czvebky2.fsf@netris.org> <87eefu30a4.fsf@gnu.org>
 <87im56l6es.fsf@yamatai>
Date: Thu, 01 Apr 2021 11:13:07 +0200
Message-ID: <87wntm8j18.fsf@ambrevar.xyz>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha256; protocol="application/pgp-signature"
X-Spam-Score: 1.8 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: Hi Guillaume! > A store reference to a C library in a
 standalone
 Lisp binary can come > either from the current package or from some
 dependencies
 > (cl+ssl, cl-cffi-gtk, etc.). So we would need to scan the source > [...]
 Content analysis details:   (1.8 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
 low trust [217.70.183.198 listed in list.dnswl.org]
 0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3)
 [217.70.183.198 listed in wl.mailspike.net]
 2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
 [URI: ambrevar.xyz (xyz)]
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
 0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
X-Debbugs-Envelope-To: 33848
Cc: Mark H Weaver <mhw@netris.org>, 33848@debbugs.gnu.org
X-BeenThere: debbugs-submit@debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request@debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit@debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request@debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request@debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces@debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
X-Spam-Score: 1.8 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Hi Guillaume! > A store reference to a C library in a standalone
    Lisp binary can come > either from the current package or from some dependencies
    > (cl+ssl, cl-cffi-gtk, etc.). So we would need to scan the source > [...]
    
 
 Content analysis details:   (1.8 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
                             low trust
                             [217.70.183.198 listed in list.dnswl.org]
  0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3)
                             [217.70.183.198 listed in wl.mailspike.net]
  2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
                             [URI: ambrevar.xyz (xyz)]
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager
  0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
  1.0 BULK_RE_SUSP_NTLD      Precedence bulk and RE: from a suspicious TLD

[Message part 1 (text/plain, inline)]
Hi Guillaume!

> A store reference to a C library in a standalone Lisp binary can come
> either from the current package or from some dependencies
> (cl+ssl, cl-cffi-gtk, etc.). So we would need to scan the source
> code of all the Lisp dependencies recursively to get the full list of
> store refrences.

I don't think there is need to scan recursively: if package A depends on
B which depends on C, then A can lists the dependency on B in a file,
and B can do the same for C.  This way the relationship between A and C
is properly stored.

Am I missing something?

> And as Mark wrote below, with the current grafting code, this list of
> store references will not solve grafting for paths that are in UTF-32 or
> both in ASCII and UTF-32 in the binary file.

Indeed, and that's the core of the issue here I believe, since grafting
is what breaks Nyxt in practice.

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.

debbugs.gnu.org maintainers <help-debbugs@gnu.org>. Last modified: Sat Apr 12 12:33:48 2025; Machine Name: wallace-server

GNU bug tracking system

Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors.