------- Comment #7 from rob1weld at aol dot com 2007-07-10 04:55 ------- >------- Comment #3 From Paolo Carlini 2007-07-09 08:43 [reply] ------- >Note that in 4.3 the header dependencies have been streamlined and it's well >possible that some projects around are failing to include required headers. >Please double check in this light, thanks.
In _some_ cases that is true "some projects around are failing to include required headers". In _other_ cases the problem is that GCC 4.3 has re-ordered the resulting inclusion sequence by not "polluting" (if that is how you feel about it) some files with _assumed_ excess header files. The lack of these _assumed_ excess header files early in the resulting ".ii" file is causing the undefined errors. Since the "new" GCC 4.3 headers are 'light' (no extra baggage) the include _may_ get used later (in _some_ cases a 'popular' include (like types.h) is _bound_ to be included, in many cases). Since all correctly written .h (or .hpp) files use [ "#ifndef XXXXX_H" "#define XXXXX_H" "Eendif" ] to surround themselves (and avoid being included twice) in the case of removing "sys/types.h" (and likely a couple of others) we have a situation that causes breakage rather than actually lightening the resulting .h (or .hpp) file. It would make the resulting object file no smaller either. Here is an example: I compiled the files using -save-temps and renamed the ".ii" files by GCC version. Here is a comparison of the files produced by GCC 4.1 and GCC 4.3: In file OAInterface_4.1.ii we have this: /* Line 5955 */ # 1 "/usr/include/sys/types.h" 1 3 4 /* Line 6022 */ typedef unsigned short int ushort; /* Line 39661 */ ushort insnSize; In file OAInterface_4.3.ii we have this: /* Line 28636 */ ushort insnSize; /* Line 33996 */ # 1 "/usr/include/sys/types.h" 1 3 4 /* Line 34063 */ typedef unsigned short int ushort; Notice that the file "/usr/include/sys/types.h" has it's line number ONE on line number 5955 using version 4.1, but it is on line 33996 using 4.3 ! The omission of "/usr/include/sys/types.h" from one of the includes in 4.3 (where it was present in 4.1) means that it eventually gets picked up by a later include file (in 4.3) and appears too late (after it is neccesary). This means that source code that worked previously with 4.1 (or older) will need their local source include files line numbers permutated to occur after the inclusion of what GCC 4.3 _might_ define in a particular include file and prior to what any later includes _might_ need defined by that particular local include. Simply placing the local includes last in the list of all included files (at the top of the source file, assuming that "#include" does not occur later in the file (like it sometimes does in GCC)) will not always work since the include files sometimes use defines that activate features used in later includes. That is a "travelling salesman" problem _BUT_ in addition you need to know how to alter each "salesman's" wares (not part of the clasical "TS" problem). That means it is very time consuming; in case what I am saying is unclear. I don't use C++ much (and know how to fix this) so one of you is welcome to "Reopen bug" or "Leave as RESOLVED INVALID" - since I did not change the setting. I thank you both and appreciate your expert advice on this matter. If this is how C++ is "really supposed to be" then it is technically correct to leave this and let the world deal with it's problem. I'm not working the tech support lines. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32683
