2

In the following snippet from the Google tutorial 'Add C and C++ Code to Your Project'

In the section 'Add other prebuilt libraries'

add_library(...)
set_target_properties( # Specifies the target library.
                       imported-lib

                       # Specifies the parameter you want to define.
                       PROPERTIES IMPORTED_LOCATION

                       # Provides the path to the library you want to import.
                       imported-lib/src/${ANDROID_ABI}/libimported-lib.so )

source: https://developer.android.com/studio/projects/add-native-code.html

What is the implicit root directory associated with imported-lib/src/${ANDROID_ABI}/libimported-lib.so ?

My 1st guess was that it was project/app/ i.e. the directory where CMakeLists.txt resides, but experimentation suggests this is not the case. I get link errors saying the functions in the shared library cannot be found when I make this assumption.

Update:

Further to Tsyvarev s help I've realised the error is not from set_target_properties() but target_link_libraries()

set_target_properties() does seem to use project/app as its root

but target_link_libraries() doesn't. If I assume project/app as the root for my prebuilt shared library location then my project build fails. If I specify the full path, i.e. from /home/me/...etc./etc./mylib.so then it does work.

The error message in the 1st instance is:

/home/me/Android/Sdk/ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/lib/gcc/arm-linux-androideabi/4.9.x/../../../../arm-linux-androideabi/bin/ld: error: cannot find -llibs/armeabi-v7a/libmylib.so

maybe the root dir in this instance is that in which ld is located?

bph
  • 10,728
  • 15
  • 60
  • 135
  • 1
    `I get link errors saying the functions in the shared library cannot be found when I make this assumption.` - This error means that your shared library doesn't define given functions. Or that you forgot to link with that library (using `target_link_libraries`). If linker fails to find the library for link with, then it emits **other error**. – Tsyvarev Jun 16 '17 at 16:07

1 Answers1

2

According to the documentation for IMPORTED_LOCATION property, it should be explicitely specified as a full path:

Full path to the main file on disk for an IMPORTED target.

If you want this path to be under current source directory, prepend it with ${CMAKE_CURRENT_SOURCE_DIR}/.

Specifying relative path is just an undefined behavior.

In your case CMake simply passes the path to the linker (that is, linker searches it under system library directories and ones added with link_directories() command). But this behavior, as non-documented, may be changed in the future at any time.

Tsyvarev
  • 60,011
  • 17
  • 110
  • 153
  • current source dir being that which CMakeLists.txt resides in. See related question -> https://stackoverflow.com/questions/15662497/in-cmake-what-is-the-difference-between-cmake-current-source-dir-and-cmake-curr – bph Jun 19 '17 at 11:20
  • `Specifying relative path is just an undefined behavior.` This is really true! I was following this tutorial http://irrlicht.sourceforge.net/forum/viewtopic.php?f=5&t=52182 and I had to replace `src/main/cpp/main.cpp` with `${CMAKE_CURRENT_SOURCE_DIR}/main.cpp`. – FonzTech Dec 22 '20 at 23:53
  • @FonzTech: Relative paths to the source files in `add_library` or `add_executable` are perfectly acceptible: CMake automatically transforms them to the absolute paths relative to the current source or binary directory. But `IMPORTED_LOCATION` property should be an absolute path: this path isn't automatically translated to the absolute. – Tsyvarev Dec 23 '20 at 00:19
  • I tried playing with paths and now I managed to add my cpp files through relative paths. Anyway, your answer helped me figuring out the problem. – FonzTech Dec 24 '20 at 10:33