From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9631 invoked by alias); 29 Mar 2019 23:42:44 -0000 Mailing-List: contact dwz-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: dwz-owner@sourceware.org Received: (qmail 9612 invoked by uid 89); 29 Mar 2019 23:42:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.0 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=Debian, HX-Languages-Length:1347 X-Spam-Status: No, score=-5.0 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sourceware.org X-Spam-Level: X-HELO: gnu.wildebeest.org Message-ID: <8f249c07c1cb9a6cbf78eec5c05b3c5641cd5526.camel@klomp.org> Subject: Re: Buildbot failure in Wildebeest Builder on whole buildset From: Mark Wielaard To: dwz@sourceware.org Cc: Tom de Vries Date: Tue, 01 Jan 2019 00:00:00 -0000 In-Reply-To: <20190329214227.59AA4817A87@builder.wildebeest.org> References: <20190329214227.59AA4817A87@builder.wildebeest.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-2.el7) Mime-Version: 1.0 X-Spam-Flag: NO X-SW-Source: 2019-q1/txt/msg00164.txt.bz2 On Fri, 2019-03-29 at 21:42 +0000, buildbot@builder.wildebeest.org wrote: > The Buildbot has detected a failed build on builder whole buildset > while building dwz. > Full details are available at: > https://builder.wildebeest.org/buildbot/#builders/19/builds/34 >=20 > Buildbot URL: https://builder.wildebeest.org/buildbot/ >=20 > Worker for this Build: fedora-x86_64 Which is Fedora 29. The other builders that fail are also Fedora based. The Debian and CentOS builds still seem to work. The problem is this commit: commit 388977c1ccdaf376540a651ee34cdf709891e0fe Author: Tom de Vries Date: Fri Mar 29 21:55:24 2019 +0100 Compile dwz-for-tests with -U__GNUC__ Undefining __GNUC__ causes issues with some include files, specifically: In file included from /usr/include/bits/floatn.h:119, from /usr/include/stdlib.h:55, from dwz.c:30 __GNUC__ defines the major version of GCC (8 on Fedora 29). Since GCC 7 the compiler defines the builtin types _Float32 and _Float64 so floatn.h doesn't have to define them. But since we undefine __GNUC__ the header cannot check the GCC version anymore and tries to define them anyway. Causing the compile error. I think the commit should just be reverted. It isn't clear to me what it really tries to check for. Cheers, Mark