RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1245805 - akonadi fails to build
Summary: akonadi fails to build
Keywords:
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:
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)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
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:
Environment:
Last Closed: 2016-05-11 00:14:41 UTC
Target Upstream Version:
Embargoed:

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
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:0887 0 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:46 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.