After reading your response and thinking about this problem a bit longer, I've come up with two other possible workarounds if the #include_next solution doesn't work.
Solution 1. Create a subdirectory called something like "bridges". For each stdc++ header that you need to include, create a bridge header in this subdirectory whose name is _not_ the same as the name of the original header. It might look something like this:
File <boost/tr1/iostream>:
#include <boost/tr1/bridges/iostream-bridge.hpp>
File <boost/tr1/bridges/iostream-bridge.hpp>:
#include <iostream>
I _think_ that the #include in the bridge header will reliably locate the original stdc++ <iostream> header, since there is no file named "iostream" in the current directory and the bridges directory is not on the search path.
No because we do have a Boost file called <iostream> in the include path, it's getting from there to the real <iostream> that's the hard part :-( This does put in mind another possible solution though.. but it'll need a more or less complete rewrite of the forwarding code, so it'll have to wait for now.
Solution 2. Include some stdc++ header that is _not_ being redefined, and then use the value of __GLIBCXX__ to determine the path to the other headers.
#if defined(__GLIBCXX__) #if __GLIBCXX__ == 20050421 #include <c++/4.0.0/iostream> #elif __GLIBCXX__ > 20050421 #include <c++/4.2.1/iostream> #else #error Unknown version of the GCC stdc++ library #endif #endif
That might work, I'll give it a try.
I certainly don't recommend this since it is so fragile, but a solution like this might work if nothing else does. Let me know if you choose to go this route and I'll try to come up with the possible values of __GLIBCXX__ for you and the corresponding paths.
I think as long as we know the __GLIBCXX__ versions for which the path is "4.0.0", that should be enough, as the case where libstdc++ is correctly tied to the compiler version is already handled.
I'd also be happy to do a few test builds for you once you think you've come up with a solution, since we do have a vested interest in this working correctly. ;)
Can you try running the tests in Trunk now? There will be some failures from the *tricky.cpp tests, but the others should all pass. Thanks, John.