From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tobias Geerinckx-Rice Subject: Re: Prevent native-inputs references ending up in the final binary Date: Fri, 26 Jan 2018 02:05:09 +0100 Message-ID: <1516928709.13891.64.camel@tobias.gr> References: <81597a04-598a-e894-84af-759c1b5401ca@tobias.gr> <20180120001317.GD18016@jasmine.lan> <20180120114059.34736dda@scratchpost.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:55715) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eesSL-0008Us-Oh for guix-devel@gnu.org; Thu, 25 Jan 2018 20:05:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eesSK-0003GC-P1 for guix-devel@gnu.org; Thu, 25 Jan 2018 20:05:25 -0500 In-Reply-To: List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Fis Trivial , Danny Milosavljevic , Leo Famulari , "ludo@gnu.org" Cc: "guix-devel@gnu.org" Hullo, On Fri, 2018-01-26 at 00:56 +0000, Fis Trivial wrote: > On 01/20/2018 06:40 PM, Danny Milosavljevic wrote: > > I think that native-inputs shouldn't end up in the final binary as > > a > > reference, especially when cross-compiling > > (but we don't do cross-compilation much in Guix - usually, we let > > qemu-arm emulate the ARM CPU on x86_64 and just call the target > > tool :) ). > > > > If there are indeed parts of the same package, one a native part > > and one a > > runtime dependency part, I actually write the same package > > reference twice, > > once in the inputs, once in the native-inputs, in my custom package > > definitions. > > > > In a "previous life" I did a lot of Linux cellphone development > > and, > > there, it was kinda important that a x86_64 toolchain doesn't end > > up being referenced in an ARM binary, so the habit stuck - and I > > think it's important to distinguish the mold used to form a product > > from an integral part of that product. > > > > I'm no expert, but can this little utility from nix help? > https://nixos.org/patchelf.html In what way? Patchelf re-writes library and/or loader paths in compiled binaries. It's cool, but I don't immediately see the connexion... Kind regards, T G-R