Diff from upstream:
Removed clang-specific branch for x86 DCAS-based loads.
The storage to load from is const-qualified and DCAS via compiler intrinsics
require an unqualified pointer. Use asm implementation instead, which should be
as efficient as intrinsics, if not better, in this case.
6e14ca24da
ok Brad (maintainer)
libc++7 made <experimental/string_view> a stub containing only
#error "<experimental/string_view> has been removed. Use <string_view> instead."
One can wonder why upstream kept the header at all.
To make your boost.build executables b2 and bjam useful we have to install
some additional files.
Noticed by Ivan Krylov via openbsd@freenode. Thanks!
feedback from semarie@ and aja@, tweaks and ok sthen@
Since the update to icu4c-63.1, icu4c uses char16_t and others from the
C++11 standard, but eg++-4.9 defaults to -std=gnu++98.
"looks good" rsadowski@, ok Brad (maintainers)
As this brings new libraries on supported architectures, split the
package into -main and -md subpackages, keeping plist updates simpler
and avoiding need for knowledge of supported arches in dependent
ports. Also means that if future ports start picking up the MD
libraries they will be easier to find. (Thanks aja@ for running a
bulk build and check-lib-depends run with an earlier version to
make sure existing ports don't pick up the new libs.)
ok rsadowski@
Bumps for ports using boost as LIB_DEPENDS or RUN_DEPENDS to
follow.
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@
