Bug 1245805 - akonadi fails to build
Summary: akonadi fails to build
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: boost
Version: 6.7
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Jonathan Wakely
QA Contact: Miloš Prchlík
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-07-22 20:08 UTC by Frantisek Kluknavsky
Modified: 2016-05-11 00:14 UTC (History)
11 users (show)

(edit)
Previous versions of the boost-devel package installed files for use with CMake
which are incompatible with the updated version of CMake in Red Hat Enterprise
Linux 6.8. This caused problems for software built with CMake because the
incompatible files were found and used automatically. The updated Boost packages
remove the incompatible files, so that software using the Boost libraries can be
built with the new version of CMake.
Clone Of:
(edit)
Last Closed: 2016-05-11 00:14:41 UTC


Attachments (Terms of Use)
Patch spec file to not install .cmake files (2.29 KB, patch)
2015-11-18 12:13 UTC, Jonathan Wakely
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:0887 normal SHIPPED_LIVE boost bug fix update 2016-05-10 22:49:16 UTC

Description Frantisek Kluknavsky 2015-07-22 20:08:50 UTC
Description of problem:
Akonadi build fails in rhel-6.7.


Version-Release number of selected component (if applicable):
akonadi-1.2.1-3.el6


Additional info:
Maybe this is related to rebased cmake - https://bugzilla.redhat.com/show_bug.cgi?id=1209427

Comment 2 Jan Grulich 2015-07-23 09:04:43 UTC
Looks like an issue in Boost itself, see:
CMake Error at /usr/lib64/boost/Boost.cmake:536 (message):
The imported target "boost_date_time-static" references the file
"/usr/lib64/lib64/libboost_date_time.a"

The path is wrong.

Comment 3 Frantisek Kluknavsky 2015-07-23 11:02:59 UTC
Builds fine in rhel-6.5 buildroot, fails to build in the same rhel-6.5 buildroot but with cmake and libarchive from rhel-6.7. Could you please elaborate why it is a problem with boost? Boost has a bug which was hidden with older cmake but exposed with new cmake? If you have a clear idea how paths should be handled in cmake, please give me a hint.

Comment 4 Jan Grulich 2015-07-23 11:37:27 UTC
Well, I'm not a cmake developer or maintainer, I just saw a wrong path coming from Boost.cmake so I assumed that the problem is there. If you are sure that the problem is not in Boost, feel free to reassign this bug to cmake.

Comment 5 Jonathan Wakely 2015-07-23 12:06:48 UTC
It could be a Boost problem, /usr/lib64/boost/Boost-relwithdebinfo.cmake has:

# Compute the installation prefix relative to this file.
GET_FILENAME_COMPONENT(_IMPORT_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH)
GET_FILENAME_COMPONENT(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)

# Import target "boost_date_time-static" for configuration "RelWithDebInfo"
SET_PROPERTY(TARGET boost_date_time-static APPEND PROPERTY IMPORTED_CONFIGURATIONS RELWITHDEBINFO)
SET_TARGET_PROPERTIES(boost_date_time-static PROPERTIES
  IMPORTED_LOCATION_RELWITHDEBINFO "${_IMPORT_PREFIX}/lib64/libboost_date_time.a"
  )


The first get_filename_component will set _IMPORT_PREFIX to /usr/lib64/boost and the second will set it to /usr/lib64 and then the IMPORTED_LOCATION_RELWITHDEBINFO will be /usr/lib64/lib64/libboost_date_time.a

Did CMake change how get_filename_component works? Maybe how it handles trailing directory separators or something?

Comment 6 Anssi Johansson 2015-07-26 15:52:37 UTC
Bug 849791 is probably related. If one rebuilds boost with an old (version 2.6) cmake, boost seems to work properly. I'll copy&paste what I wrote in bug 849791 comment 11:

At least the following packages from EPEL6 no longer build with RHEL 6.7's boost-1.41.0-27.el6 due to this bug:

paraview-3.8.1-3.el6.src.rpm
plee-the-bear-0.4.1-5.el6.src.rpm
scribus-1.4.3-2.el6.src.rpm
smesh-5.1.2.2-10.svn55.el6.src.rpm
supertux-0.3.4-1.el6.src.rpm
vtk-5.8.0-6.el6.1.src.rpm

They build fine if I first rebuild boost using cmake-2.6.4-5.el6, and then use the newly built boost for building the above packages. They also build fine using RHEL 6.6's boost, so I consider this a regression in boost.

They all fail with a:

CMake Error at /usr/lib64/boost/Boost.cmake:536 (message):
  The imported target "boost_date_time-static" references the file
     "/usr/lib64/lib64/libboost_date_time.a"
  but this file does not exist.  Possible reasons include: ...

The following packages from EPEL6 can't be built even if I rebuild boost with cmake 2.6. It is unclear at this time what would be required to compile them. Perhaps they need an older boost.

console-bridge-0.1.4-2.el6.src.rpm
-- No rule to make target `/usr/lib64/lib64/libboost_system-mt.so.5', needed by `libconsole_bridge.so.0'.
libflatarray-0.1.1-1.el6.src.rpm
-- No rule to make target `/usr/lib64/lib64/libboost_date_time-mt.so.5', needed by `test/aligned_allocator_test'.
libkolabxml-0.7.0-2.el6.src.rpm
-- No rule to make target `/usr/lib64/lib64/libboost_thread-mt.so.5', needed by `src/libkolabxml.so.0.7.0'.

For the above three packages, the files are present in /usr/lib64, but not in /usr/lib64/lib64.

Comment 7 Johnny Hughes 2015-07-26 18:39:41 UTC
Based on what is posted in #849791 , I don't think they mean to fix it.

You may ne able to use '-DBoost_NO_BOOST_CMAKE=ON' to fix it.

Comment 8 Jonathan Wakely 2015-07-27 09:30:00 UTC
(In reply to Johnny Hughes from comment #7)
> Based on what is posted in #849791 , I don't think they mean to fix it.
> 
> You may ne able to use '-DBoost_NO_BOOST_CMAKE=ON' to fix it.

Yup, after reading Bug 849791 it looks like akonadi should not be using those cmake files.

Comment 9 Jan Grulich 2015-07-27 14:30:21 UTC
I can confirm that using '-DBoost_NO_BOOST_CMAKE=ON' makes Akonadi to build again.

Comment 13 Jan Grulich 2015-11-16 08:54:47 UTC
I still think this should be fixed somewhere else, because akonadi is not the only package which needs to use -DBoost_NO_BOOST_CMAKE=ON option in order to build, I had to do the same for kdebase-workspace too and I bet more packages will follow.

Comment 14 Jonathan Wakely 2015-11-16 10:32:53 UTC
Yes, tt's going to be fixed in Boost, which is the component of the bug.

Comment 15 Jonathan Wakely 2015-11-18 12:13 UTC
Created attachment 1096003 [details]
Patch spec file to not install .cmake files

Fixing this is very simple once it's acked.

Comment 18 Miloš Prchlík 2016-01-18 14:09:20 UTC
Verified with build boost-1.41.0-28.el6, rebuild of akonadi (from SRPM) passes.

Comment 20 errata-xmlrpc 2016-05-11 00:14:41 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-0887.html


Note You need to log in before you can comment on or make changes to this bug.