GNU bug report logs - #55657
libgccjit is unusable

Previous Next

Full log

Message #71 received at 55657 <at> debbugs.gnu.org (full text, mbox):

From: John Kehayias <john.kehayias <at> protonmail.com>
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Cc: Andrew Whatson <whatson <at> gmail.com>, Tobias Geerinckx-Rice <me <at> tobias.gr>,
 "remco <at> remworks.net" <remco <at> remworks.net>,
 "55657 <at> debbugs.gnu.org" <55657 <at> debbugs.gnu.org>
Subject: Re: libgccjit is unusable
Date: Sun, 07 Aug 2022 15:09:15 +0000

------- Original Message -------
On Sunday, August 7th, 2022 at 9:59 AM, Liliana Marie Prikler wrote:

> It's a really stupid one. Basically, the tests and really any
> executable you try to build fails to execute without LD_LIBRARY_PATH
> set. Now obviously, that's an issue with ld and you know which package
> has ld? That's right, it's binutils!
>

Ah! That LD_LIBRARY_PATH was needed was the clue.

> In Andrew's recipe, he sneakily snarfed out binutils from inputs using
> assoc-ref, but I'm using the new package style with (this-package-
> input) to achieve the same thing, so I had to add binutils. But this
> now shadows ld-wrapper. So we have to add ld-wrapper as well. Now
> this makes me question whether the driver options are actually sane or
> whether we'd have to prepend ld-wrapper to those as well.
>

Is the assoc-ref for binutils (implicit input?) equivalent to just using #$binutils directly? e.g. (string-append "-B" #$binutils "/bin/") with no added binutils to the inputs. Is that not a good idea? As a test, that does indeed work, everything configures, builds, and runs (only tested opening with no configuration).

> WDYT, Andrew?

Previous Next

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