[TR1] sun problems, OSVL4-V2
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? Doug, as a quick check, can you try running the same command that fails, but with the order of -I".." and -I"/home/user1/dgregor/BoostRegressionTesting/boost/boost/tr1/tr1" reversed? If that works, can you run the failing command with -save-temps, and send me the .ii file? Thanks, Volodya
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
Vladimir Prus wrote:
can cause system <memory> to be preferred to TR1's <memory>. Could it be that the problem is somewhat more contrived?
Apologies I should have mailed you an update about this: while I have seen issues like that in testing that were caused by include path ordering problems, in this case Simon Atanasyan has already come to the rescue and the issue does appear to be fixed in cvs. I don't remember the exact circumstances where I had a header ordering problem now, but I think it was to do with gcc's #include_next not finding what it needed to if the paths were in the wrong order. Certainly during early testing of the lib, most unexplained problems were caused by ordering problems, but since diagnosing the exact cause requires detailed examination of megabytes worth of preprocessed output, I didn't attempt it unless there was really no other way! For now this appears to be a non-issue for bbv2 then: but, I note that in most of the toolsets being tested it just so happens "by chance" that the includes are in the right order (they appear to be sorted by name????), the sunpro toolset was a noteable exception, hence my suspision in this case. Hopefully that clarifies where we are now, Many thanks, John.
participants (3)
-
John Maddock -
Simon Atanasyan -
Vladimir Prus