find_library fails when cross compiling

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

find_library fails when cross compiling

Oliver Dain
Hi,

I have some find_library lines like the following:

find_library(protobuf_protobuf protobuf PATHS /Users/oliverdain/Documents/code/revl/.install/${ARCH}/${VARIANT}/protobuf/3.4.1.r1/lib NO_DEFAULT_PATH )
target_link_libraries(ml_editing PUBLIC ${protobuf_protobuf})

These work find when $ARCH and $VARIANT are set to OSX and either Debug or Release (my target system). However, If I run

cmake -H. -B/Users/oliverdain/Documents/code/revl/cpp/build/build/IPHONE/Release -DCMAKE_TOOLCHAIN_FILE=ios.toolchain.cmake -DIOS_PLATFORM=OS -DCMAKE_BUILD_TYPE=Release -DARCH=IPHONE -DVARIANT=Release

the libraries are reported not found (the standard "CMake Error: The following variables are used in this project, but they are set to NOTFOUND." error) even though the libraries are in the specified location. For example, it says it can't find the protobuf libs but an ls yields:

$ ls /Users/oliverdain/Documents/code/revl/.install/IPHONE/Release/protobuf/3.4.1.r1/lib
cmake libprotobuf-lite.a libprotobuf.a pkgconfig

Note that if I change the NO_DEFAULT_PATH specification in the find_library line to NO_CMAKE_FIND_ROOT_PATH everything works as expected and the libs are found and linked (and I know its the right libs because things also run).

Is this a bug or is there something I don't understand about NO_DEFAULT_PATH?

Thanks,
Oliver

PS: I know the hard coded full path names are odd - the CMakeLists.txt files are actually generated -- it's a long story.

--

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
Reply | Threaded
Open this post in threaded view
|

Re: find_library fails when cross compiling

Oliver Dain
In case anyone else hits this, I figured it out. The issue was that our toolchain file specified "CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY" which meant it was ignoring our PATH list. Changing it to "CMAKE_FIND_ROOT_PATH_MODE_LIBRARY BOTH" solved the issue.

On Mon, Mar 26, 2018 at 6:06 PM Oliver Dain <[hidden email]> wrote:
Hi,

I have some find_library lines like the following:

find_library(protobuf_protobuf protobuf PATHS /Users/oliverdain/Documents/code/revl/.install/${ARCH}/${VARIANT}/protobuf/3.4.1.r1/lib NO_DEFAULT_PATH )
target_link_libraries(ml_editing PUBLIC ${protobuf_protobuf})

These work find when $ARCH and $VARIANT are set to OSX and either Debug or Release (my target system). However, If I run

cmake -H. -B/Users/oliverdain/Documents/code/revl/cpp/build/build/IPHONE/Release -DCMAKE_TOOLCHAIN_FILE=ios.toolchain.cmake -DIOS_PLATFORM=OS -DCMAKE_BUILD_TYPE=Release -DARCH=IPHONE -DVARIANT=Release

the libraries are reported not found (the standard "CMake Error: The following variables are used in this project, but they are set to NOTFOUND." error) even though the libraries are in the specified location. For example, it says it can't find the protobuf libs but an ls yields:

$ ls /Users/oliverdain/Documents/code/revl/.install/IPHONE/Release/protobuf/3.4.1.r1/lib
cmake libprotobuf-lite.a libprotobuf.a pkgconfig

Note that if I change the NO_DEFAULT_PATH specification in the find_library line to NO_CMAKE_FIND_ROOT_PATH everything works as expected and the libs are found and linked (and I know its the right libs because things also run).

Is this a bug or is there something I don't understand about NO_DEFAULT_PATH?

Thanks,
Oliver

PS: I know the hard coded full path names are odd - the CMakeLists.txt files are actually generated -- it's a long story.

--

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