[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug binutils/14072] Incorrect handling of config.h and/or sysdep.h caus

From: skunk at iskunk dot org
Subject: [Bug binutils/14072] Incorrect handling of config.h and/or sysdep.h causing problems
Date: Wed, 16 May 2012 17:59:55 +0000


--- Comment #2 from Daniel Richard G. <skunk at iskunk dot org> 2012-05-16 
17:59:55 UTC ---
The thought is that __GLIBC__ catches system headers in what is presumably the
main development environment, GNU/Linux. It doesn't really need to work on
other systems to be useful, because as long as config.h is the first thing seen
on Linux, the same should hold true on other systems (given no changes in the
source, and the absence of funky cpp conditionals that early on).

Even if someone hacks on binutils in a non-Linux environment, any issues with
the #includes should become apparent once some other developer builds on Linux.

Enabling this only in maintainer mode would be sensible; I left that out
because you would need to do this via e.g. "#ifdef MAINTAINER_MODE" in the
AH_VERBATIM (note that the AH_VERBATIM itself can't be conditionalized), so
then you'd need to conditionally AC_DEFINE(MAINTAINER_MODE)... it just seemed
like more trouble than it was worth. I don't see that this should ever trip
erroneously out in the wild, barring a user setting CPPFLAGS=-D__GLIBC__ or the
like for some odd reason.

I have to walk back my comments on config.h being #included twice---what I had
actually seen in my build of the CVS source was this:

-DHAVE_DLFCN_H=1 -I. -I$(srcdir)/sid/component/cgen-cpu/xstormy16
-I$(srcdir)/sid/component/cgen-cpu/xstormy16/.. -I../../../include
-I$(srcdir)/sid/component/cgen-cpu/xstormy16/../../../include -I../../../../bfd
-I$(srcdir)/sid/component/cgen-cpu/xstormy16/../../../../include -g -O2 -MT
xstormy16.lo -MD -MP -MF .deps/xstormy16.Tpo -c
$(srcdir)/sid/component/cgen-cpu/xstormy16/xstormy16.cxx  -fPIC -DPIC -o
In file included from
../../../../bfd/config.h:267:0: warning: "PACKAGE" redefined [enabled by
<command-line>:0:0: note: this is the location of the previous definition
../../../../bfd/config.h:358:0: warning: "VERSION" redefined [enabled by
<command-line>:0:0: note: this is the location of the previous definition

It's actually a clash between a project that doesn't use config.h and one that
does, and that in a section of the binutils tree that isn't binutils proper. My
bad :]

The reason I didn't add any logic detecting double-#inclusion, at any rate, was
that you'd already get copious warnings from that, and it's not likely to be a
build-breaker on exotic platforms in the way the other header snafus have been.

Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]