Main port changes:
- Add myself as second maintainer
- Licence tag from MIT-like to boost
Changelog:
http://www.boost.org/users/history/version_1_66_0.html
ok jca@ and landry@ (Tested in a bulk, thanks!)
"Fine with me" from Brad (maintainer)
Notable port changes.
- Bump all shared libs from 6.0 to 7.0.
- COMPILER= base-clang ports-gcc (Replace ONLY_FOR_ARCHS)
- Remove our user.hpp. Boost detects all compiler features correct.
- Drop all -Wno-* options.
- Drop fiber support. It doesn't build with GCC
- Drop stacktrace support. It doesn't build on arm (spotted by jca@)
- b2 doesn't seem to respect python parameter, we need to run twice with
separate python environments to build both shared libs.
- Zap trailing whitespace
- Add py-numpy as bdep
- Disable precompiled header
- cleanup BJAM_CONFIG
- Drop "-d+2" debug.
Survived a macppc bulk by kirby@
Survived a amd64 bulk by landry@
Build test on sparc64 and arm by jca@ (and many other tests)
Many thanks to all those who made it possible
Final ok landry@, jca@
wrong compiler, so re-add it (dependent ports will whine a lot less)
tell boost we have threads and int128 (there's not issue about dual
compiler for clang)
does build.
todo:
- enable more stuff
- look closer at the tooling, needs something like the gcc config change
but at least, this allows us to look at the remaining ports.
(1) Pass CXX and CXXFLAGS to the configure script run.
(2) Split out the build of the bjam tool from the bootstrap procedure.
(3) Tell the main build to use CXX via user-config.jam.
ok Brad, jca@
time.
We build boost itself with gcc-4.2.1 from base, which doesn't support
the integer scalar type __int128, and this results in a
/usr/local/include/boost/config/user.hpp lacking the "BOOST_HAS_INT128"
define.
When compiling something that depends on boost using a newer compiler
like gcc-4.9 or clang, a code snippet in
/usr/local/include/boost/config/compiler/{clang,gcc}.hpp reactivates
__int128 support, but the code containing typedef declarations
inside /usr/local/include/boost/config/suffix.hpp is never reached,
because /usr/local/include/boost/config/user.hpp lacks "BOOST_HAS_INT128".
Hence, the following errors occur:
/usr/local/include/boost/type_traits/is_integral.hpp:72:1: error: 'int128_type' is not a member of 'boost'
/usr/local/include/boost/type_traits/is_integral.hpp:73:1: error: 'uint128_type' is not a member of 'boost'
As a temporary band-aid, completely disable __int128 support on
OpenBSD.
OK jca@, sthen@
/usr/local/include/boost/asio/ssl/impl/context.ipp: In constructor 'boost::asio::ssl::context::context(boost::asio::ssl::context_base::method)':
/usr/local/include/boost/asio/ssl/impl/context.ipp:93: error: '::SSLv3_method' has not been declared
/usr/local/include/boost/asio/ssl/impl/context.ipp:96: error: '::SSLv3_client_method' has not been declared
/usr/local/include/boost/asio/ssl/impl/context.ipp:99: error: '::SSLv3_server_method' has not been declared
OK jca@
- ensure we don't build the 'context' and 'coroutine' libs, they are not
portable and the latter depends on the former
- don't use the 'gcc_sparc' backend in Boost.atomic, for it doesn't
build; use the generic gcc backend based on __sync_*
- stop tweaking cc -march / -mcpu values; this is not desirable on any
arch and it breaks on sparc64 due to a bogus -mcpu=c3 default
- don't attempt to force -m32 / -m64 flags, this breaks at least alpha
(64 bits but doesn't understand -m64)
alpha, hppa & sparc64 tests by landry@, amd64 bulk by ajacoutot@
ok jasper@
not enable the use of said features because the POSIX feature
groups are not enabled yet due to missing functions/features
within respective feature groups.
ok sthen@
codepath to fix a run-time issue for apps using boost-filesystem with apps
failing with.. "std::runtime_error: locale::facet::_S_create_c_locale name not valid"
Reported by/tested/Ok gonzalo@ bentley@
