Before getting to any detailed discussion on this, I want to make a few facts clear: - I am not adverse to moving the config.h include position on implacable principle. - I am not adverse to carefully considering your suggested fix. - A change will require several hours of testing to land on trunk. - I am not yet convinced that moving where config.h is included is the best fix. - Any change will have to be done very carefully and pass muster before other project developers. A reasoned defense may be necessary. - I appreciate your effort to investigate this and diagnosis. The reason I am unconvinced is that, generally, we<sup><b>1</b></sup> like headers to not interfere with each other, to be include-order independent, and if one is dependent on another, that they perform such includes as they need for themselves. I see this as particularly important for commonly used library code. If bringing the generated config.h and other non-system headers to that likable state will cure your problem, (regardless of what precisely led to it), that is going to be my preferred fix. (I am open to reasons to not so prefer.) If the conflicting headers cannot be made include-order independent, I want to understand why before reverting to the "pragmatic"<sup><b>2</b></sup> remedy of reordering includes. It would help me better see the larger context to understand what you did to a generated config.h that made its include ranking important. I will want to understand the breakage you induced in detail to help pinpoint where the header conflict is occurring. (IOW, I want repro.) I am open to the proposition, (and hold it personally), that a config.h file is a good place to put local feature configuration definitions. So I am disinclined to say anything like, "Just don't modify config.h". Hence, I am interested in solving your problem because I doubt it is one unique to you. (You may be unique in bringing the problem here, but that is fine!) So, I am asking for a little help, (repro mainly), so that I can know what is the best fix and can defend it if called upon to do so.<sup><b>3</b></sup> ---- <b>1.</b> By "we", I mean software developers generally. <b>2.</b> Dogmatism and adherence to good practice must sometimes be distinguished. <b>3.</b> In fact, I do not make changes without believing I can defend them.