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. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
