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 <benze...@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! >
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake