Subject: Re: [boost] [tr1] Help needed with Darwin port
From: Stuart A. Malone (samalone_at_[hidden])
Date: 2009-01-13 12:50:17
On Jan 13, 2009, at 11:46 AM, John Maddock wrote:
> * Do people commonly install Boost into a system path such as /usr/
> include or /usr/local/include ?
I don't know about others, but my own Boost headers are currently
installed in /usr/local/include/boost-1_37, which I explicitly add to
the system header search path using the -I option to gcc in my project
Before that, I had them checked into my Subversion repository so that
each version of my project was paired with the version of Boost used
to build it. Under that scheme, there was no version of Boost
"installed" at all, just local copies used for particular projects.
I don't think you can assume that any particular relative path will
get you reliably from a Boost header file to a system header file.
> * Is it possible to detect the Darwin version number (to separate
> 10.0 from 9.x)?
A quick find/grep through the system headers did not come up with
I would not attempt to detect the version using a shell variable like
OSTYPE, though, since that would presumably detect the version of
Darwin that you are running on, not the version that you are compiling
for. It's possible to have multiple versions of Apple's developer
tools installed, and each one of them can support SDKs from older
systems, so the version of Darwin that's running would not be a
reliable indicator of where the stdc++ headers are stored.
> * Do you know what happens if someone installs gcc from source (ie
> not from Apples developer tools)?
It's been some time since I've done this, but my recollection is that
by default, the stdc++ headers that come with gcc get installed into a
deep, deep subdirectory of /usr/local whose location is known only to
gcc. This is done so you have have multiple versions of gcc and stdc+
+ installed simultaneously.
I think that perhaps there's another way out of this situation.
I'm assuming that the reason you can't simply #include <iostream> is
that you are defining a header whose name is also <iostream>, and
attempting to include the stdc++ version of the header simply leads to
I believe that gcc has a non-standard extension called #include_next
that is designed to handle exactly this situation. It includes
another file, but searches for it _only_ in the directories that come
later in the search path than the current directory. You can read
more about it at:
It appears that this feature has been part of gcc since at least 4.0,
so you should be able to detect that version of gcc and then use that
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk