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.

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.

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.

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

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.

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.

FWIW, the solution is to build with -DBoost_NO_BOOST_CMAKE=TRUE

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.

Here is the buildlog from EPEL koji for the failed paraview build:

https://kojipkgs.fedoraproject.org//work/tasks/5000/10455000/build.log

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.

Bug 1245805 is related and still open, unlike this bug.

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

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.