bug#67157: gcc-toolchain@4.8.5 not available on the official substitute servers

[Thomas Schwinge]

I ran into the same issue.

On 2023-11-16T11:25:18+0100, Simon Tournier <zimon.toutoune@gmail.com> wrote:
> On Mon, 13 Nov 2023 at 20:19, Frédéric Mahé <frederic.mahe@cirad.fr> wrote:
>> Is the absence of a x86-64 GNU Linux GCC 4.8.5 build deliberate?

> No, it is not deliberate, sadly.  Well, I have tried to find a past
> revision when gcc-toolchain@4.8.5 builds but I fail.
>
> The Guix Data Service shows that gcc-toolchain@4.8.5 is not available
> for the build farm named Bordeaux.  And the substitutes are also missing
> on the other build farm named Berlin.
>
> Well, my guess is the issue is related to an update of GCC.  Therefore,
> I am trying this commit:
>
>         27322ac30be6816eca33ee946a04d3b0ab32896f
>         CommitDate: Thu Sep 8 21:40:00 2022 +0200
>
> which is right before the update to GCC 11 as default.
>
>   guix time-machine --commit=27322ac30be6816eca33ee946a04d3b0ab32896f \
>        -- build gcc-toolchain@4.8.5 --no-grafts
>
> Wait and see…

I tried this, but after quite a long time, it failed, too.  :-|

    In file included from ../../gcc-4.8.5/gcc/cp/except.c:1008:
    cfns.gperf: At global scope:
    cfns.gperf:101:1: error: ‘const char* libc_name_p(const char*, unsigned 
int)’ redeclared inline with ‘gnu_inline’ attribute
    cfns.gperf:26:14: note: ‘const char* libc_name_p(const char*, unsigned 
int)’ previously declared here

If I'm understanding things right, Ricardo actually has addressed this
issue in commit e6994d7e3f3f4a69f984c9e67df27abe1bc07c1c
"gnu: gcc-arm-none-eabi-4.9: Fix incompatible redeclaration"
('gnu/packages/patches/gcc-4.9-inline.patch'), and similarly a number of
years earlier in commit db90eb8c2bd447ab53bed80e5b0ea5105a928cdf
"gnu: Add propeller-gcc-4" -- both not applied to the GCC 4.8 sources
we're trying to build here.  Anyway, putting Ricardo in CC, in case
you've got any input to this one here, too?  :-)

The latter commit's 'gnu/packages/patches/gcc-4.6-gnu-inline.patch'
indicates that "the 3.0.3 release of gperf" may be when this started, so
I'll try to invoke the time-machine for older than that, as a first
(hopefully simple) try.