Re: [CMake] Clarifying Cmake behavior

[James Benze]

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

Re: [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  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

[CMake] Clarifying Cmake behavior

[James Benze]

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