On 4/29/2017 1:49 PM, John Maddock via Boost wrote:
Sorry about the multiple posts. I have been having some trouble with Thunderbird. I think it is fixed now.
No problem, for some reason I lost all boost messages for a couple of days....
Something apparently happened to everybody, where the mailing lists stopped working along with the GMane reflection. Everything seems to be back now.
but I see from the archives you replied as below:
With 12.3 I see:
sun.compile.c++ /home/fceldiener/build/boost/bin.v2/libs/integer/test/fail_uint_65.test/sun-12.3stlport/debug/address-model-32/fail_uint_65.o
I can not see why it fails to compile and no reason seems to be given.
It's a compile-fail test, which compiles when it should not - as I understand it, it tries to create a 65-bit integer which should of course fail. I assume it's a compiler bug, but either way, nothing has changed in that code for years.
With 12.2 I still see:
sun.compile.c++ /home/fceldiener/build/boost/bin.v2/libs/integer/test/integer_traits_test.test/sun-12.2stlport/debug/address-model-32/integer_traits_test.o "../../../boost/cstdint.hpp", line 381: Error: uintptr_t is not defined. 1 Error(s) detected.
That's weird, it should have been fixed in https://github.com/boostorg/config/commit/19766b0a0e3d8c92e4c0d058cc47190ce7... - solaris.hpp unconditionally defines BOOST_HAS_STDINT_H so that pp-branch should only be taken when INTPTR_MAX is defined and ::intptr actually exists. Or are you on red-hat?
I am on Linux ( Fedora 25 ), not Solaris. I will look at it and see what I can figure out.
In which case are you able to figure out why that pp-branch is taken?
Thanks!
John.