From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:51412) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hk8Ng-0004ZP-Em for guix-patches@gnu.org; Sun, 07 Jul 2019 10:43:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hk8Ne-0003Jl-2G for guix-patches@gnu.org; Sun, 07 Jul 2019 10:43:07 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:48479) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hk8Nb-0003Hh-0y for guix-patches@gnu.org; Sun, 07 Jul 2019 10:43:04 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hk8Na-0000FR-S5 for guix-patches@gnu.org; Sun, 07 Jul 2019 10:43:02 -0400 Subject: [bug#36346] [PATCH] gnu: Allow building toolchain with non-default libc. Resent-Message-ID: Date: Sun, 07 Jul 2019 14:42:24 +0000 From: Carl Dong Message-ID: In-Reply-To: <87y31cqeu7.fsf@devup.no> References: <87y31cqeu7.fsf@devup.no> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Carl Dong Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Marius Bakke Cc: "36346@debbugs.gnu.org" <36346@debbugs.gnu.org> Hi Marius! > It would be easier to digest this patch if it came with an actual user of= this > change. Right now it complicates a very simple procedure for no apparent > reason. Can you elaborate a bit on the use case? Ah! This change is motivated by the work I've been doing in shifting the Bi= tcoin release process to a Guix-based one. The binaries we produce aim to be compatible with GLIBC_2_11, and we have glibc compat wrappers (https://github.com/bitcoin/bitcoin/blob/f373beebbcc0c7d1160e02dc638a00b3e6= 831d98/src/compat/glibc_compat.cpp) all the way up to 2.27 (since we need RISCV support). With Guix, I hope tha= t we don't have to keep updating compat wrappers anymore, and pin our toolchain = glibc version to a fixed one. See here for how I use this: https://github.com/bitcoin/bitcoin/blob/e8dd4da0b287e0fe252c99bb4a7cb26c2e9= 47b71/contrib/guix/packages/gcc-bitcoin.scm#L91 > Guix excels at creating bespoke toolchains like these. It is easy to expr= ess > this change as a new 'make-gcc-toolchain-with-custom-libc' procedure. So = I'm > not sure if it's worth changing 'make-gcc-toolchain', which serves a fair= ly > specific use case. > > I would expect any reasonably complex toolchain to need further tweaks, a= nd we > cannot possibly support all such configuration inside 'make-gcc-toolchain= '. > > It does sound useful to make these procedures more generally accessible > however. Perhaps 'make-gcc-toolchain' could be implemented in terms of a = more > generic 'make-toolchain' interface? That all sound like promising solutions. My thought process comes from port= ing riscv64 to Guix, where I realized that I had to override the default gcc ve= rsion (riscv64 requires gcc 7.1), glibc version (2.27), and kernel headers versio= n (4.15). That makes me think that the sensible list of things to be overrida= ble for a toolchain would be those three, in case of future architectures. I've submitted previous patches to cross-base.scm that added the ability to parameterize these three, and this patch was simply doing the same for gcc-toolchain. Anyway, please let me know which approach you'd prefer, and I'd be very hap= py to implement and change. :-) Cheers, Carl Dong contact@carldong.me "I fight for the users"