Bug 1245805

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.

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.

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.

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?

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.

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.

(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.

I can confirm that using '-DBoost_NO_BOOST_CMAKE=ON' makes Akonadi to build again.

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.

Yes, tt's going to be fixed in Boost, which is the component of the bug.

Created attachment 1096003 [details]
Patch spec file to not install .cmake files

Fixing this is very simple once it's acked.

Verified with build boost-1.41.0-28.el6, rebuild of akonadi (from SRPM) passes.

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