On Tue, Dec 18, 2018 at 7:42 AM Paul Smith <p...@mad-scientist.net> wrote:
> Hi all. > > I'm using cmake with a cross-compiler environment, but building third > party packages that are configured with CMake. So when I invoke cmake > for those packages I add this options to the command line: > > -DCMAKE_FIND_ROOT_PATH=/my/sysroot > > However, this is not working because it's finding 32bit libraries. For > example if the package's CMakeLists.txt file contains this: > > find_package(ZLIB REQUIRED) > > then my link line ends up containing: > > /my/sysroot/usr/lib/libz.so > > which is the 32bit version and the link fails. The 64bit version DOES > exist exactly as it should: > > $ ls -1 /my/sysroot/usr/lib*/libz.so* > /my/sysroot/tools/usr/lib/libz.so > /my/sysroot/tools/usr/lib64/libz.so > > and the link works if I do it by hand with the right path. I don't > know why it's not automatically looking for lib64; I checked and CMake > knows I want a 64bit build. For example I see this after running: > > CMakeFiles/3.11.3/CMakeCXXCompiler.cmake:set(CMAKE_CXX_SIZEOF_DATA_PTR > "8") > > Actually I wish cmake would just add "-lz" to the command line and let > the linker figure it all out rather than trying to second-guess things. > Then it would "just work". > > In any event, if I edit the CMakeLists.txt in the package to set the > global property FIND_LIBRARY_USE_LIB64_PATHS to ON, then it all works > fine: > > set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS ON) > > But I can't see any way to set that property from the command line, > without editing the package's CMakeLists.txt file which I obviously > don't want to do. > > Help for either (a) figuring out why cmake incorrectly chooses 32bit > libraries or (b) setting the property without editing third-party > CMakeLists.txt files would be much appreciated!! > If you are setting your own sysroot, are you using a toolchain file? You could put your set_property() command in your toolchain file if you're using one. If you're not using a toolchain file and don't want to go that route, you could potentially inject the commands you want using the CMAKE_PROJECT_<projectName>_INCLUDE <https://cmake.org/cmake/help/latest/variable/CMAKE_PROJECT_PROJECT-NAME_INCLUDE.html> feature. It allows you to effectively include a file immediately after a project() command without having to actually edit the CMakeLists.txt that contains that project() command. Those techniques aside, it's interesting that you need to add this manual workaround at all. I suspect this code <https://gitlab.kitware.com/cmake/cmake/blob/v3.13.2/Modules/Platform/Linux.cmake#L55> might be why it is being turned off for you, but without more detail about your build setup, it's hard to say. If you use a toolchain file and set CMAKE_SYSTEM_NAME to anything (even the same as the CMAKE_HOST_SYSTEM_NAME), CMAKE_CROSSCOMPILING will be TRUE, which I suspect would prevent the problem you're seeing. -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide <https://crascit.com/professional-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: https://cmake.org/mailman/listinfo/cmake
