Please provide all your cmake options.

Are you sure that you
a) haven't upgraded the system recently (e.g. cmake version)?
b) really can compile 10.0.14 from scratch, after you remove CMakeCache.txt file?

If it's a "Yes" for b), could you please remove CMakeCache.txt for both, re-run cmake (which will pass for 10.0.14 and fail for 1.0.15), and paste output of cmake . -LA for both?

Thanks.

Elena,

As previously posted, yes I can compile 10.0.14 with same identical setup. Why do I have to compile it "from scratch"? I compile it with a standard rpmbuild, you don't compile neither your packages "from scratch" but rather use the UseRPMTools CMake module.

The issue is simple, there is a double concatenation for "/lib64". Can you please let me know in what file this occurs? I will create the patch myself.

Floren,

"From scatch" in this context was just a short word for "after you remove CMakeCache.txt". And yes, we do actually build our packages on a clean source dir without a previously saved CMakeCache.
And no, you don't have to compile any particular way, it was requested as an experiment in order to make the answer more obvious and spare further argument. Apparently it was a wishful thinking.
But never mind, we can do it your way.

The issue is simple, there is a double concatenation for "/lib64". Can you please let me know in what file this occurs? I will create the patch myself.

It occurs in /usr/lib64/boost/Boost-relwithdebinfo.cmake. Please feel free to submit a patch to boost.
See more details here: http://stackoverflow.com/questions/21214045/got-usr-lib64-lib64-while-using-cmake-with-boost

And yes, it fails exactly the same way on 10.0.14. My guess is that you upgraded cmake recently (maybe unknowingly, as a part of system upgrade). Without the requested output of cmake . -LA I'll refrain from guessing why it still works for you on 10.0.14.

Thanks for the report, we might need to consider prohibiting certain combinations of cmake/boost or look into other workarounds.

serg,

Summary of the above:

Apparently CentOS 6.x recently upgraded cmake from 2.6.x to 2.8.12. A lovely mix of it and boost 1.41 causes the error quoted in the description.

The problem is described here:
http://stackoverflow.com/questions/9948375/cmake-find-package-succeeds-but-returns-wrong-path
http://stackoverflow.com/questions/21214045/got-usr-lib64-lib64-while-using-cmake-with-boost

RHEL might also be affected.

I don't know if it's possible to get the cmake option mentioned in the first link work, if so, it should probably be done. Otherwise we might have to make our cmake config more picky about versions of cmake and boost.

Elena,

You are correct, I just compiled yesterday MariaDB 10.0.14 with cmake 2.8.12 and boost 1.41, it fails at same place. My apologies, I was able to compile successfully 10.0.14 prior RHEL 6.6 upgrade. Do you know if the issue still occurs with boost 1.53+? I will create a more updated boost rpm, instead of fiddling with patches.

Floren,

Do you know if the issue still occurs with boost 1.53+

I can't tell for sure. I know that our build machines use cmake 2.8.12 and boost 1.49 and build successfully, but it might be because we use a source build of boost. As I understand, the erroneous files come not from boost repo, but from RHEL packages of boost, so maybe if you create RPMs yourself, you won't have the problem at all.
serg might know more details and correct me if I'm wrong.

Upd: also found this https://bugzilla.redhat.com/show_bug.cgi?id=849791

Elena,

Can you compile fine 10.0.15 on RHEL7 with base rpms? If you do, then boost 1.53+ should work. I'll build boost 1.55 rpm for RHEL 6.6 and report back to see if I get same error.

We build on CentOS 7 with cmake 2.8.11 and boost 1.53, yes. However, I'm not sure whether it's boost from RHEL rpms or a from a source build (can't reach the machine to check).