From: Markus Schöpflin (markus.schoepflin_at_[hidden])
Date: 2005-06-17 09:45:55
Markus Schöpflin wrote:
> Ralf W. Grosse-Kunstleve wrote:
>>If you want to find out exactly what I am doing go to
>>and copy the source bundle including Python into a new empty directory on your
>>Tru64 machine. Then simply run
>> perl cctbx_python_241_bundle.selfx
>>and watch the cxx commands fly by.
> Ok, I did this and yes, it works. And the essential difference is...
> -I/usr/include !!!
> boost.build somehow thinks it necessary to include this path in the
> compiler command line and this makes things break.
Ralf, either you're a genious or it's pure coincidence that you are not hit
by the bug in the iotraits header file. :-)
To summarize, this only compiles on Tru64 if /usr/include is not in the
include path. For this to be the case, it must not be specified on the
command line and the pure_cname compiler option must be in effect.
To quote from the cxx man page:
> [Tru64] When used in conjunction with the <cname> headers, -pure_cname
> defines C names in namespace std only as specified by the C++ Interna-
> tional Standard. When used with cname.h or <cname> headers,
> -nopure_cname defines C names in namespace std and at global namespace
> scope. The -pure_cname option is enabled by default when you specify
> the -std strict_ansi and -std strict_ansi_errors options. The
> -pure_cname option also defines the __PURE_CNAME macro.
This is pretty bad because quite a few boost libraries depend on more than
only the C names as specified in the standard. (thread and fs at least,
IIRC, but I think there are more)
So I think there is no general solution to make this work for Tru64. I
could try and remove the -nopure_cname from the compiler command line and
see which libraries fail after that, but I have to admit I'm not too
hopeful that this will lead us anywhere.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk