I did a bit more searching around, and, for me at least, setting
Boost_REALPATH on also seems to be a valid solution to the problem, as the
linker will no longer get confused between the system installed libraries
and my custom ones. I dunno if that works in all situations, but it seems
to be the cleanest solution to what I'm doing.
On Tue, Mar 15, 2016 at 5:16 PM, Elizabeth Fischer <rpf2...@columbia.edu>
wrote:
> Something is wrong here. In 99% of the cases I've seen, it is not
> necessary to set LD_LIBRARY_PATH. That env var is evil, and should be used
> only as a last resort, and temporarily at that. There must be a better
> way...
>
>
> On Tue, Mar 15, 2016 at 2:38 PM, James Benze <benze...@gmail.com> wrote:
>
>> 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
>>
>
>
--
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
