Subject: Re: [boost] [tr1] Help needed with Darwin port
From: John Maddock (john_at_[hidden])
Date: 2009-01-14 11:49:14
> 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
> 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>
> #error Unknown version of the GCC stdc++ library
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk