The bug was introduced when devel/gettext was removed from MODULES.
The issue (when building port depending on devel/kf5/kparts) was reported
by aja@, thanks!
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@
should eliminate the TOCTOU race between config and build stages
that can result in neither the internal or the port versions being
available.
Found while preparing for Ocaml 4.3.0.
ok sthen@
This plugin installs a mocker fixture which is a thin-wrapper around the
patching API provided by the mock package, but with the benefit of not
having to worry about undoing patches at the end of a test.
/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@
This does not include NetworkManager and ModemManager bindings, for obvious
reasons. But there is the Bluez-Qt binding included, which acts as a stub,
allowing KDE stuff relying on it to compile.
Also, we ship outdated version of Baloo, because newer versions rely on
the MDB library which we don't have - and won't have until UBC is fixed.
Input from many, tested by kirby@ and awolk@, final okay awolk@ - thanks!
This switches libffi to the use of two different mappings per closure,
one with RW access, the other with RX access. Even if not perfect it is
already an improvement. Soon RWX memory will be unavailable by default,
so fixing libffi means that we don't have to tweak an unknown percentage
of the 565 ports that link against it...
Initial diff from sthen@ who also did most of the tests.
ok sthen@ jasper@ (maintainer)
