I have tested sun 12.2 through 12.5 with stlport and running the integer lasts from the latest 'develop'.
Thanks for this!
My user-config.jam entry for each version has:
<cxxflags>-std=sun03 <cxxflags>-library=stlport4 <linkflags>-std=sun03 <linkflags>-library=stlport4 <cxxflags>-features=tmplife <cxxflags>-features=tmplrefstatic ;
I get, starting from the latest:
12.5
sun.compile.c++ /home/fceldiener/build/boost/bin.v2/libs/integer/test/common_factor_test.test/sun-12.5stlport/debug/address-model-32/common_factor_test.o
"../../../boost/rational.hpp", line 141: Error: The type "boost::STATIC_ASSERTION_FAILURE<0>" is incomplete.
"common_factor_test.cpp", line 327: Where: While specializing "boost::rational<my_wrapped_integer<int, 1>>".
"common_factor_test.cpp", line 327: Where: Specialized in non-template code.
1 Error(s) detected.
This is now fixed in develop by altering the tests This issue is caused (and would have been equally caused before) by simply including <boost/rational.hpp>. The problem is that the tests use gcd<T>(arg1, arg2), but this causes all overloads of gcd to be instantiated on T, regardless of whether they will be selected, and the rational (or multiprecision) overloads may not compile for some random type T. Changing to gcd(static_cast<T>(arg1), static_cast<T>(arg2)) fixes things for now. It's probably possible to make this work if there was a real need, but since it has never worked before (the tests simply weren't exposing the issue) and no one has complained it's very low priority IMO.
12.4
sun.compile.c++ /home/fceldiener/build/boost/bin.v2/libs/integer/test/common_factor_test.test/sun-12.4stlport/debug/address-model-32/common_factor_test.o
"../../../boost/integer/common_factor_rt.hpp", line 110: Warning: Identifier expected instead of "}".
That's a bug in the header for C++98 compilers (extraneous , in enum declaration), fixed in develop. I'm hoping the rest of the errors are cascading off this.
12.2
../../../boost/cstdint.hpp", line 381: Error: uintptr_t is not defined.
appears for each test.
I've pushed a tentative fix to Boost.Config, but it's likely that this has never worked before either!
I did not try 64-bit tests. Should I try with a higher -std=c++11 level with stlport ? I have separate jam entries which test each version without the stlport library but with c++03 or c++11 as the standard.
I don't believe it's possible to compile with both STLPort and C++11 or later as these use a different ABI. There is one remaining failure with Oracle 12.5 in C++11 mode relating to how it handles variadic templates, I'll try to find a workaround for that later. Many thanks for those tests! John. --- This email has been checked for viruses by AVG. http://www.avg.com