GNU bug report logs - #36346
[PATCH] gnu: Allow building toolchain with non-default libc.

Previous Next

Full log

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

From: Carl Dong <contact <at> carldong.me>
To: Marius Bakke <mbakke <at> fastmail.com>
Cc: "36346 <at> debbugs.gnu.org" <36346 <at> debbugs.gnu.org>
Subject: Re: [bug#36346] [PATCH] gnu: Allow building toolchain with
 non-default libc.
Date: Sun, 07 Jul 2019 14:42:24 +0000

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 Bitcoin
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/f373beebbcc0c7d1160e02dc638a00b3e6831d98/src/compat/glibc_compat.cpp)
all the way up to 2.27 (since we need RISCV support). With Guix, I hope that 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/e8dd4da0b287e0fe252c99bb4a7cb26c2e947b71/contrib/guix/packages/gcc-bitcoin.scm#L91

> Guix excels at creating bespoke toolchains like these. It is easy to express
> 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 fairly
> specific use case.
>
> I would expect any reasonably complex toolchain to need further tweaks, and 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 porting
riscv64 to Guix, where I realized that I had to override the default gcc version
(riscv64 requires gcc 7.1), glibc version (2.27), and kernel headers version
(4.15). That makes me think that the sensible list of things to be overridable
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 happy to
implement and change. :-)


Cheers,
Carl Dong
contact <at> carldong.me
"I fight for the users"

Previous Next

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