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

[skunk at iskunk dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=14072

--- 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:

g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\"
-DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\"
-DPACKAGE=\"sidcomp\" -DVERSION=\"0.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
-DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
-DHAVE_DLFCN_H=1 -I. -I$(srcdir)/sid/component/cgen-cpu/xstormy16
-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
.libs/xstormy16.o
In file included from
$(srcdir)/sid/component/cgen-cpu/xstormy16/xstormy16.cxx:8:0:
../../../../bfd/config.h:267:0: warning: "PACKAGE" redefined [enabled by
default]
<command-line>:0:0: note: this is the location of the previous definition
../../../../bfd/config.h:358:0: warning: "VERSION" redefined [enabled by
default]
<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.