From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pierre Neidhardt Subject: bug#33848: Store references in SBCL-compiled code are "invisible" Date: Thu, 27 Dec 2018 23:05:44 +0100 Message-ID: <87d0pmhbgn.fsf@ambrevar.xyz> References: <87r2e8jpfx.fsf@gnu.org> <877eg0i43j.fsf@netris.org> <87d0psi1xo.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> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([208.118.235.92]:56993) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gcdn3-00015j-6K for bug-guix@gnu.org; Thu, 27 Dec 2018 17:06:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gcdn1-00072b-9S for bug-guix@gnu.org; Thu, 27 Dec 2018 17:06:04 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:42819) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gcdn0-0006zF-NH for bug-guix@gnu.org; Thu, 27 Dec 2018 17:06:03 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gcdn0-0006iF-Ax for bug-guix@gnu.org; Thu, 27 Dec 2018 17:06:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-reply-to: <87zhsq8wkj.fsf@gnu.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 33848@debbugs.gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > The reference scanner, currently written in C++, traverses whole > directory trees. Being C++ it treats file names as byte arrays so it > doesn=E2=80=99t matter what the file name encoding is. But what matters then is that the filename encodings on the filesystem and = in the binary match, right? > Note also that the reference scanner only looks for =E2=80=9Cxyz=E2=80=A6= -foo=E2=80=9D; what > comes before and after doesn=E2=80=99t matter. So for example if you have > =E2=80=9C/gnu/store/xyz=E2=80=A6-foo/=C3=A0=E2=80=9D, what=E2=80=99s impo= rtant is the =E2=80=9Cxyz=E2=80=A6-foo=E2=80=9D bit. OK, makes sense, then my main worry is just moot :) =2D-=20 Pierre Neidhardt https://ambrevar.xyz/ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEUPM+LlsMPZAEJKvom9z0l6S7zH8FAlwlTLgACgkQm9z0l6S7 zH/S3Qf/W9Oy7e1p3LkCiKM2l9t7jW3TezaUlHflLGmVd1zdiaTq/aeLdTfY2r+i +/aEweAHmQGD1oHWmSbnDMyBOQalzBNAQi8dg+oOSVNiMASWk+aHCj5OohE1mxrd dSLwTxk0a4BIM03GbEc/qFtI2nOZEJGjphkHJGjSKHB/5gzilsLVXRjajYWXVh/P qVaIH3xJzjA4zIyg711PQTKMqB8qIAKpr0OKA23vpZ1FaRKoNY5NRx/g1wQpFTfi 4ZdwgJwPwh3bDkU61C5mPiHcVARi8X3M65h96Aj+9RX9TCZ/+3oQTWexKTv2o0xH ZfSYbHpvtAb8xkg9sKLaN47TFoM2Zg== =djyT -----END PGP SIGNATURE----- --=-=-=--