Hi guys, among the various Sun CC failures that permeate our regression tests there's one which seems quite straightforward to fix (so it probably isn't :-)): the compiler claims ambiguity between test_tools::tt_detail::print_helper<char[1]> (const char(&)[1]) test_tools::tt_detail::print_helper<const char, 1>(const char(&)[1]) in "boost/test/test_tools.hpp". AFAICT, that's correct and we should fix the code between lines 377 and 389. -- [ Gennaro Prota, C++ developer for hire ]
About the segmentation faults (signal 11) it might be worth digging a bit into the Sun database. I found this: <http://sunsolve.sun.com/search/advsearch.do?collection=PATCH&type=collections&max=50&queryKey5=111715&toDocument=yes> (or <http://tinyurl.com/l6x3n>) but this is search is better done by someone who has access to the compiler, of course. -- [ Gennaro Prota, C++ developer for hire ]
On Sun, 23 Jul 2006 21:37:03 +0200, Gennaro Prota <gennaro_prota@yahoo.com> wrote:
Hi guys,
among the various Sun CC failures that permeate our regression tests there's one which seems quite straightforward to fix [...]
Another easy one: in "../boost/iostreams/char_traits.hpp", line 40 and others: wint_t is not defined. The file char_traits.hpp tries bringing that name into std twice: first via the BOOST_NO_STDC_NAMESPACE and then via an ad-hoc #if (which should actually use BOOST_WORKAROUND). Now I'm not sure whether we should define BOOST_NO_STDC_NAMESPACE when __SUNPRO_CC == 0x580 (probably not, as the problem might only exist for rarely used names such as wint_t) or add to the second #if. In both cases that's another easy fix. PS: if config/compiler/sunpro_cc.hpp is modified, please seize the occasion to correct the last comment in the file: // last known and checked version is 0x570: <-- #if (__SUNPRO_CC > 0x580) <-- <...> #endif -- [ Gennaro Prota, C++ developer for hire ]
Gennaro Prota wrote:
On Sun, 23 Jul 2006 21:37:03 +0200, Gennaro Prota <gennaro_prota@yahoo.com> wrote:
Hi guys,
among the various Sun CC failures that permeate our regression tests there's one which seems quite straightforward to fix [...]
Another easy one:
in "../boost/iostreams/char_traits.hpp", line 40 and others: wint_t is not defined. The file char_traits.hpp tries bringing that name into std twice: first via the BOOST_NO_STDC_NAMESPACE and then via an ad-hoc #if (which should actually use BOOST_WORKAROUND).
I'll have to check this but I think some of the changes that Simon Atanasyan from SUN made and published in his blog address this. It's a tad late in the day for me to check but it may well be that I've got a patch for that which I'm preparing...
Now I'm not sure whether we should define BOOST_NO_STDC_NAMESPACE when __SUNPRO_CC == 0x580 (probably not, as the problem might only exist for rarely used names such as wint_t) or add to the second #if. In both cases that's another easy fix.
I don't think we should as the compiler in general is fairly standard compliant. However SUN mainly supports the configuration of this compiler + STLport. If you don't use that configuration you may be seeing some really odd things happening. Regards, Timo
On Sun, 23 Jul 2006 23:16:50 +0100, Timo Geusch <timo@unix-consult.com> wrote:
I'll have to check this but I think some of the changes that Simon Atanasyan from SUN made and published in his blog address this.
Thanks for pointing me there :-) Yes, some problems are addressed, and are in fact supposed to be fixed since boost 1.33.1: <http://blogs.sun.com/roller/resources/sga/boost_1_33_1.patch> Why they aren't is beyond me (I guess Simon posted his patch(es) here, otherwise the answer is obvious)
It's a tad late in the day for me
It's 1 am here, too :-)
to check but it may well be that I've got a patch for that which I'm preparing...
Do you mean Simon has privately sent them to you? Well, I'll do some changes to the RC 1.34 branch now, so that we can perhaps see the effects within tomorrow. Thanks again for the tip :-) -- [ Gennaro Prota, C++ developer for hire ]
Gennaro Prota wrote:
On Sun, 23 Jul 2006 23:16:50 +0100, Timo Geusch <timo@unix-consult.com> wrote:
I'll have to check this but I think some of the changes that Simon Atanasyan from SUN made and published in his blog address this.
Thanks for pointing me there :-) Yes, some problems are addressed, and are in fact supposed to be fixed since boost 1.33.1:
<http://blogs.sun.com/roller/resources/sga/boost_1_33_1.patch>
Why they aren't is beyond me (I guess Simon posted his patch(es) here, otherwise the answer is obvious)
I think he only posted them to his blog and no-one had the time to integrate them. SUN compiler support wasn't that high on the agenda and only very few people (including myself) had access to the SUN compilers, and not necessarily the latest versions either. Not to mention that the older compilers are a tad quirky..
to check but it may well be that I've got a patch for that which I'm preparing...
Do you mean Simon has privately sent them to you? Well, I'll do some changes to the RC 1.34 branch now, so that we can perhaps see the effects within tomorrow. Thanks again for the tip :-)
Nah, I'm trying to port his patches to 1.34 RC in what little spare time I have.. At the moment I'm concentrating on getting Boost.Python to compile (he hasn't got any patches for that) but I'm kinda waiting until I'm back from holiday to continue that as the latest patch set for the compiler should be available by then. This supposedly fixes another lot of compilation issues. I'm lazy :-) and I'm happy to wait that long..
On Tue, 25 Jul 2006 06:45:41 +0100, Timo Geusch <timo@unix-consult.com> wrote:
I think he only posted them to his blog and no-one had the time to integrate them.
I didn't even know such a blog existed.
At the moment I'm concentrating on getting Boost.Python to compile (he hasn't got any patches for that) but I'm kinda waiting until I'm back from holiday to continue that as the latest patch set for the compiler should be available by then. This supposedly fixes another lot of compilation issues. I'm lazy :-) and I'm happy to wait that long..
In the meantime I applied some fixes without having access to the compiler. Some were committed too late for appearing in yesterday's regression mail. The rest of them worked, and today we should have the full picture. -- [ Gennaro Prota, C++ developer for hire ]
On Mon, Jul 24, 2006 at 12:58:11AM +0200, Gennaro Prota wrote:
On Sun, 23 Jul 2006 23:16:50 +0100, Timo Geusch <timo@unix-consult.com> wrote:
I'll have to check this but I think some of the changes that Simon Atanasyan from SUN made and published in his blog address this.
Thanks for pointing me there :-) Yes, some problems are addressed, and are in fact supposed to be fixed since boost 1.33.1:
<http://blogs.sun.com/roller/resources/sga/boost_1_33_1.patch>
Why they aren't is beyond me (I guess Simon posted his patch(es) here, otherwise the answer is obvious)
The above patch will tie you to -library=stlport4 though. The boost mini howto on the same blog, http://blogs.sun.com/roller/page/sga?entry=boost_mini_howto, says you need to build programs linking against boost with: -library=stlport4 -features=tmplife -features=tmplrefstatic I suppose this means if your boost program links against any 3rd-party libraries, they must be compiled with the above as well. Is stlport4 "better" than Cstd? -- albert chin (china@thewrittenword.com)
Albert Chin wrote:
On Mon, Jul 24, 2006 at 12:58:11AM +0200, Gennaro Prota wrote:
On Sun, 23 Jul 2006 23:16:50 +0100, Timo Geusch <timo@unix-consult.com> wrote:
I'll have to check this but I think some of the changes that Simon Atanasyan from SUN made and published in his blog address this. Thanks for pointing me there :-) Yes, some problems are addressed, and are in fact supposed to be fixed since boost 1.33.1:
<http://blogs.sun.com/roller/resources/sga/boost_1_33_1.patch>
Why they aren't is beyond me (I guess Simon posted his patch(es) here, otherwise the answer is obvious)
The above patch will tie you to -library=stlport4 though. The boost mini howto on the same blog, http://blogs.sun.com/roller/page/sga?entry=boost_mini_howto, says you need to build programs linking against boost with: -library=stlport4 -features=tmplife -features=tmplrefstatic
I suppose this means if your boost program links against any 3rd-party libraries, they must be compiled with the above as well.
Is stlport4 "better" than Cstd?
Cstd is an old implementation. It does not conforms to standard. And it will never conforms because we (Sun) need to maintains binary compatibility with old releases. Stlport is closer to standard and contains some features necessary for Boost. -- Simon Atanasyan
On Thu, 27 Jul 2006 08:11:21 +0400, Simon Atanasyan <Simon.Atanasyan@Sun.COM> wrote:
The above patch will tie you to -library=stlport4 though.
Well, I didn't apply the patch, actually. I just took inspiration (so to speak) from it, inferring what the problem was. The changes I've made to the boost code shouldn't in themselves tie it to any library.
Cstd is an old implementation. It does not conforms to standard. And it will never conforms because we (Sun) need to maintains binary compatibility with old releases. Stlport is closer to standard and contains some features necessary for Boost.
Hi Simon, nice to hear from you directly :-) It would be great if you could join us or, if you just can't, to inform us of any patch you might release against boost sources. It happens sometimes that those who have access to the compiler (and thus likely know about your blog) are too busy to deal with boost regressions and vice versa. In both cases, I guess collaboration will help everyone here, so please consider this an explicit invitation :-) -- [ Gennaro Prota, C++ developer for hire ]
Gennaro Prota wrote:
Hi Simon, nice to hear from you directly :-) It would be great if you could join us or, if you just can't, to inform us of any patch you might release against boost sources. It happens sometimes that those who have access to the compiler (and thus likely know about your blog) are too busy to deal with boost regressions and vice versa. In both cases, I guess collaboration will help everyone here, so please consider this an explicit invitation :-)
Hi, I have some tasks aren't related to Boost now. But I will switch to Boost in a couple weeks or so. I plan to compile Boost 1.34 and development version by Sun Studio Express (http://developers.sun.com/prodtech/cc/downloads/express.jsp) and by Sun Studio 11. If you or anybody else have a questions like 'Is it a bug in Sun C++?' or 'Is it a known bug and when this annoyed big will be fixed?' fill free to ask me directly :-) -- Simon
Simon Atanasyan wrote:
If you or anybody else have a questions like 'Is it a bug in Sun C++?' or 'Is it a known bug and when this annoyed big will be fixed?' fill free to ask me directly :-)
Well in that case :-) If you have a chance to look at the TR1 library failures that would be a big help. Almost all the failures all appear to be caused by the appropriate header files not getting included. The situation here is somewhat different to normal, because we're trying to replace existing std lib header files, so that #include <memory> includes the Boost.TR1 version of <memory> which forwards on the real version as well as including it's own extra parts. However, for some reason the Boost versions of these headers appear not to be being picked up. Any ideas? Many thanks, John Maddock.
John Maddock wrote:
If you have a chance to look at the TR1 library failures that would be a big help. Almost all the failures all appear to be caused by the appropriate header files not getting included. The situation here is somewhat different to normal, because we're trying to replace existing std lib header files, so that
#include <memory>
includes the Boost.TR1 version of <memory> which forwards on the real version as well as including it's own extra parts. However, for some reason the Boost versions of these headers appear not to be being picked up.
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. -- Simon
Simon Atanasyan wrote:
includes the Boost.TR1 version of <memory> which forwards on the real version as well as including it's own extra parts. However, for some reason the Boost versions of these headers appear not to be being picked up.
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.
Ouch, you haven't been stealing Borland's old design team have you? Seems to be the same philosophy at work :-) Anyway many thanks for the explanation, I'll get that fixed. John.
Simon Atanasyan wrote:
John Maddock wrote:
includes the Boost.TR1 version of <memory> which forwards on the real version as well as including it's own extra parts. However, for some reason the Boost versions of these headers appear not to be being picked up.
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.
It turns out this is harder for us to fix than I imagined: up until now we have had a prohibition on symbolic links in cvs for the obvious portability reasons. We also require all_lower_case filenames for the same reason. I note that STLport seems to get around this without resorting to these names, but I can't see how, any ideas? Or is this a recent compiler feature? Thanks again, John.
John Maddock wrote:
Simon Atanasyan wrote:
John Maddock wrote:
includes the Boost.TR1 version of <memory> which forwards on the real version as well as including it's own extra parts. However, for some reason the Boost versions of these headers appear not to be being picked up. 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.
It turns out this is harder for us to fix than I imagined: up until now we have had a prohibition on symbolic links in cvs for the obvious portability reasons. We also require all_lower_case filenames for the same reason. I note that STLport seems to get around this without resorting to these names, but I can't see how, any ideas? Or is this a recent compiler feature?
It's old compiler feature. I suggest to create a shell script to create necessary symlinks. User will be able to run it by hand. And Jamfile used to run Boost test suite will able to run this script too. I know this is quite ugly workaround. -- Simon
On Mon, 07 Aug 2006 18:22:29 +0400, Simon Atanasyan <Simon.Atanasyan@Sun.COM> wrote:
If you or anybody else have a questions like 'Is it a bug in Sun C++?' or 'Is it a known bug and when this annoyed big will be fixed?' fill free to ask me directly :-)
Perhaps you meant "asking by mail", but since you replied to John here I'm first making an attempt on the list. It would be nice if you had a look at the signal 11 failures (really a lot of them). Maybe they have the same origin. -- [ Gennaro Prota, C++ developer for hire ]
Gennaro Prota wrote:
On Mon, 07 Aug 2006 18:22:29 +0400, Simon Atanasyan <Simon.Atanasyan@Sun.COM> wrote:
If you or anybody else have a questions like 'Is it a bug in Sun C++?' or 'Is it a known bug and when this annoyed big will be fixed?' fill free to ask me directly :-)
Perhaps you meant "asking by mail", but since you replied to John here I'm first making an attempt on the list. It would be nice if you had a look at the signal 11 failures (really a lot of them). Maybe they have the same origin.
Yes, I meant "asking by mail". Could you show command line to reproduce signal 11 failures? Right now I do not have a time to run full Boost test suite. So example speeds up my investigation a bit. -- Simon
On Thu, Jul 27, 2006 at 08:11:21AM +0400, Simon Atanasyan wrote:
Albert Chin wrote:
Is stlport4 "better" than Cstd?
Cstd is an old implementation. It does not conforms to standard. And it will never conforms because we (Sun) need to maintains binary compatibility with old releases. Stlport is closer to standard and contains some features necessary for Boost.
Doesn't using stlport4 require an installation of the Sun C++ compiler installed for access to libstlport.so? -- albert chin (china@thewrittenword.com)
On Thu, Jul 27, 2006 at 10:36:59AM -0500, Albert Chin wrote:
On Thu, Jul 27, 2006 at 08:11:21AM +0400, Simon Atanasyan wrote:
Albert Chin wrote:
Is stlport4 "better" than Cstd?
Cstd is an old implementation. It does not conforms to standard. And it will never conforms because we (Sun) need to maintains binary compatibility with old releases. Stlport is closer to standard and contains some features necessary for Boost.
Doesn't using stlport4 require an installation of the Sun C++ compiler installed for access to libstlport.so?
Never mind. I see that Sun allows free redistribution of libstlport.so. -- albert chin (china@thewrittenword.com)
Albert Chin skrev:
On Thu, Jul 27, 2006 at 08:11:21AM +0400, Simon Atanasyan wrote:
Albert Chin wrote:
Is stlport4 "better" than Cstd?
Cstd is an old implementation. It does not conforms to standard. And it will never conforms because we (Sun) need to maintains binary compatibility with old releases. Stlport is closer to standard and contains some features necessary for Boost.
Doesn't using stlport4 require an installation of the Sun C++ compiler installed for access to libstlport.so? -library=stlport4 tell the Sun C++ (pre)compiler and linker to use the stlport lib that ship and installs with the standard install, but it is not used as default. Hope that answers your question.
Bjørn
On Thu, Jul 27, 2006 at 06:01:08PM +0200, BjXrn_Roald wrote:
Albert Chin skrev:
On Thu, Jul 27, 2006 at 08:11:21AM +0400, Simon Atanasyan wrote:
Albert Chin wrote:
Is stlport4 "better" than Cstd?
Cstd is an old implementation. It does not conforms to standard. And it will never conforms because we (Sun) need to maintains binary compatibility with old releases. Stlport is closer to standard and contains some features necessary for Boost.
Doesn't using stlport4 require an installation of the Sun C++ compiler installed for access to libstlport.so?
-library=stlport4 tell the Sun C++ (pre)compiler and linker to use the stlport lib that ship and installs with the standard install, but it is not used as default. Hope that answers your question.
Huh? It adds a DT_NEEDED entry to the executable/library for libstlport.so.1. -- albert chin (china@thewrittenword.com)
On Sun, 23 Jul 2006 21:37:03 +0200, Gennaro Prota <gennaro_prota@yahoo.com> wrote:
AFAICT, that's correct
Well, thanks to all those who refrained to reply and let myself realize my own stupidity :-( I've changed #if BOOST_WORKAROUND(__SUNPRO_CC, BOOST_TESTED_AT(0x530)) to #if BOOST_WORKAROUND(__SUNPRO_CC, < 0x580) so that we can see the effect. Eventually the comparison should then be <= 0x530 or < 0x570. -- [ Gennaro Prota, C++ developer for hire ]
participants (6)
-
Albert Chin -
Bjørn Roald -
Gennaro Prota -
John Maddock -
Simon Atanasyan -
Timo Geusch