From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4567 invoked by alias); 15 Jun 2012 19:15:46 -0000 Received: (qmail 4554 invoked by uid 22791); 15 Jun 2012 19:15:44 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_NO X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 15 Jun 2012 19:15:20 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id B61A31C6FF1; Fri, 15 Jun 2012 15:15:19 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9fAy7AvTmDa5; Fri, 15 Jun 2012 15:15:19 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 812401C6ED7; Fri, 15 Jun 2012 15:15:19 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 7857A145616; Fri, 15 Jun 2012 12:15:16 -0700 (PDT) Date: Fri, 15 Jun 2012 19:15:00 -0000 From: Joel Brobecker To: Hans-Peter Nilsson Cc: gdb-patches@sourceware.org Subject: Re: build error for mn10300-elf sim with your recent commit Message-ID: <20120615191516.GA18729@adacore.com> References: <201206151846.q5FIkL3Z026410@ignucius.se.axis.com> <20120615185559.GZ18729@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120615185559.GZ18729@adacore.com> User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-06/txt/msg00524.txt.bz2 > > My autotester complains that the sim build for mn10300-elf is > > broken, and your entry was the only one at the top of > > sim/mn10300/ChangeLog. There was a working build 5-6 hours > > earlier: > > Yeah, I think that might be me. I'll try to reproduce and fix. > If it's an easy fix, I won't be offdended if you send a patch :-). I think this one is really going to hurt. Amazing how a little change in bfd can have ripple effects everywhere. Basically: BFD changed the inclusion rules, now causing a build error if you include "bfd.h" without having included "config.h" before. We were including "config.h", but BFD failed to notice because of the fact that the PACKAGE macro was missing. I added it, and now we trip another requirement: Either we include "config.h", or we include "sysdep.h" (which in turn includes "config.h" for you). sysdep.h provides some definitions for the system that might be missing some features, like: #if !HAVE_DECL_FFS extern int ffs (int); #endif So, my first suggestion is to replace all includes of "config.h" by includes of "sysdep.h". Or rather, I'd create a file similar to GDB's defs.h, and add a rule that every file should include that file first. I'm copying Mike for guidance. Right now, there are exactly 100 files that include "config.h", for 8 files that include sysdep.h. I am also wondering why BFD has this requirement at all. Looking at the code, there wouldn't be any harm that I could think of if config.h was included first, and then sysdep.h, since the first thing sysdep.h does is include config.h. And if someone includes sysdep.h first, and then config.h, the second include will be a noop. Perhaps we should ask the binutils folks as well? Or maybe I should do some archeology, but I am running out of time for today. -- Joel