Bug 849791 - boost-devel ships a broken Boost-relwithdebinfo.cmake file
boost-devel ships a broken Boost-relwithdebinfo.cmake file
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: boost (Show other bugs)
6.4
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Petr Machata
qe-baseos-tools
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-20 17:29 EDT by Kai Meyer
Modified: 2015-08-19 09:11 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-02-04 15:10:40 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
An example CMake configuration file. (746 bytes, application/x-download)
2012-08-20 17:29 EDT, Kai Meyer
no flags Details

  None (edit)
Description Kai Meyer 2012-08-20 17:29:10 EDT
Created attachment 605782 [details]
An example CMake configuration file.

Description of problem:
Using cmake-2.8 (either from epel or from upstream) breaks boost library paths.
http://www.gccxml.org/Bug/bug_relationship_graph.php?bug_id=13446&graph=dependency
http://stackoverflow.com/questions/9948375/cmake-find-package-succeeds-but-returns-wrong-path/12044891#12044891


Version-Release number of selected component (if applicable):
boost-devel-1.41.0-11.el6.x86_64
boost-devel-1.41.0-11.el6.i686


How reproducible:
By using CMake to build a project that links against boost libraries.

Steps to Reproduce:
1. Extract the two files in the attached zip. (boost-test.cpp, CMakeLists.txt) and put them in the same directory (say ~/boost-test/)
2. Make a build-directory and run cmake (say: mkdir -p ~/boost-test/build; cd ~/boost-test/build; cmake ..; make). If you are using the cmake package from cmake28-2.8.8, run 'cmake28 ..' instead.
  
Actual results:
Using cmake 2.6 will link correctly. Using cmake 2.8 will fail to find the boost libraries in /usr/lib64/lib64.

Expected results:
For cmake 2.8 to link against boost libraries correctly.

Additional info:
This problem exists in the boost-devel package in the file:
/usr/lib64/boost/Boost-relwithdebinfo.cmake
Or on 32bit platforms:
/usr/lib/boost/Boost-relwithdebinfo.cmake

The shipped version of cmake in RHEL 6 is 2.6, which contains:
/usr/share/cmake/Modules/FindBoost.cmake
This cmake file does not require the use of Boost-relwithdebinfo.cmake to find the boost libraries. Cmake version 2.8 (I think .3+) does, and will break with out a fix.

I am satisfied with the fix being to duplicate line 10 to appear twice in a row:
GET_FILENAME_COMPONENT(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)

Either that, or fix all the lines like this:
  IMPORTED_LOCATION_RELWITHDEBINFO "${_IMPORT_PREFIX}/lib64/libboost_date_time-mt.a"

With this:
  IMPORTED_LOCATION_RELWITHDEBINFO "${_IMPORT_PREFIX}/libboost_date_time-mt.a"

Fixing this file should not break any cmake2.6 functionality, and fix 2.8 functionality. If it would be helpful, I would happily work on fixing the problem in a sourcerpm, and submitting that patch, but I didn't want to delay the report.
Comment 2 Kai Meyer 2012-08-20 17:51:34 EDT
In addition, it also fails to link against debug versions of libraries, since there is a separate debug-info package that contains that information. For instance, with the same two files above, try running cmake with:
cmake28 -DCMAKE_BUILD_TYPE=Debug

The make will fail with an error like this:
$ make
Scanning dependencies of target boost-test
[100%] Building CXX object CMakeFiles/boost-test.dir/boost-test.cpp.o
make[2]: *** No rule to make target `/usr/lib64/libboost_regex-mt-d.so.5', needed by `boost-test'.  Stop.
make[1]: *** [CMakeFiles/boost-test.dir/all] Error 2
make: *** [all] Error 2

I think this because boost-devel does not ship un-stripped versions of the libraries, but instead simply links to the .so.5 libraries from the boost-<component> pacakges, like so:
/usr/lib64/libboost_regex-mt.so -> libboost_regex-mt.so.5 (boost-devel)
/usr/lib64/libboost_regex-mt.so.5 (boost-regex)
/usr/lib64/libboost_regex.so -> libboost_regex.so.5 (boost-devel)
/usr/lib64/libboost_regex.so.5 (boost-regex)

FindBoost.cmake expects an unstripped debug version available at:
/usr/lib64/libboost_regex-mt-d.so.5

The behavior of cmake 2.6 is to simply use the release versions every time.

I can't say I have an opinion on whether we should add symlinks for the -d.so.5 files, and require the debug-info package to step through boost libs, or have the debug-info package come with the symlinks, or have boost-devel ship the unstripped versions of the debug libraries. But it would be nice if this worked with cmake 2.8, and can be easily done with out disrupting current cmake 2.6 functionality.
Comment 3 RHEL Product and Program Management 2012-09-07 01:29:23 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.
Comment 4 Steven P. Ulrick 2013-03-04 15:39:06 EST
I am running a fully updated install of Fedora 17 and I have the exact same problem that the original reporter of this bug is having.
Comment 5 Petr Machata 2013-03-08 13:54:08 EST
(In reply to comment #0)
> This problem exists in the boost-devel package in the file:
> /usr/lib64/boost/Boost-relwithdebinfo.cmake
> Or on 32bit platforms:
> /usr/lib/boost/Boost-relwithdebinfo.cmake
> 
> The shipped version of cmake in RHEL 6 is 2.6, which contains:
> /usr/share/cmake/Modules/FindBoost.cmake
> This cmake file does not require the use of Boost-relwithdebinfo.cmake to
> find the boost libraries. Cmake version 2.8 (I think .3+) does, and will
> break with out a fix.
> 
> [...] fix all the lines like this:
>   IMPORTED_LOCATION_RELWITHDEBINFO
> "${_IMPORT_PREFIX}/lib64/libboost_date_time-mt.a"
> 
> With this:
>   IMPORTED_LOCATION_RELWITHDEBINFO
> "${_IMPORT_PREFIX}/libboost_date_time-mt.a"

Thanks for analysis, this is very helpful.  I'll see what works.  We ship cmake 2.6 with RHEL 6, so not breaking that is rather important.

(In reply to comment #2)
> In addition, it also fails to link against debug versions of libraries,
> since there is a separate debug-info package that contains that information.
> For instance, with the same two files above, try running cmake with:
> cmake28 -DCMAKE_BUILD_TYPE=Debug
> 
> The make will fail with an error like this:
> $ make
> Scanning dependencies of target boost-test
> [100%] Building CXX object CMakeFiles/boost-test.dir/boost-test.cpp.o
> make[2]: *** No rule to make target `/usr/lib64/libboost_regex-mt-d.so.5',
> needed by `boost-test'.  Stop.
> make[1]: *** [CMakeFiles/boost-test.dir/all] Error 2
> make: *** [all] Error 2

That's because we don't ship debug versions of libraries at all.  What we ship is a stripped RelWithDebuginfo build.  The stripped part is in -debuginfo subpackage.  We don't even build -d variants at all.

> I think this because boost-devel does not ship un-stripped versions of the
> libraries, but instead simply links to the .so.5 libraries from the
> boost-<component> pacakges, like so:
> /usr/lib64/libboost_regex-mt.so -> libboost_regex-mt.so.5 (boost-devel)
> /usr/lib64/libboost_regex-mt.so.5 (boost-regex)
> /usr/lib64/libboost_regex.so -> libboost_regex.so.5 (boost-devel)
> /usr/lib64/libboost_regex.so.5 (boost-regex)

These libX.so symlinks make it possible to use -lX on a compiler command line.  That's not specific to boost, or to our way of shipping it.

> FindBoost.cmake expects an unstripped debug version available at:
> /usr/lib64/libboost_regex-mt-d.so.5

Maybe we should patch it so that it doesn't assume existence of -d builds.  Thus it would be possible to build debug build of given project even though actual boost libraries that that project links to are not debug.

> The behavior of cmake 2.6 is to simply use the release versions every time.
> 
> I can't say I have an opinion on whether we should add symlinks for the
> -d.so.5 files, and require the debug-info package to step through boost
> libs, or have the debug-info package come with the symlinks, or have
> boost-devel ship the unstripped versions of the debug libraries. But it
> would be nice if this worked with cmake 2.8, and can be easily done with out
> disrupting current cmake 2.6 functionality.

The -d libraries are not simply unstripped, it's a fully separate build variant.  We could still provide symlinks from X-d.so to X.so, I guess, I can't immediately find why it should break, and it would be by far the simplest solution.
Comment 6 Kai Meyer 2013-03-08 14:33:49 EST
I'm not as concerned about generating the -d build variant, as I am being able to build a Debug configuration of a given project. I rarely need anything more than the regular debuginfo packages shipped by RHEL, as I am almost always the source of my own bugs :)

I think I would be satisfied with any solution that allows the attached sample project in comment #1 build correctly with both cmake and cmake28 for both Release (default) and Debug configurations.

Thanks for looking into this.
Comment 7 Jeff Law 2014-02-04 15:10:40 EST
After further discussions with Petr, I'm closing this as WONTFIX.

While we ship the cmake files for boost, that's because we used cmake to build boost shipping the cmake files themselves was never intentional and was never meant to imply support for using those shipped cmake files to build stuff.
Comment 8 Jeroen van Meeuwen 2014-11-12 15:31:54 EST
FWIW, the solution is to build with -DBoost_NO_BOOST_CMAKE=TRUE
Comment 9 Johnny Hughes 2015-07-23 19:53:28 EDT
Well, the version of cmake and boost shipped with RHEL 6.7 means that things in EPEL that use boost (for example, paraview):

 https://kojipkgs.fedoraproject.org//packages/paraview/

Will no longer build.

Using cmake 2.6 from RHEL 6.5 to build boost (instead of cmake 2.8 that is included in RHEL 6.7) will create boost RPMs that will build said packages with boost.
Comment 10 Johnny Hughes 2015-07-23 19:57:39 EDT
Here is the buildlog from EPEL koji for the failed paraview build:

https://kojipkgs.fedoraproject.org//work/tasks/5000/10455000/build.log
Comment 11 Anssi Johansson 2015-07-24 12:58:03 EDT
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 12 Anssi Johansson 2015-07-26 12:17:40 EDT
Bug 1245805 is related and still open, unlike this bug.
Comment 13 Jonathan Wakely 2015-07-27 05:28:23 EDT
(In reply to Johnny Hughes from comment #10)
> Here is the buildlog from EPEL koji for the failed paraview build:
> 
> https://kojipkgs.fedoraproject.org//work/tasks/5000/10455000/build.log

That package uses the unsupported cmake files. As it says in comment 7:

  shipping the cmake files themselves was never intentional and was never meant
  to imply support for using those shipped cmake files to build stuff.

Comment 8 seems to have the solution.
Comment 14 Kai Meyer 2015-07-27 12:06:37 EDT
Simply deleting the files also solves the problem.

rpm -ql boost-devel | grep 'cmake$' | xargs rm

In comment 3, the reason for not fixing this issue was described as:
"Because the affected component is not scheduled to be updated
in the current release..."
I always took the component to be "cmake", not "boost". Since cmake did get an update, does that mean we are justified to ask to revisit the decision?

In comment 7, it's expanded to say:
"...shipping the cmake files themselves was never intentional..."
Since this is the case, and deleting the files entirely resolve the issue, the resolution seems clear.

I'd like to see a patch to remove the cmake files from boost-devel to more properly resolve the issue.

If not, there's always comment 8, which is basically asking maintainers to have this particular domain specific knowledge when building their software for RHEL 6.7. Bug 1245805 is evidence that this approach is, at the very least, annoying.

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