From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Subject: bug#33848: Store references in SBCL-compiled code are "invisible" Date: Mon, 24 Dec 2018 16:06:09 +0100 Message-ID: <87sgynezha.fsf@gnu.org> References: <87r2e8jpfx.fsf@gnu.org> <877eg0i43j.fsf@netris.org> <87d0psi1xo.fsf@gnu.org> <874lb3kin6.fsf@ambrevar.xyz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([208.118.235.92]:50976) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gbRov-0005jh-Bt for bug-guix@gnu.org; Mon, 24 Dec 2018 10:07:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gbRos-0000F0-5N for bug-guix@gnu.org; Mon, 24 Dec 2018 10:07:05 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:59515) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gbRos-0000El-1m for bug-guix@gnu.org; Mon, 24 Dec 2018 10:07:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gbRor-00064N-Nw for bug-guix@gnu.org; Mon, 24 Dec 2018 10:07:01 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <874lb3kin6.fsf@ambrevar.xyz> (Pierre Neidhardt's message of "Sun, 23 Dec 2018 23:01:01 +0100") 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: Pierre Neidhardt Cc: 33848@debbugs.gnu.org Hi Pierre, Pierre Neidhardt skribis: >> I don=E2=80=99t think we=E2=80=99ve encountered the problem before. > > Actually it does ring a bell for me. Didn't we have a similar issue with= Fish, > or some dependency? We did have a problem with Fish but I can no longer find it. Do you remember what it was? Something with C++, no? >> For now I lean towards looking for a way to address the issue >> specifically for SBCL. > > Don't forget that we currently have 5 Lisp compilers. > Besides, it's not clear that this can be fixed on the compiler's side, it= could > very well be that patches will be required on a per-project basis. I know little about CL but maybe we can find a solution that works for all five compilers. At least that would be the first approach I would suggest following. Thanks, Ludo=E2=80=99.