GNU bug report logs - #74676
[core-packages-team 5/5] DRAFT gnu: gcc: Update gcc, gcc-toolchain to 14.

Previous Next

Full log

View this message in rfc822 format

From: Janneke Nieuwenhuizen <janneke <at> gnu.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: ekaitz <at> elenq.tech, andreas <at> enge.fr, efraim <at> flashner.co.il, 74676 <at> debbugs.gnu.org
Subject: [bug#74676] [core-packages-team 5/5] DRAFT gnu: gcc: Update gcc, gcc-toolchain to 14.
Date: Mon, 06 Jan 2025 14:30:03 +0100

Ludovic Courtès writes:

Hi,

> Janneke Nieuwenhuizen <janneke <at> gnu.org> skribis:
>
>> I've built the rust bootstrap several times already, guess I'll just go
>> for a new round.  But this time we can maybeu "cheat" with packages that
>> are too difficult to build, and build them with another gcc version than
>> 14?
>
> I haven’t followed closely (sorry!), but if it’s just a matter of adding
> ‘gcc-11’ (say) as a native input for a couple of packages, that’s
> probably okay.  Except perhaps for C libraries, because then we could
> end up with programs depending on two difference versions of libgcc_s.so
> & co.

Right.  I found that for c++ packages it's also tricky.   Anyway, at the
moment we have

--8<---------------cut here---------------start------------->8---
1198e662af gnu: clang-runtime-17: Build with gcc-13.
eef34a6748 gnu: clang-runtime-18: Build with gcc-13.
bf33f0022e gnu: python-cython-next: Build with gcc-13.
0ae054278b gnu: ghc-8.4.4: Build with gcc-13.
5e65c4721a gnu: ghc-8.0.2: Build with gcc-13.
804a75c785 gnu: perl-tk: Build with gcc-12.
269da0d77f gnu: json-c-0.13: Fix build with gcc-13.
68545a30d7 gnu: gavl: Fix build by using gcc-13.
--8<---------------cut here---------------end--------------->8---

Silly but just the other day I realised why using a non-gcc-14 is so
problematic: we won't have that package (or any of its dependencies) on
the Hurd :).

Especially ghc might be problematic, but I spent a lot of time trying to
set relaxing CFLAGS (-copt-Wno-error=...) on every necessary build
"level" and got bored of the slow feedback cycle ("it didn't build").

Otoh, possibly things may improve before we really need these packages
on the Hurd and possibly others have more helpful ideas for fixing a
certain package.

I'm a bit puzzled that ci.guix.gnu.org says 81% success, that cannot be
right?  Sure, I worked very hard and we only have x86_64-linux and
i686-linux enabled atm but still?

FWIW, I just built libstd++ on aarch64 too :)

I also included (and reverted for now to avoid a world rebuild, so still
pretty much untested atm)

--8<---------------cut here---------------start------------->8---
ed4c3760fc gexp: Improve support of Unicode characters.
--8<---------------cut here---------------end--------------->8---

from <https://issues.guix.gnu.org/73660> that seems OK but IWBN if
someone could have a look at that.

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen <janneke <at> gnu.org>  | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

Previous Next

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