<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 18, 2018 at 7:42 AM Paul Smith <<a href="mailto:paul@mad-scientist.net">paul@mad-scientist.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi all.<br>
<br>
I'm using cmake with a cross-compiler environment, but building third<br>
party packages that are configured with CMake.  So when I invoke cmake<br>
for those packages I add this options to the command line:<br>
<br>
  -DCMAKE_FIND_ROOT_PATH=/my/sysroot<br>
<br>
However, this is not working because it's finding 32bit libraries.  For<br>
example if the package's CMakeLists.txt file contains this:<br>
<br>
  find_package(ZLIB REQUIRED)<br>
<br>
then my link line ends up containing:<br>
<br>
  /my/sysroot/usr/lib/libz.so<br>
<br>
which is the 32bit version and the link fails.  The 64bit version DOES<br>
exist exactly as it should:<br>
<br>
  $ ls -1 /my/sysroot/usr/lib*/libz.so*<br>
  /my/sysroot/tools/usr/lib/libz.so<br>
  /my/sysroot/tools/usr/lib64/libz.so<br>
<br>
and the link works if I do it by hand with the right path.  I don't<br>
know why it's not automatically looking for lib64; I checked and CMake<br>
knows I want a 64bit build.  For example I see this after running:<br>
<br>
  CMakeFiles/3.11.3/CMakeCXXCompiler.cmake:set(CMAKE_CXX_SIZEOF_DATA_PTR "8")<br>
<br>
Actually I wish cmake would just add "-lz" to the command line and let<br>
the linker figure it all out rather than trying to second-guess things.<br>
Then it would "just work".<br>
<br>
In any event, if I edit the CMakeLists.txt in the package to set the<br>
global property FIND_LIBRARY_USE_LIB64_PATHS to ON, then it all works<br>
fine:<br>
<br>
  set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS ON)<br>
<br>
But I can't see any way to set that property from the command line,<br>
without editing the package's CMakeLists.txt file which I obviously<br>
don't want to do.<br>
<br>
Help for either (a) figuring out why cmake incorrectly chooses 32bit<br>
libraries or (b) setting the property without editing third-party<br>
CMakeLists.txt files would be much appreciated!!<br>
</blockquote></div><div><br></div><div><br></div>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.<div><br></div><div>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 <a href="https://cmake.org/cmake/help/latest/variable/CMAKE_PROJECT_PROJECT-NAME_INCLUDE.html">CMAKE_PROJECT_<projectName>_INCLUDE</a> 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.<br clear="all"><div><br></div><div>Those techniques aside, it's interesting that you need to add this manual workaround at all. I suspect <a href="https://gitlab.kitware.com/cmake/cmake/blob/v3.13.2/Modules/Platform/Linux.cmake#L55">this code</a> 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.</div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr">Craig Scott<br><div>Melbourne, Australia</div><div><a href="https://crascit.com" target="_blank">https://crascit.com</a><br></div><div><br></div><div>New book released: <a href="https://crascit.com/professional-cmake/" target="_blank">Professional CMake: A Practical Guide</a><br></div></div></div></div></div></div></div></div></div>