Boost logo

Boost :

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 !!!
> 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:

> -[no]pure_cname
> [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, gregod at, cpdaniel at, john at