[scope_exit] trunk tests fail on sun compiler
Hello all, I'm trying to get ScopeExit to work on Sun. 1) First it looked like all tests fail on this compiler: http://www.boost.org/development/tests/trunk/developer/scope_exit.html 2) However, I installed Solaris Studio 12.3 on my Ubuntu 10 and it seems that I can compile ScopeExit just fine with the following" $ CC -I /usr/include/i386-linux-gnu/ -I ../../.. -DBOOST_TYPEOF_EMULATION world_seq.cpp Note that: a) Sun does not support variadic macros so only ScopeExit sequence syntax will work. b) Sun does not support native type-of so BOOST_TYPEOF_EMULATION needs to be defined. Therefore, all original ScopeExit type-of emulation tests named `emulation_...` should compile (because they use the sequence syntax and define BOOST_TYPEOF_EMULATION). However, they fail... why? 3) Why when I click on the "fail" link for these tests I get no information on the Sun compiler's output? For example: http://www.boost.org/development/tests/trunk/developer/output/Sandia-sun-boo... If I follow this link I get "Error extracting file: No matching files were found.". What does this mean? Thanks a lot! --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-scope-exit-trunk-tests-fail-on-sun-... Sent from the Boost - Dev mailing list archive at Nabble.com.
AMDG On 03/24/2012 08:54 AM, lcaminiti wrote:
3) Why when I click on the "fail" link for these tests I get no information on the Sun compiler's output?
For example: http://www.boost.org/development/tests/trunk/developer/output/Sandia-sun-boo...
It looks like the Boost.Test library failed to build.
If I follow this link I get "Error extracting file: No matching files were found.". What does this mean?
This is an error from the server, not an error from the regression test run. In Christ, Steven Watanabe
On Sat, Mar 24, 2012 at 12:27 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
On 03/24/2012 08:54 AM, lcaminiti wrote:
3) Why when I click on the "fail" link for these tests I get no information on the Sun compiler's output?
For example: http://www.boost.org/development/tests/trunk/developer/output/Sandia-sun-boo...
It looks like the Boost.Test library failed to build.
Actually, now that you mentioned it, it looks like a lot of Boost.Test regressions fail on the Sun platform... http://www.boost.org/development/tests/trunk/developer/test.html Is this Sun platform supported on not by Boost? (How can my library tests pass IF the tester library doesn't work on a platform?!)
If I follow this link I get "Error extracting file: No matching files were found.". What does this mean?
This is an error from the server, not an error from the regression test run.
Can the Sun platform maintainer (Noel Belcourt?) please send me more detail on the failure messages? Unfortunately, at this point I can't confirm if the failure is in the Sun platform/toolset, Boost.Test, or Boost.ScopeExit? Thanks a lot :) --Lorenzo
On Mar 25, 2012, at 2:54 PM, Lorenzo Caminiti wrote:
On Sat, Mar 24, 2012 at 12:27 PM, Steven Watanabe <watanabesj@gmail.com
wrote: AMDG
On 03/24/2012 08:54 AM, lcaminiti wrote:
3) Why when I click on the "fail" link for these tests I get no information on the Sun compiler's output?
For example: http://www.boost.org/development/tests/trunk/developer/output/Sandia-sun-boo...
It looks like the Boost.Test library failed to build.
Actually, now that you mentioned it, it looks like a lot of Boost.Test regressions fail on the Sun platform... http://www.boost.org/development/tests/trunk/developer/test.html
Is this Sun platform supported on not by Boost? (How can my library tests pass IF the tester library doesn't work on a platform?!)
If I follow this link I get "Error extracting file: No matching files were found.". What does this mean?
This is an error from the server, not an error from the regression test run.
Can the Sun platform maintainer (Noel Belcourt?) please send me more detail on the failure messages? Unfortunately, at this point I can't confirm if the failure is in the Sun platform/toolset, Boost.Test, or Boost.ScopeExit?
Hi Lorenzo, Sun is, for all intent and purposes, a dead platform for us. While I realize others may be using newer flavors of it, we've basically stopped and use it only for the numerics which were/are quite good. Our system is not being maintained so I'd guess your best bet is to mark your library as unsupported on this platform. Best. -- Noel Belcourt
Belcourt, K. Noel wrote
Sun is, for all intent and purposes, a dead platform for us. While I realize others may be using newer flavors of it, we've basically stopped and use it only for the numerics which were/are quite good. Our system is not being maintained so I'd guess your best bet is to mark your library as unsupported on this platform.
OK. Shall Sun be removed by the trunk regression tests then? Regards, --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-scope-exit-trunk-tests-fail-on-sun-... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Mar 26, 2012, at 6:31 AM, lcaminiti wrote:
Belcourt, K. Noel wrote
Sun is, for all intent and purposes, a dead platform for us. While I realize others may be using newer flavors of it, we've basically stopped and use it only for the numerics which were/are quite good. Our system is not being maintained so I'd guess your best bet is to mark your library as unsupported on this platform.
Hi Lorenzo,
OK. Shall Sun be removed by the trunk regression tests then?
No, we'll leave the Sandia-Sun tester running as long as we can. Go to the Legend at the bottom of the trunk results page, one of the keys is this: n/a The library author marked it as unusable on particular platform/ toolset. I suggest you mark your library as n/a for the Sandia-Sun tester, as others have done for their libraries, e.g. proto, property_tree, statechart, xpressive, etc... -- Noel
Le 26/03/12 17:39, Belcourt, K. Noel a écrit :
On Mar 26, 2012, at 6:31 AM, lcaminiti wrote:
Belcourt, K. Noel wrote
Sun is, for all intent and purposes, a dead platform for us. While I realize others may be using newer flavors of it, we've basically stopped and use it only for the numerics which were/are quite good. Our system is not being maintained so I'd guess your best bet is to mark your library as unsupported on this platform.
Hi Lorenzo,
OK. Shall Sun be removed by the trunk regression tests then?
No, we'll leave the Sandia-Sun tester running as long as we can. Go to the Legend at the bottom of the trunk results page, one of the keys is this:
n/a The library author marked it as unusable on particular platform/toolset.
I suggest you mark your library as n/a for the Sandia-Sun tester, as others have done for their libraries, e.g. proto, property_tree, statechart, xpressive, etc...
Noel, it is difficult to classify a library as N/A when we don't know what is not working on. I'm wondering if this is not catching a bug on the regression tools. Boost.Thread is on the same case, and I will be interested in changing whatever is needed to make it usable on Sun/Solaris. Please, could you see why the regression tests are not showing why the test fails? Best, Vicente
On Mar 26, 2012, at 11:13 AM, Vicente J. Botet Escriba wrote:
Le 26/03/12 17:39, Belcourt, K. Noel a écrit :
On Mar 26, 2012, at 6:31 AM, lcaminiti wrote:
Belcourt, K. Noel wrote
Sun is, for all intent and purposes, a dead platform for us. While I realize others may be using newer flavors of it, we've basically stopped and use it only for the numerics which were/are quite good. Our system is not being maintained so I'd guess your best bet is to mark your library as unsupported on this platform.
Hi Lorenzo,
OK. Shall Sun be removed by the trunk regression tests then?
No, we'll leave the Sandia-Sun tester running as long as we can. Go to the Legend at the bottom of the trunk results page, one of the keys is this:
n/a The library author marked it as unusable on particular platform/toolset.
I suggest you mark your library as n/a for the Sandia-Sun tester, as others have done for their libraries, e.g. proto, property_tree, statechart, xpressive, etc...
it is difficult to classify a library as N/A when we don't know what is not working on. I'm wondering if this is not catching a bug on the regression tools.
I believe this is the same problem it's been for years, libraries like Thread that depend on Boost.Test won't work right unless Test works right. A quick glance at the Boost.Test results show most of it doesn't work on Sun, that's why Thread and presumably many other libraries don't work on Sun.
Boost.Thread is on the same case, and I will be interested in changing whatever is needed to make it usable on Sun/Solaris.
I only see a couple of option, push on Gennadiy to bring up Test on Sun, or decouple Thread from Test and control your own fate.
Please, could you see why the regression tests are not showing why the test fails
Here's an example. ...skipped <p/scratch2/kbelco/boost/results/boost/bin.v2/libs/thread/ test/condition_variable__default_p.test/sun-5.10/debug/address- model-64/stdlib-sun-stlport/threading- multi>condition_variable__default_p for lack of <p/scratch2/kbelco/ boost/results/boost/bin.v2/libs/test/build/sun-5.10/debug/address- model-64/link-static/stdlib-sun-stlport/threading- multi>libboost_unit_test_framework.a... -- Noel
On Mar 26, 2012, at 11:13 AM, Vicente J. Botet Escriba wrote:
Le 26/03/12 17:39, Belcourt, K. Noel a écrit :
On Mar 26, 2012, at 6:31 AM, lcaminiti wrote:
Belcourt, K. Noel wrote
Sun is, for all intent and purposes, a dead platform for us. While I realize others may be using newer flavors of it, we've basically stopped and use it only for the numerics which were/are quite good. Our system is not being maintained so I'd guess your best bet is to mark your library as unsupported on this platform.
Hi Lorenzo,
OK. Shall Sun be removed by the trunk regression tests then?
No, we'll leave the Sandia-Sun tester running as long as we can. Go to the Legend at the bottom of the trunk results page, one of the keys is this:
n/a The library author marked it as unusable on particular platform/toolset.
I suggest you mark your library as n/a for the Sandia-Sun tester, as others have done for their libraries, e.g. proto, property_tree, statechart, xpressive, etc...
Noel,
it is difficult to classify a library as N/A when we don't know what is not working on. I'm wondering if this is not catching a bug on the regression tools.
Boost.Thread is on the same case, and I will be interested in changing whatever is needed to make it usable on Sun/Solaris.
Please, could you see why the regression tests are not showing why the test fails?
Oh, I should point out that there's about 500 targets that fail to link due to missing Boost.Test libraries. -- Noel
Le 26/03/12 19:30, Belcourt, K. Noel a écrit :
On Mar 26, 2012, at 11:13 AM, Vicente J. Botet Escriba wrote:
Le 26/03/12 17:39, Belcourt, K. Noel a écrit :
On Mar 26, 2012, at 6:31 AM, lcaminiti wrote:
Belcourt, K. Noel wrote
Sun is, for all intent and purposes, a dead platform for us. While I realize others may be using newer flavors of it, we've basically stopped and use it only for the numerics which were/are quite good. Our system is not being maintained so I'd guess your best bet is to mark your library as unsupported on this platform.
Hi Lorenzo,
OK. Shall Sun be removed by the trunk regression tests then?
No, we'll leave the Sandia-Sun tester running as long as we can. Go to the Legend at the bottom of the trunk results page, one of the keys is this:
n/a The library author marked it as unusable on particular platform/toolset.
I suggest you mark your library as n/a for the Sandia-Sun tester, as others have done for their libraries, e.g. proto, property_tree, statechart, xpressive, etc...
Noel,
it is difficult to classify a library as N/A when we don't know what is not working on. I'm wondering if this is not catching a bug on the regression tools.
Boost.Thread is on the same case, and I will be interested in changing whatever is needed to make it usable on Sun/Solaris.
Please, could you see why the regression tests are not showing why the test fails?
Oh, I should point out that there's about 500 targets that fail to link due to missing Boost.Test libraries.
Thanks for the information. The last test I have been adding to Boost.Thread doesn't use Boost.Test, but the link to Boost.Test is done however. I will dissociate it to see if this helps. Thanks again, Vicente
On Mar 27, 2012, at 10:59 AM, Vicente J. Botet Escriba wrote:
Le 26/03/12 19:30, Belcourt, K. Noel a écrit :
On Mar 26, 2012, at 11:13 AM, Vicente J. Botet Escriba wrote:
Le 26/03/12 17:39, Belcourt, K. Noel a écrit :
On Mar 26, 2012, at 6:31 AM, lcaminiti wrote:
Belcourt, K. Noel wrote
Sun is, for all intent and purposes, a dead platform for us. While I realize others may be using newer flavors of it, we've basically stopped and use it only for the numerics which were/are quite good. Our system is not being maintained so I'd guess your best bet is to mark your library as unsupported on this platform.
Hi Lorenzo,
OK. Shall Sun be removed by the trunk regression tests then?
No, we'll leave the Sandia-Sun tester running as long as we can. Go to the Legend at the bottom of the trunk results page, one of the keys is this:
n/a The library author marked it as unusable on particular platform/toolset.
I suggest you mark your library as n/a for the Sandia-Sun tester, as others have done for their libraries, e.g. proto, property_tree, statechart, xpressive, etc...
Noel,
it is difficult to classify a library as N/A when we don't know what is not working on. I'm wondering if this is not catching a bug on the regression tools.
Boost.Thread is on the same case, and I will be interested in changing whatever is needed to make it usable on Sun/Solaris.
Please, could you see why the regression tests are not showing why the test fails?
Oh, I should point out that there's about 500 targets that fail to link due to missing Boost.Test libraries.
Thanks for the information. The last test I have been adding to Boost.Thread doesn't use Boost.Test, but the link to Boost.Test is done however. I will dissociate it to see if this helps.
I'm most interested in hearing if Thread (sans Test) will work on Sun. -- Noel
Le 27/03/12 20:17, Belcourt, K. Noel a écrit :
On Mar 27, 2012, at 10:59 AM, Vicente J. Botet Escriba wrote:
Le 26/03/12 19:30, Belcourt, K. Noel a écrit :
On Mar 26, 2012, at 11:13 AM, Vicente J. Botet Escriba wrote:
Le 26/03/12 17:39, Belcourt, K. Noel a écrit :
On Mar 26, 2012, at 6:31 AM, lcaminiti wrote:
Belcourt, K. Noel wrote > > Sun is, for all intent and purposes, a dead platform for us. > While I > realize others may be using newer flavors of it, we've basically > stopped and use it only for the numerics which were/are quite good. > Our system is not being maintained so I'd guess your best bet is to > mark your library as unsupported on this platform.
Hi Lorenzo,
OK. Shall Sun be removed by the trunk regression tests then?
No, we'll leave the Sandia-Sun tester running as long as we can. Go to the Legend at the bottom of the trunk results page, one of the keys is this:
n/a The library author marked it as unusable on particular platform/toolset.
I suggest you mark your library as n/a for the Sandia-Sun tester, as others have done for their libraries, e.g. proto, property_tree, statechart, xpressive, etc...
Noel,
it is difficult to classify a library as N/A when we don't know what is not working on. I'm wondering if this is not catching a bug on the regression tools.
Boost.Thread is on the same case, and I will be interested in changing whatever is needed to make it usable on Sun/Solaris.
Please, could you see why the regression tests are not showing why the test fails?
Oh, I should point out that there's about 500 targets that fail to link due to missing Boost.Test libraries.
Thanks for the information. The last test I have been adding to Boost.Thread doesn't use Boost.Test, but the link to Boost.Test is done however. I will dissociate it to see if this helps.
I'm most interested in hearing if Thread (sans Test) will work on Sun.
Me too. Note that some test are using yet Boost.Test. Committed revision 77588. Best, Vicente
Le 27/03/12 22:28, Vicente J. Botet Escriba a écrit :
Le 27/03/12 20:17, Belcourt, K. Noel a écrit :
On Mar 27, 2012, at 10:59 AM, Vicente J. Botet Escriba wrote:
Le 26/03/12 19:30, Belcourt, K. Noel a écrit :
On Mar 26, 2012, at 11:13 AM, Vicente J. Botet Escriba wrote:
Le 26/03/12 17:39, Belcourt, K. Noel a écrit :
On Mar 26, 2012, at 6:31 AM, lcaminiti wrote:
> > Belcourt, K. Noel wrote >> >> Sun is, for all intent and purposes, a dead platform for us. >> While I >> realize others may be using newer flavors of it, we've basically >> stopped and use it only for the numerics which were/are quite >> good. >> Our system is not being maintained so I'd guess your best bet >> is to >> mark your library as unsupported on this platform.
Hi Lorenzo,
> OK. Shall Sun be removed by the trunk regression tests then?
No, we'll leave the Sandia-Sun tester running as long as we can. Go to the Legend at the bottom of the trunk results page, one of the keys is this:
n/a The library author marked it as unusable on particular platform/toolset.
I suggest you mark your library as n/a for the Sandia-Sun tester, as others have done for their libraries, e.g. proto, property_tree, statechart, xpressive, etc...
Noel,
it is difficult to classify a library as N/A when we don't know what is not working on. I'm wondering if this is not catching a bug on the regression tools.
Boost.Thread is on the same case, and I will be interested in changing whatever is needed to make it usable on Sun/Solaris.
Please, could you see why the regression tests are not showing why the test fails?
Oh, I should point out that there's about 500 targets that fail to link due to missing Boost.Test libraries.
Thanks for the information. The last test I have been adding to Boost.Thread doesn't use Boost.Test, but the link to Boost.Test is done however. I will dissociate it to see if this helps.
I'm most interested in hearing if Thread (sans Test) will work on Sun.
Me too. Note that some test are using yet Boost.Test. Committed revision 77588.
Good news. The regression test show now that a lot of test pass and when failing the reason is accessible. I will start to analyze the failing test. Best, Vicente
Vicente Botet wrote
Good news. The regression test show now that a lot of test pass and when failing the reason is accessible.
Congrats :) Is there a reason in general not to use Boost.Test or this issue is limited to the Sun platform? In my libraries I used Boost.Test just for convenience -- I could just as easily catch the errors and return an exit code instead of using Boost.Test... Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-scope-exit-trunk-tests-fail-on-sun-... Sent from the Boost - Dev mailing list archive at Nabble.com.
Le 28/03/12 23:37, lcaminiti a écrit :
Vicente Botet wrote
Good news. The regression test show now that a lot of test pass and when failing the reason is accessible.
Congrats :)
Is there a reason in general not to use Boost.Test or this issue is limited to the Sun platform? In my libraries I used Boost.Test just for convenience -- I could just as easily catch the errors and return an exit code instead of using Boost.Test... IIRC Boost.Test doesn't works neither on cygwin.
I'm using <boost/detail/lightweight_test.hpp> which is really lightweight and works everywhere. Here it is a simple example #include <boost/thread/thread.hpp> #include <boost/detail/lightweight_test.hpp> int main() { boost::thread::id id = boost::this_thread::get_id(); BOOST_TEST(id != boost::thread::id()); return boost::report_errors(); } Boost.TypeTraits has defined some macros that make use of Boost.Test or an internal framework. HTH, Vicente
Vicente Botet wrote
Le 28/03/12 23:37, lcaminiti a écrit :
Vicente Botet wrote
Good news. The regression test show now that a lot of test pass and when failing the reason is accessible.
Congrats :)
Is there a reason in general not to use Boost.Test or this issue is limited to the Sun platform? In my libraries I used Boost.Test just for convenience -- I could just as easily catch the errors and return an exit code instead of using Boost.Test... IIRC Boost.Test doesn't works neither on cygwin.
I was able get Boost.Test to work on my Cygwin with GCC 4.5.3.
I'm using <boost/detail/lightweight_test.hpp> which is really lightweight and works everywhere.
Here it is a simple example
#include <boost/thread/thread.hpp> #include <boost/detail/lightweight_test.hpp>
int main() { boost::thread::id id = boost::this_thread::get_id(); BOOST_TEST(id != boost::thread::id()); return boost::report_errors(); }
Thanks a lot Vicente! I've changed ScopeExit tests to use Boost.Detail/LightweightTest instead of Boost.Test and now the tests give sensible errors also on Sun :) http://www.boost.org/development/tests/trunk/developer/output/Sandia-sun-boo... Next I'll either be able to fix these errors or mark the Sun tests n/a. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-scope-exit-trunk-tests-fail-on-sun-... Sent from the Boost - Dev mailing list archive at Nabble.com.
lcaminiti wrote
Next I'll either be able to fix these errors or mark the Sun tests n/a.
Good news :) it seems that ScopeExit compiles on Sun (after I've replaced Boost.Test with Boost.Detail/LightweightTest as Vicente suggested). One issue however it that Boost.Typeof does not automatically detect Sun as not having native type-of so BOOST_TYPEOF_EMULATION must be explicitly defined by the user to compile ScopeExit code. But once that's done, most (I'm still double checking if all) tests seems to compile. I will mark the ScopeExit failures on Sun as "must use type-of emulation mode (by defining the BOOST_TYPEOF_EMULATION macro)". Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-scope-exit-trunk-tests-fail-on-sun-... Sent from the Boost - Dev mailing list archive at Nabble.com.
Le 02/04/12 22:21, lcaminiti a écrit :
lcaminiti wrote
Next I'll either be able to fix these errors or mark the Sun tests n/a.
Good news :) it seems that ScopeExit compiles on Sun (after I've replaced Boost.Test with Boost.Detail/LightweightTest as Vicente suggested).
One issue however it that Boost.Typeof does not automatically detect Sun as not having native type-of so BOOST_TYPEOF_EMULATION must be explicitly defined by the user to compile ScopeExit code. But once that's done, most (I'm still double checking if all) tests seems to compile. I will mark the ScopeExit failures on Sun as "must use type-of emulation mode (by defining the BOOST_TYPEOF_EMULATION macro)".
What about forcing BOOST_TYPEOF_EMULATION with Sun compiler? Boost.Chrono adds this to the Jamfile project requirements <toolset>sun:<define>BOOST_TYPEOF_EMULATION Maybe I should add it to the config.hpp file in addition to document the restriction. Best, Vicente
Vicente Botet wrote
Le 02/04/12 22:21, lcaminiti a écrit :
lcaminiti wrote
Next I'll either be able to fix these errors or mark the Sun tests n/a.
Good news :) it seems that ScopeExit compiles on Sun (after I've replaced Boost.Test with Boost.Detail/LightweightTest as Vicente suggested).
One issue however it that Boost.Typeof does not automatically detect Sun as not having native type-of so BOOST_TYPEOF_EMULATION must be explicitly defined by the user to compile ScopeExit code. But once that's done, most (I'm still double checking if all) tests seems to compile. I will mark the ScopeExit failures on Sun as "must use type-of emulation mode (by defining the BOOST_TYPEOF_EMULATION macro)".
What about forcing BOOST_TYPEOF_EMULATION with Sun compiler?
Boost.Chrono adds this to the Jamfile project requirements
<toolset>sun:<define>BOOST_TYPEOF_EMULATION
Maybe I should add it to the config.hpp file in addition to document the restriction.
How would I make Boost.Typeof automatically detect that Sun doesn't support native type-of? That'd be the best fix for the user. Shall I change Boost.Config, Boost.Typeof, or something else? Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-scope-exit-trunk-tests-fail-on-sun-... Sent from the Boost - Dev mailing list archive at Nabble.com.
AMDG On 04/03/2012 06:58 AM, lcaminiti wrote:
How would I make Boost.Typeof automatically detect that Sun doesn't support native type-of?
For some reason Boost.Typeof thinks that Sun does support native typeof. See boost/typeof/typeof.hpp:158 ff.
That'd be the best fix for the user. Shall I change Boost.Config, Boost.Typeof, or something else?
In Christ, Steven Watanabe
Steven Watanabe-4 wrote
AMDG
On 04/03/2012 06:58 AM, lcaminiti wrote:
How would I make Boost.Typeof automatically detect that Sun doesn't support native type-of?
For some reason Boost.Typeof thinks that Sun does support native typeof. See boost/typeof/typeof.hpp:158 ff.
That'd be the best fix for the user. Shall I change Boost.Config, Boost.Typeof, or something else?
It looks like there's a problem in Boost.Config that is causing Boost.Typeof not to work on Sun compilers. Here's what's going on. 1) First of all, I was wrong and Sun supports native type-of using __typeof__ so Boost.Typeof is right in doing: #define BOOST_TYPEOF_KEYWORD __typeof__ // boost/typeof/typeof.hpp:158 2) However, the header boost/config/platform/linux.hpp get's included later by Boost.Typeof and it does: #ifndef __GNUC__ // // if the compiler is not gcc we still need to be able to parse // the GNU system headers, some of which (mainly <stdint.h>) // use GNU specific extensions: // //... # ifndef __typeof__ # define __typeof__ typeof // boost/config/platform/linux.hpp:103 # endif This generates and error because Sun has no "typeof" but only "__typeof__" (note that __typeof__ is not a macro on Sun but still it's what you should use for type-of). For example, this code: #include <boost/confi.hpp> int main(void) { int i = 0; __typeof__(i) j = i; return 0; } Incorrectly replaces __typeof__(i) with typeof(i) and it does not compile (as I verified on my Linux Sun installation also looking at the preprocessor output CC -E ...) but it compiles just fine without the #include <boost/config.hpp> because __typeof__(i) remains unchanged. I'm not familiar enough with Boost.Config... how can shall boost/config/platform/linux.hpp:103 be fixed? Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-scope-exit-trunk-tests-fail-on-sun-... Sent from the Boost - Dev mailing list archive at Nabble.com.
Vicente Botet wrote
<toolset>sun:<define>BOOST_TYPEOF_EMULATION
Actually adding this to the Jamfile: <toolset>sun:<define>__typeof__=__typeof__ is a better workaround because having __typeof__ defined will prevent Boost.Config from defining it to "typeof": ... # ifndef __typeof__ # define __typeof__ typeof // boost/config/platform/linux.hpp:103 # endif ... So Boost.Typeof will be able to use Sun's native __typeof__ :) We still should fix the actual issue in Boost.Config -- but I'm not sure how... maybe replacing __GNUC__: // boost/config/platform/linux.hpp #ifndef __GNUC__ // // if the compiler is not gcc we still need to be able to parse // the GNU system headers, some of which (mainly <stdint.h>) // use GNU specific extensions: // //... # ifndef __typeof__ # define __typeof__ typeof // boost/config/platform/linux.hpp:103 # endif with: #if !defined(__GNUC__) && (!defined(__SUNPRO_CC) || __SUNPRO_CC < 0x590) Note that Sun has __typeof__ since version 5.9. But I'm not familiar enough with the Boost.Config platform stuff to make any change to it... any taker? Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-scope-exit-trunk-tests-fail-on-sun-... Sent from the Boost - Dev mailing list archive at Nabble.com.
Le 04/04/12 23:27, lcaminiti a écrit :
Vicente Botet wrote
<toolset>sun:<define>BOOST_TYPEOF_EMULATION
Actually adding this to the Jamfile:
<toolset>sun:<define>__typeof__=__typeof__
is a better workaround because having __typeof__ defined will prevent Boost.Config from defining it to "typeof":
... # ifndef __typeof__ # define __typeof__ typeof // boost/config/platform/linux.hpp:103 # endif ...
So Boost.Typeof will be able to use Sun's native __typeof__ :)
Glad to see that you have found the origin of the incoherency. I'll apply your method soon waiting for a solution in Boost.Config. I'm wondering if this will not remove a lot of failing test with this compiler.
We still should fix the actual issue in Boost.Config -- but I'm not sure how... maybe replacing __GNUC__:
// boost/config/platform/linux.hpp #ifndef __GNUC__ // // if the compiler is not gcc we still need to be able to parse // the GNU system headers, some of which (mainly<stdint.h>) // use GNU specific extensions: // //... # ifndef __typeof__ # define __typeof__ typeof // boost/config/platform/linux.hpp:103 # endif
with:
#if !defined(__GNUC__)&& (!defined(__SUNPRO_CC) || __SUNPRO_CC< 0x590)
Note that Sun has __typeof__ since version 5.9.
But I'm not familiar enough with the Boost.Config platform stuff to make any change to it... any taker?
This seems a good starting workaround. John, do you agree with it? Good work, Vicente
On Wed, Apr 4, 2012 at 17:27, lcaminiti <lorcaminiti@gmail.com> wrote:
Vicente Botet wrote
<toolset>sun:<define>BOOST_TYPEOF_EMULATION
Actually adding this to the Jamfile:
<toolset>sun:<define>__typeof__=__typeof__
is a better workaround because having __typeof__ defined will prevent Boost.Config from defining it to "typeof":
... # ifndef __typeof__ # define __typeof__ typeof // boost/config/platform/linux.hpp:103 # endif ...
So Boost.Typeof will be able to use Sun's native __typeof__ :)
We still should fix the actual issue in Boost.Config -- but I'm not sure how... maybe replacing __GNUC__:
// boost/config/platform/linux.hpp #ifndef __GNUC__ // // if the compiler is not gcc we still need to be able to parse // the GNU system headers, some of which (mainly <stdint.h>) // use GNU specific extensions: // //... # ifndef __typeof__ # define __typeof__ typeof // boost/config/platform/linux.hpp:103 # endif
with:
#if !defined(__GNUC__) && (!defined(__SUNPRO_CC) || __SUNPRO_CC < 0x590)
Note that Sun has __typeof__ since version 5.9.
But I'm not familiar enough with the Boost.Config platform stuff to make any change to it... any taker?
You do not need these defines, and you do not need to redefine typeof as __typeof__ for SunProCC. You only need to pass the correct flags to the Sun C++ compiler: [steleman@darthvader][~/tmp][04/04/2012 19:00:53][1104]>> cat ./typeof.cc #include <iostream> int main (int argc, char* argv[]) { typeof (typeof (char*)[4]) y0; typeof (int*) y1[4]; char* y2[4]; int* y3[4]; std::cerr << argv[0] << std::endl; return 0; } [steleman@darthvader][~/tmp][04/04/2012 19:01:00][1105]>> /opt/oracle/solarisstudio12.3/bin/CC -m32 -g -xO3 -Qoption ccfe -features=gcc typeof.cc -o typeofCC [steleman@darthvader][~/tmp][04/04/2012 19:01:05][1106]>> ./typeofCC ./typeofCC [steleman@darthvader][~/tmp][04/04/2012 19:01:10][1107]>> echo $status 0 [steleman@darthvader][~/tmp][04/04/2012 19:01:14][1108]>> /opt/oracle/solarisstudio12.3/bin/CC -V CC: Sun C++ 5.12 Linux_i386 2011/11/16 [steleman@darthvader][~/tmp][04/04/2012 19:01:20][1109]>> uname -a Linux darthvader 2.6.34.10-0.4-desktop #1 SMP PREEMPT 2011-10-19 22:16:41 +0200 x86_64 x86_64 x86_64 GNU/Linux [steleman@darthvader][~/tmp][04/04/2012 19:01:21][1110]>> --Stefan -- Stefan Teleman KDE e.V. stefan.teleman@gmail.com
Stefan Teleman-2 wrote
[steleman@darthvader][~/tmp][04/04/2012 19:00:53][1104]>> cat ./typeof.cc #include <iostream>
int main (int argc, char* argv[]) { typeof (typeof (char*)[4]) y0; typeof (int*) y1[4]; char* y2[4]; int* y3[4];
std::cerr << argv[0] << std::endl;
return 0; }
[steleman@darthvader][~/tmp][04/04/2012 19:01:00][1105]>> /opt/oracle/solarisstudio12.3/bin/CC -m32 -g -xO3 -Qoption ccfe -features=gcc typeof.cc -o typeofCC
Sun CC has __typeof__ since 5.9: http://developers.sun.com/sunstudio/support/CCcompare.html I'm not sure which one of your flags make CC use "typeof" instead of __typeof__ but I think we should use __typeof__ on Sun as indicated by the link above and as currently and correctly detected by Boost.Typeof (before Boost.Config changes __typeof__ to typeof). To recap, what I've seen is: Boost.Typeof correctly detects that by `#define BOOST_TYPEOF_KEYWORD __typeof__`. However, Boost.Config later `#define __typeof__ typeof` for all non GCC compiler on Linux (I'm not sure why...). Therefore, BOOST_TYEPOF_KEYWORD first expands to __typeof__ which in turns it expands to typeof and CC fails because it doesn't know typeof (it expects __typeof__ instead as Boost.Typeof originally figured out). Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-scope-exit-trunk-tests-fail-on-sun-... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Wed, Apr 4, 2012 at 22:28, lcaminiti <lorcaminiti@gmail.com> wrote:
Stefan Teleman-2 wrote
[steleman@darthvader][~/tmp][04/04/2012 19:00:53][1104]>> cat ./typeof.cc #include <iostream>
int main (int argc, char* argv[]) { typeof (typeof (char*)[4]) y0; typeof (int*) y1[4]; char* y2[4]; int* y3[4];
std::cerr << argv[0] << std::endl;
return 0; }
[steleman@darthvader][~/tmp][04/04/2012 19:01:00][1105]>> /opt/oracle/solarisstudio12.3/bin/CC -m32 -g -xO3 -Qoption ccfe -features=gcc typeof.cc -o typeofCC
Sun CC has __typeof__ since 5.9: http://developers.sun.com/sunstudio/support/CCcompare.html
I'm not sure which one of your flags make CC use "typeof" instead of __typeof__ but I think we should use __typeof__ on Sun as indicated by the link above and as currently and correctly detected by Boost.Typeof (before Boost.Config changes __typeof__ to typeof).
-Qoption ccfe -features=gcc. To build Boost with SunProCC you're going to have to pass several -Qoption ccfe -features=<X> to the compiler anyway. Might as well bite the bullet and pass them. :-) Otherwise, no dice, it won't build. Also, the document page you are referring to shows an inconsistency between the typeof operator implementations in SunProC vs. SunProCC: http://developers.sun.com/solaris/articles/c_type.html SunProC allows typeof (without underscores) by default, without any special flags: [steleman@darthvader][~/tmp][04/04/2012 23:04:00][1122]>> /opt/oracle/solarisstudio12.3/bin/cc -m32 -g -xO3 typeof.c -o typeofC [steleman@darthvader][~/tmp][04/04/2012 23:04:09][1123]>> ./typeofC ./typeofC [steleman@darthvader][~/tmp][04/04/2012 23:04:13][1124]>> echo $status 0 [steleman@darthvader][~/tmp][04/04/2012 23:04:17][1125]>> cat ./typeof.c #include <stdio.h> int main(int argc, char* argv[]) { typeof (typeof (char*)[4]) y0; typeof (int*) y1[4]; char* y2[4]; int* y3[4]; (void) fprintf(stderr, "%s\n", argv[0]); return 0; } But, neither typeof nor __typeof__ are part of any Standard anyway. --Stefan -- Stefan Teleman KDE e.V. stefan.teleman@gmail.com
Stefan Teleman-2 wrote
-Qoption ccfe -features=gcc.
To build Boost with SunProCC you're going to have to pass several -Qoption ccfe -features=<X> to the compiler anyway. Might as well bite the bullet and pass them. :-) Otherwise, no dice, it won't build.
Also, the document page you are referring to shows an inconsistency between the typeof operator implementations in SunProC vs. SunProCC:
http://developers.sun.com/solaris/articles/c_type.html
SunProC allows typeof (without underscores) by default, without any special flags:
I see. I'll try to add your suggested options to my Jamfile and see how the regression tests go. Thanks! --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-scope-exit-trunk-tests-fail-on-sun-... Sent from the Boost - Dev mailing list archive at Nabble.com.
Le 05/04/12 15:24, lcaminiti a écrit :
Stefan Teleman-2 wrote
-Qoption ccfe -features=gcc.
To build Boost with SunProCC you're going to have to pass several -Qoption ccfe -features=<X> to the compiler anyway. Might as well bite the bullet and pass them. :-) Otherwise, no dice, it won't build.
Also, the document page you are referring to shows an inconsistency between the typeof operator implementations in SunProC vs. SunProCC:
http://developers.sun.com/solaris/articles/c_type.html
SunProC allows typeof (without underscores) by default, without any special flags:
I see. I'll try to add your suggested options to my Jamfile and see how the regression tests go.
I suspect that the code in Typeof need to be changed to use typeof introduced with these options, isn't it? So I don't think it will help to cahnge the options alone. Best, Vicente
Vicente Botet wrote
I see. I'll try to add your suggested options to my Jamfile and see how the regression tests go.
I suspect that the code in Typeof need to be changed to use typeof introduced with these options, isn't it? So I don't think it will help to cahnge the options alone.
I'll give this a try and post the results (maybe no change in Typeof because Config replaces __typeof__ with typeof at least on Linux... but if that works is a "bug" cancelling another :) ). --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-scope-exit-trunk-tests-fail-on-sun-... Sent from the Boost - Dev mailing list archive at Nabble.com.
lcaminiti wrote
Stefan Teleman-2 wrote
-Qoption ccfe -features=gcc.
To build Boost with SunProCC you're going to have to pass several -Qoption ccfe -features=<X> to the compiler anyway. Might as well bite the bullet and pass them. :-) Otherwise, no dice, it won't build.
Also, the document page you are referring to shows an inconsistency between the typeof operator implementations in SunProC vs. SunProCC:
http://developers.sun.com/solaris/articles/c_type.html
SunProC allows typeof (without underscores) by default, without any special flags:
I see. I'll try to add your suggested options to my Jamfile and see how the regression tests go.
I've added this to ScopeExit test/Jamfile.v2: project : requirements <toolset>sun:<cxxflags>"-Qoption ccfe -features=gcc" ; But the regression test show: "/opt/sunstudio12.1/bin/CC" +d -library=stlport4 -features=tmplife -features=tmplrefstatic -library=stlport4 -g -erroff=%none -m64 -KPIC -DBOOST_ALL_NO_LIB=1 -I".." -c -o "/scratch2/kbelco/boost/results/boost/bin.v2/libs/scope_exit/test/world_checkpoint_seq.test/sun-5.10/debug/address-model-64/stdlib-sun-stlport/world_checkpoint_seq.o" "../libs/scope_exit/test/world_checkpoint_seq.cpp" Any idea why the -Qoptiona ccfee -features=gcc did not show up in the regression test run? What am I doing wrong? Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-scope-exit-trunk-tests-fail-on-sun-... Sent from the Boost - Dev mailing list archive at Nabble.com.
lcaminiti wrote
lcaminiti wrote
Stefan Teleman-2 wrote
-Qoption ccfe -features=gcc.
To build Boost with SunProCC you're going to have to pass several -Qoption ccfe -features=<X> to the compiler anyway. Might as well bite the bullet and pass them. :-) Otherwise, no dice, it won't build.
Also, the document page you are referring to shows an inconsistency between the typeof operator implementations in SunProC vs. SunProCC:
http://developers.sun.com/solaris/articles/c_type.html
SunProC allows typeof (without underscores) by default, without any special flags:
I see. I'll try to add your suggested options to my Jamfile and see how the regression tests go.
I've added this to ScopeExit test/Jamfile.v2:
project : requirements <toolset>sun:<cxxflags>"-Qoption ccfe -features=gcc" ;
But the regression test show:
"/opt/sunstudio12.1/bin/CC" +d -library=stlport4 -features=tmplife -features=tmplrefstatic -library=stlport4 -g -erroff=%none -m64 -KPIC -DBOOST_ALL_NO_LIB=1 -I".." -c -o "/scratch2/kbelco/boost/results/boost/bin.v2/libs/scope_exit/test/world_checkpoint_seq.test/sun-5.10/debug/address-model-64/stdlib-sun-stlport/world_checkpoint_seq.o" "../libs/scope_exit/test/world_checkpoint_seq.cpp"
Any idea why the -Qoptiona ccfee -features=gcc did not show up in the regression test run? What am I doing wrong?
Sorry, I got confused (maybe I didn't refresh my browser page...), the options were added but they didn't help: Compile [2012-04-09 16:56:36 UTC]: fail "/opt/sunstudio12.1/bin/CC" +d -Qoption ccfe -features=gcc -library=stlport4 -features=tmplife -features=tmplrefstatic -library=stlport4 -g -erroff=%none -m64 -KPIC -DBOOST_ALL_NO_LIB=1 -I".." -c -o "/scratch2/kbelco/boost/results/boost/bin.v2/libs/scope_exit/test/world_seq.test/sun-5.10/debug/address-model-64/stdlib-sun-stlport/world_seq.o" "../libs/scope_exit/test/world_seq.cpp" "../libs/scope_exit/test/world_seq.cpp", line 34: Error: boost_se_wrapped_t_0_34 is not a namespace or class name. "../libs/scope_exit/test/world_seq.cpp", line 34: Error: type is not defined. "../libs/scope_exit/test/world_seq.cpp", line 34: Error: boost_se_wrapped_t_1_34 is not a namespace or class name. "../libs/scope_exit/test/world_seq.cpp", line 34: Error: type is not defined. "../libs/scope_exit/test/world_seq.cpp", line 34: Error: Could not find a match for boost_se_params_t_34::boost_se_params_t_34(bool, std::vector<person>) needed in world::add_person(const person&). "../libs/scope_exit/test/world_seq.cpp", line 35: Error: int is not a structure type. 6 Error(s) detected. If I use these options on my Sun Linux Ubuntu installation, this code compiles. But on the Sun platform used for regression I still got there errors while the errors go away if define=BOOST_TYPEOF_EMULATION. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-scope-exit-trunk-tests-fail-on-sun-... Sent from the Boost - Dev mailing list archive at Nabble.com.
Le 09/04/12 23:54, lcaminiti a écrit :
lcaminiti wrote Sorry, I got confused (maybe I didn't refresh my browser page...), the options were added but they didn't help:
...
If I use these options on my Sun Linux Ubuntu installation, this code compiles. But on the Sun platform used for regression I still got there errors while the errors go away if define=BOOST_TYPEOF_EMULATION.
Hi, have you checked that the test runner has been launch since the revision including your modifications? Vicente
Vicente Botet wrote
Le 09/04/12 23:54, lcaminiti a écrit :
lcaminiti wrote Sorry, I got confused (maybe I didn't refresh my browser page...), the options were added but they didn't help:
...
If I use these options on my Sun Linux Ubuntu installation, this code compiles. But on the Sun platform used for regression I still got there errors while the errors go away if define=BOOST_TYPEOF_EMULATION.
Hi,
have you checked that the test runner has been launch since the revision including your modifications?
Thanks, I didn't notice that before. Anyway, I just checked and yes the test runner was lunched against the rev with the cxxflags set for Sun in the Jamfile. That makes sense because I also see the extra flags in the compiler command line (I don't know why I didn't see them before, again maybe I just didn't update my browser page): http://www.boost.org/development/tests/trunk/developer/output/Sandia-sun-boo... However, the extra cxxflags which are a fix on my Sun Ubuntu Linux didn't fix the issue here. I'm still trying a couple of other possible workarounds for Sun... I'll keep you posted. Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-scope-exit-trunk-tests-fail-on-sun-... Sent from the Boost - Dev mailing list archive at Nabble.com.
Belcourt, K. Noel wrote
On Mar 26, 2012, at 11:13 AM, Vicente J. Botet Escriba wrote:
Le 26/03/12 17:39, Belcourt, K. Noel a écrit :
On Mar 26, 2012, at 6:31 AM, lcaminiti wrote:
Belcourt, K. Noel wrote
Sun is, for all intent and purposes, a dead platform for us. While I realize others may be using newer flavors of it, we've basically stopped and use it only for the numerics which were/are quite good. Our system is not being maintained so I'd guess your best bet is to mark your library as unsupported on this platform.
Hi Lorenzo,
OK. Shall Sun be removed by the trunk regression tests then?
No, we'll leave the Sandia-Sun tester running as long as we can. Go to the Legend at the bottom of the trunk results page, one of the keys is this:
n/a The library author marked it as unusable on particular platform/toolset.
I suggest you mark your library as n/a for the Sandia-Sun tester, as others have done for their libraries, e.g. proto, property_tree, statechart, xpressive, etc...
Noel,
it is difficult to classify a library as N/A when we don't know what is not working on. I'm wondering if this is not catching a bug on the regression tools.
Boost.Thread is on the same case, and I will be interested in changing whatever is needed to make it usable on Sun/Solaris.
Please, could you see why the regression tests are not showing why the test fails?
Oh, I should point out that there's about 500 targets that fail to link due to missing Boost.Test libraries.
Note that ScopeExit (LocalFunction, etc) regression tests use Boost.Test but the library itself does not use Boost.Test at all. So even if the regression tests for the library fails due to Boost.Test missing, it is difficult to conclude if the library will or not work on the platform. The only sure thing is that the library is not being sensibly tested on Sun... All of that said, I'm happy not worry about Sun :) I might mark the library n/a or something like that. I'll stop trying to understand if they work or not on Sun given that I can't really test it on that platform. Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-scope-exit-trunk-tests-fail-on-sun-... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Sat, Mar 24, 2012 at 11:54, lcaminiti <lorcaminiti@gmail.com> wrote:
Hello all,
I'm trying to get ScopeExit to work on Sun.
1) First it looked like all tests fail on this compiler: http://www.boost.org/development/tests/trunk/developer/scope_exit.html
2) However, I installed Solaris Studio 12.3 on my Ubuntu 10 and it seems that I can compile ScopeExit just fine with the following"
$ CC -I /usr/include/i386-linux-gnu/ -I ../../.. -DBOOST_TYPEOF_EMULATION world_seq.cpp
Note that: a) Sun does not support variadic macros so only ScopeExit sequence syntax will work. b) Sun does not support native type-of so BOOST_TYPEOF_EMULATION needs to be defined.
Therefore, all original ScopeExit type-of emulation tests named `emulation_...` should compile (because they use the sequence syntax and define BOOST_TYPEOF_EMULATION). However, they fail... why?
3) Why when I click on the "fail" link for these tests I get no information on the Sun compiler's output?
For example: http://www.boost.org/development/tests/trunk/developer/output/Sandia-sun-boo...
If I follow this link I get "Error extracting file: No matching files were found.". What does this mean?
Hi. Could you please try passing: -Qoption ccfe -features=gcc -Qoption ccfe -tmpldepth=N on compile line, where N above is an integer greater than 64 (which is the default) and see if this fixes the problems. I would try first with -tmpldepth=128. --Stefan -- Stefan Teleman KDE e.V. stefan.teleman@gmail.com
participants (6)
-
Belcourt, K. Noel -
lcaminiti -
Lorenzo Caminiti
-
Stefan Teleman -
Steven Watanabe -
Vicente J. Botet Escriba