cmake multi sub projects : problem with path of lib

Usage
1

Hi,

I have a project with sub projects :

    ├── CMakeLists.txt
    ├── projects
        ├── libA
        │   ├── CMakeLists.txt
        │   ├── include
        │   │   └── libA
        │   │       └── my_liba.h
        │   ├── src
        │   │   └── my_liba.cpp
        │   └── test
        ├── libB
        │   ├── CMakeLists.txt
        │   ├── include
        │   │   └── libB
        │   │       └── my_libb.h
        │   ├── src
        │   │   └── my_libb.cpp
        │   └── test
        └── runner
            ├── CMakeLists.txt
            └── src
                └── main.cpp

My problem is that the runner is compiled with the path to the libA and libB :

gcc-linaro-…-mingw32_arm-linux-gnueabihf\bin\arm-linux-gnueabihf-gcc.exe -LC:/openssl/lib -ldl -llzma -lz -lrt -lpthread projects/libA/libA.so projects/libB/libB.so

In the runner CmakeList file I have:

target_link_libraries (runner
libA
libB
)
On My raspberry pi device, I don’t have a folder projects …

2

What is produced is planned to be used in situ.

If you want to distribute the artifacts, you have to install then (see install() command). The installation process handle to update binaries (or relink them) to enable portable usage…

See also various RPATH variables and properties to control the way libraries are linked.

3

Thanks for the answer.

I added:
install(TARGETS ${project_name} DESTINATION Debug)

and I tried:

set(CMAKE_BUILD_RPATH_USE_ORIGIN TRUE)
set(CMAKE_SKIP_RPATH TRUE)
set(CMAKE_SKIP_BUILD_RPATH TRUE)
SET(CMAKE_SKIP_BUILD_RPATH TRUE)

But it didn’t work :frowning:

I still have the path of the lib in my executable.

What is the correct way to edit the executable and remove the path of the lib inside ?

4

I would like cmake use this :

gcc ... -L /home/projects/my_files -lwinter_fresh

and not:

gcc ... /home/projects/my_files/libwinter_fresh.so

I have used :

target_link_directories( ${project_name} PRIVATE
   ${project_lib_path}
)
target_link_libraries (${project_name}
libA
libB
)
5

I found a way to fix my problem, but it’s not the best one … it’s not clean.

target_link_libraries (${project_name}
-llibA
-llibB
)

I added -l before each lib

6

CMake vastly prefers to say “use this file” rather than (re-)construct a set of flags to lead the linker to the same conclusion. What’s the problem that using full paths causes?

7

My problem is that the path of the lib is built into my executable. And in my remote machine this path doesn’t exist.

And cmake doesn’t remove the path with install…

8

Is the library to be linked with maybe missing an SONAME?

9

In what way? Can you provide the readelf -d $lib output of the file that fails when using full paths? A missing SONAME could cause something like this (though I’m not familiar with embedded idiosyncrasies).

10

Thanks,

My project has:

0x00000001 (NEEDED) Shared library: [libdl.so.2]
0x00000001 (NEEDED) Shared library: [liblzma.so.5]
0x00000001 (NEEDED) Shared library: [libz.so.1]
0x00000001 (NEEDED) Shared library: [librt.so.1]
0x00000001 (NEEDED) Shared library: [libpthread.so.0]
0x00000001 (NEEDED) Shared library: [libxml2.so.2]
0x00000001 (NEEDED) Shared library: [libsqlite3.so.0]
0x00000001 (NEEDED) Shared library: [projects/LibA/libA.so]
0x00000001 (NEEDED) Shared library: [projects/LibBt/libB.so]
0x00000001 (NEEDED) Shared library: [projects/LibC/libC.so]
0x00000001 (NEEDED) Shared library: [libcrypto.so.1.1]
0x00000001 (NEEDED) Shared library: [libc.so.6]

I have edited /etc/ld.so.conf.to add libA.so in the LD_LIBRARY_PATH .
But it doesn’t work, That’s why I would like to delete the path projects/LibA projects/LibB projects/LibC

11

I would suggest instead setting a SONAME for those libraries. Alternatively, you can change their LIBRARY_OUTPUT_DIRECTORY property to place them in a better location in the build tree to avoid these paths. But the SONAME is the better solution here.

12

Are you installing the project to a local directory prior to distributing it to the remote system? That should be preferred (instead of taking the binaries directly from the build tree).

13

Thanks,

Ok I will try with the SONAME.

Is it enough to make a lib with SONAME =>

project(${project_name} VERSION 1.0.0)
SET_PROPERTY(GLOBAL PROPERTY TARGET_SUPPORTS_SHARED_LIBS TRUE)

option(BUILD_SHARED_LIBS “Build using shared libraries” ON)

add_library(${project_name} ${files})

14

I found out what was my problem =>
this was needed in my toolchain file :
SET(CMAKE_SHARED_LIBRARY_SONAME_C_FLAG “-Wl,-soname,”)

now I have after install on my WINDOWS machine :
libA.so
libA.so.1
libA.so.1.0.0

When I copy it into my linux machine, I have with ldconfig :

libA.so.1 is not a symbolic link

I should copy files with extension so.1.0.0 and make a symbolic link to libA.so and libA.so.1 ?

Thanks,

15

That’s weird as it’s set in uncoditional in Platform/Linux.cmake. Does your toolchain file properly setup cross-compiling to Linux, e.g. sets CMAKE_SYSTEM_NAME?

16

You are right,

I had SET(CMAKE_SYSTEM_NAME Generic) switching to Linux works also. Thanks.