Re: [CMake] Clarifying Cmake behavior
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 visit: CMake Support: http://cmake.org/cmake/help/support.html
Re: [CMake] Clarifying Cmake behavior
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
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