Summary: | databases/akonadi: fix build with boost 1.60 on 9.x | ||||||
---|---|---|---|---|---|---|---|
Product: | Ports & Packages | Reporter: | Dmitry Marakasov <amdmi3> | ||||
Component: | Individual Port(s) | Assignee: | freebsd-kde (group) <kde> | ||||
Status: | Closed FIXED | ||||||
Severity: | Affects Some People | CC: | truckman | ||||
Priority: | --- | Flags: | rakuco:
maintainer-feedback+
|
||||
Version: | Latest | ||||||
Hardware: | Any | ||||||
OS: | Any | ||||||
Bug Depends on: | |||||||
Bug Blocks: | 199601 | ||||||
Attachments: |
|
Description
Dmitry Marakasov
2016-02-29 20:52:59 UTC
(In reply to Dmitry Marakasov from comment #0) > Another solution would be > to switch akonadi to USES=compiler:c++11-lib (which may be more desirable, > as building c++ libraries with clang while most ports are built with gcc may > lead to ABI compatibility issues, and c++11-lib will use gcc to build), but > it will also require additional testing. I'm not aware of ABI compatibility issues between clang/libstdc++ and GCC/libstdc++, the problem's when libc++ is used instead of libstdc++, or a different libstdc++ version is used. Using USES=compiler:c++11-lib would cause the latter: Qt4 is built with base GCC and base libstdc++, with akonadi using lang/gcc and it's libstdc++, which is much more likely to either fail to link or cause runtime crashes than what we do now. If the problem in boost is that it assumes that a compiler that understands C++11 is also a compiler that has a C++11-compatible standard library, wouldn't it be possible to do what we do with Qt itself and make the checks more granular (e.g. if clang is used with libstdc++, assume std::forward and other C++11 features that depend on the standard library are not present)? I'm able to get akonadi to build by adding this patch to boost: --- boost/config/compiler/clang.hpp.orig 2015-12-08 18:55:19 UTC +++ boost/config/compiler/clang.hpp @@ -167,7 +167,7 @@ # define BOOST_NO_CXX11_UNIFIED_INITIALIZATION_SYNTAX #endif -#if !__has_feature(cxx_rvalue_references) +#if !__has_feature(cxx_rvalue_references) || (defined(__GLIBCXX__) && __GLIBCXX__ < 20080606) # define BOOST_NO_CXX11_RVALUE_REFERENCES #endif That's more in line with what I was suggesting. Please take a look at bug 199601, comment #77 where I elaborate on a better check you can possibly do. Fixed in the latest version of the boost upgrade patch |