[CMake] Clarifying Cmake behavior

[James Benze]

So I combed through the source code, and solved the problem, mostly.  It
did turn out to be a cmake issue, sort of, so I figured I'd post here for
posterity in case future problem solvers come across a similar issue.

So I'm using both a custom compiler and a custom set of boost libraries.
For simplicity, I installed them to the same prefix
(/path/to/custom/stuff).  Now cmake has a list of libraries that it thinks
are always looked in for link directories.  If you use a custom compiler
(/path/to/custom/stuff/bin/g++ for example), it adds that compiler's
libraries to it's "implicit link directories", ones that it assumes are
found automatically (in this case /path/to/custom/stuff/lib and
/path/to/custom/stuff/lib64).  Because my custom boost version was in this
library path (/path/to/custom/stuff/lib) cmake assumed that the compiler
could find them and just used the "-l" syntax with no RPATH set.  When I
used my control set of libraries, they were installed in a different prefix
(/path/to/test/boost/) so cmake says "oh you can't find these" and did the
full path linkage plus RPATH.

So my two solutions are as follows:

1) set LD_LIBRARY_PATH when building. In this case, everything links
correctly, although ld harmlessly complains about conflicts with the
distribution-installed libraries in /usr/lib/
2) Install boost in a different directory than my custom compiler.

Cheers, all.

On Tue, Mar 15, 2016 at 10:38 AM, James Benze <benzejaa at gmail.com> wrote:

> Hey all:
>
> I'm trying to compile boost with some weird options, and I can't get
> projects linked with it to compile correctly.  As using regularly compiled
> boost seems to work just fine, this indicates my issue is not with
> cmake...however I was hoping I could get some clarification on how cmake
> searches for things in order to diagnose my issue.
>
> I made a toy project here:
>
> cmake_minimum_required(VERSION 2.8.4)
> project(testproject)
>
> find_package(Boost 1.58.0 REQUIRED COMPONENTS thread)
> add_executable(a.out main.cpp)
> target_link_libraries(a.out ${Boost_LIBRARIES})
>
> When I build this project with the "good" normally compiled boost
> libraries, I get this CMakeFiles/a.out.dir/link.txt:
>
> /full/path/to/compiler/g++ CMakeFiles/a.out.dir/main.cpp.o -o a.out
> -rdynamic /full/path/to/good/boost/libboost_thread.so
> -Wl,-rpath,/full/path/to/good/boost
>
> When I build the project with the exact same options, except substituting
> the "bad" boost for the BOOST_ROOT variable, I get:
>
> /full/path/to/compiler/g++ CMakeFiles/a.out.dir/main.cpp.o -o a.out
> -rdynamic -lboost_thread
>
> The obvious differences here are that with the good boost libraries, we
> get a full path to the boost library and not a shortened path.
> Additionally, with the good library, I get a the rpath to the library set
> as well.  The ${Boost_LIBRARIES} variable is the full path to
> libboost_thread.so in both cases.
>
> This is obviously a problem with my boost compilation, but this is my only
> clue to diagnosing the problem.  I was hoping for some insight as to why
> cmake would choose one way of linking over another so I could attempt to
> fix my actual problem.
>
> Thanks!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160315/1d3d1de8/attachment.html>