Bug 825826
Summary: | Boost 1.50 in Fedora 18 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Petr Machata <pmachata> |
Component: | boost | Assignee: | Petr Machata <pmachata> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | denis.arnaud_fedora, mnewsome, pertusus, pmachata, redhat-bugzilla |
Target Milestone: | --- | Keywords: | FutureFeature |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Enhancement | |
Doc Text: | Story Points: | --- | |
Clone Of: | 754865 | Environment: | |
Last Closed: | 2013-03-08 13:17:31 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 847534 | ||
Bug Blocks: |
Description
Petr Machata
2012-05-28 15:08:39 UTC
Regarding the upstream that this will use, there are, in theory, three possibilities: canonical boost, pocb, or ryppl. In the past several releases, we were using pocb. But that has been largely abandoned and required considerable effort on maintainers' side. Ryppl is what seems to be the way of the future. I'm currently testing Ryppl to see whether it provides the build flexibility that we need. So far I've found that to build shared objects we need to issue cmake thus: cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_SHARED_LIBS=TRUE <srcdir> That builds without sonames. To fill in these, we need to patch some cmake files like this: diff -up modules/boost/system/CMakeLists.txt\~ modules/boost/system/CMakeLists.txt --- modules/boost/system/CMakeLists.txt 2012-06-25 18:21:00.770952956 +0200 +++ modules/boost/system/CMakeLists.txt 2012-06-25 18:21:14.565050692 +0200 @@ -16,6 +16,7 @@ add_library(boost_system src/error_code.cpp src/local_free_on_destruction.hpp ) +set_target_properties(boost_system PROPERTIES SOVERSION "1.50.0") if(NOT BUILD_SHARED_LIBS) set_target_properties(boost_system PROPERTIES We will also want to build twice, once for DSO's and once for static archd ... and once for static archives. I'm thinking that if eu I'm thinking that if the Ryppl way is viable, we might even provide each boost library in a separate boost-devel subpackage. The dependencies are clearly stated in the CMakeList's, and it should be possible to generate the corresponding .spec artifacts from that. Python3 builds are straightforward: -DPython_ADDITIONAL_VERSIONS=3.2mu There doesn't seek There doesn't seem to be a mechanism for configuring just a subset of targets, but one can launch build of a subset by doing e.g. make VERBOSE=1 boost_graph_parallel There doesn't seem to be a way to install a boost distribution from ryppl toolset. We could install manually, but that's probably bending over backwards too much. I talked to the developers on #ryppl, and they don't feel like ryppl is mature enough for use in Fedora either. POCB is nowadays essentially maintained by Denis alone, with occasional patch from me, and there's no clear intent to become more official. Given the above, I feel like we should switch back to building boost with jam. Initial packaging of boost 1.50 has just been committed to master. Scratch build is spinning here: http://koji.fedoraproject.org/koji/taskinfo?taskID=4330875 After fixing bugs in the build above, I will do an official build in a separate boost tag (as described in https://fedorahosted.org/rel-eng/ticket/5230 ). In any case, I think now is the time to write to fedora devel, and update everyone on how to rebuild for new boost, so I'll do it shortly. I've just built boost 1.50: http://koji.fedoraproject.org/koji/taskinfo?taskID=4331284 Note the build was made into the tag "f18-boost". Missing filesystem v2 breaks Zarafa building. Robert, if this is still a problem, then please open a separate bug report and I will look into it. The purpose of this bug was to track Fedora 18 feature, which has now long been implemented. |