GNU bug report logs - #36882
QEMU 4 fails to build for x86_64-linux

Previous Next

Full log

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

From: Marius Bakke <mbakke <at> fastmail.com>
To: Mathieu Othacehe <m.othacehe <at> gmail.com>
Cc: 36882 <at> debbugs.gnu.org, Ludovic Courtès <ludo <at> gnu.org>,
 Jan Nieuwenhuizen <janneke <at> gnu.org>
Subject: Re: Qemu 4.2.0 build for x86_64-linux fails
Date: Tue, 03 Mar 2020 21:37:11 +0100

[Message part 1 (text/plain, inline)]

Marius Bakke <mbakke <at> fastmail.com> writes:

> Hello Mathieu & Ludo,
>
> (+ janneke)
>
> Mathieu Othacehe <m.othacehe <at> gmail.com> writes:
>
>>> Yup, turned out patching GCC was too difficult. I'm experimenting a
>>> filter over inputs passed to set-path-environment-variable in set-paths.
>>
>> This is also quite tricky, because the "libc" input passed to set-paths
>> must not be removed from C_INCLUDE_PATH in (gnu packages commencement)
>> for mes packages.
>
> If that is the only issue preventing us from solving this problem for
> all build systems, I'd say let's fix that.  We could rename it obviously,
> though there are a few places that expect the "libc" key so it may become
> unwieldly.
>
> Can we find another way to detect the Mes toolchain, perhaps directly in
> gnu-build-system where we apply this workaround?  E.g. look for inputs
> where (string-contains (package-name input) "mesboot")?
>
> Suggestions?

I realize we don't have access to PACKAGE-NAME in the builder, though we
could check for the string in the store item names.  'mesboot' contains
an 'e' and is thus guaranteed not to end up in the hash.

Not a very elegant solution though, hoping for other suggestions.  :-)

[signature.asc (application/pgp-signature, inline)]

Previous Next

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