Re: [boost] [TR1] sun problems, OSVL4-V2

From: Simon Atanasyan (Simon.Atanasyan_at_[hidden])
Date: 2006-08-22 04:50:32

Vladimir Prus wrote:
> John,
> you reported previously that some TR1 tests fail on sun, which you suspected
> to be V2 issue.
> 
> You said, specifically:
> 
>     A typical list of errors here: http://tinyurl.com/pcwf5 suggests that
>     the "real" version of <memory> is getting included rather than the Tr1
>     version. The command line shows that the TR1 headers are in the path,
>     but *after* the Boost include path, and while I'm not completely sure, I
>     believe this is the problem 
> 
> On closer look, I think I don't understand what's going on. The "real"
> <memory> is in "standard" include directories, and that "standard" include
> directory is not present in command line at all. Even though boost include
> directory is present before TR1 include directory, I see no way how this
> can cause system <memory> to be preferred to TR1's <memory>. Could it be
> that the problem is somewhat more contrived? 

Vladimir,
here is a quote from my previous mail with explanation of the Sun compiler
behavior in that case.

 >> The root of this problem is a surprise for me. Actually to include
 >> <memory> Sun C++ searches file named memory.SUNWCCh. This file is a
 >> symbolic link to "memory". Please don't ask me to explain the
 >> rationale of this "feature"  :-)  So you can create symbolic links in
 >> the tr1
 >> folder like memory.SUNWCCh -> memory. It should help. Meanwhile, I
 >> will try to persuade my co-workers to implement command line option
 >> to turn off this feature.

So even if you specify the only -I option with full path to Boost <memory>
Sun C++ compiler find system <memory> first.

--
Simon