On Linux the CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES detected by CMake is different from the default search path of linker

[traversaro]

In CMake the variable CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES contains the link directories that the linker already considers by default, and you can easily check its value by a the example provided in https://gist.github.com/traversaro/1d6e3bb4e737ba80ef6ad255e3734a32 :

(cmake-tests) traversaro@IITICUBLAP102:~$ git clone https://gist.github.com/traversaro/1d6e3bb4e737ba80ef6ad255e3734a32
Cloning into '1d6e3bb4e737ba80ef6ad255e3734a32'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), 340 bytes | 113.00 KiB/s, done.
(cmake-tests) traversaro@IITICUBLAP102:~$ cd 1d6e3bb4e737ba80ef6ad255e3734a32/
(cmake-tests) traversaro@IITICUBLAP102:~/1d6e3bb4e737ba80ef6ad255e3734a32$ cmake .
-- CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES: /home/traversaro/miniconda3/envs/cmake-tests/lib;/home/traversaro/miniconda3/envs/cmake-tests/lib/gcc/x86_64-conda-linux-gnu/9.3.0;/home/traversaro/miniconda3/envs/cmake-tests/lib/gcc;/home/traversaro/miniconda3/envs/cmake-tests/x86_64-conda-linux-gnu/lib;/home/traversaro/miniconda3/envs/cmake-tests/x86_64-conda-linux-gnu/sysroot/lib;/home/traversaro/miniconda3/envs/cmake-tests/x86_64-conda-linux-gnu/sysroot/usr/lib
-- Configuring done
-- Generating done
-- Build files have been written to: /home/traversaro/1d6e3bb4e737ba80ef6ad255e3734a32

The CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES is used by CMake for automatically ignoring this directories if a build system pass them to the link_directories command. However, on conda-forge, it seems that the linker default search path to do not match the search path of the linker (see https://stackoverflow.com/questions/9922949/how-to-print-the-ldlinker-search-path):

(cmake-tests) traversaro@IITICUBLAP102:~/1d6e3bb4e737ba80ef6ad255e3734a32$ ld --verbose | grep SEARCH_DIR | tr -s ' ;' \\012
SEARCH_DIR("=/home/conda/feedstock_root/build_artifacts/binutils_split_1605279079140/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeh/x86_64-conda-linux-gnu/lib64")
SEARCH_DIR("=/usr/local/lib64")
SEARCH_DIR("=/lib64")
SEARCH_DIR("=/usr/lib64")
SEARCH_DIR("=/home/conda/feedstock_root/build_artifacts/binutils_split_1605279079140/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeh/x86_64-conda-linux-gnu/lib")
SEARCH_DIR("=/usr/local/lib")
SEARCH_DIR("=/lib")
SEARCH_DIR("=/usr/lib")

In particular, ld seems to use non-relocatable directories in its search path.

Environment (conda list):

$ conda list
(cmake-tests) traversaro@IITICUBLAP102:~/1d6e3bb4e737ba80ef6ad255e3734a32$ conda list
# packages in environment at /home/traversaro/miniconda3/envs/cmake-tests:
#
# Name                    Version                   Build  Channel
_libgcc_mutex             0.1                 conda_forge    conda-forge
_openmp_mutex             4.5                       1_gnu    conda-forge
binutils                  2.35.1               hdd6e379_0    conda-forge
binutils_impl_linux-64    2.35.1               h17ad2fc_0    conda-forge
binutils_linux-64         2.35                hc3fd857_29    conda-forge
bzip2                     1.0.8                h7b6447c_0
c-compiler                1.1.2                h7f98852_0    conda-forge
ca-certificates           2020.11.8            ha878542_0    conda-forge
cmake                     3.19.1               h1f3970d_0    conda-forge
compilers                 1.1.2                ha770c72_0    conda-forge
cxx-compiler              1.1.2                h4bd325d_0    conda-forge
expat                     2.2.10               he6710b0_2
fortran-compiler          1.1.2                h1990efc_0    conda-forge
gcc_impl_linux-64         9.3.0               h28f5a38_17    conda-forge
gcc_linux-64              9.3.0               h7247604_29    conda-forge
gfortran_impl_linux-64    9.3.0               h2bb4189_17    conda-forge
gfortran_linux-64         9.3.0               ha1c937c_29    conda-forge
gxx_impl_linux-64         9.3.0               h53cdd4c_17    conda-forge
gxx_linux-64              9.3.0               h0d07fa4_29    conda-forge
kernel-headers_linux-64   2.6.32              h77966d4_13    conda-forge
krb5                      1.18.2               h173b8e3_0
ld_impl_linux-64          2.35.1               hed1e6ac_0    conda-forge
libcurl                   7.71.1               h20c2e04_1
libedit                   3.1.20191231         h14c3975_1
libgcc-devel_linux-64     9.3.0               hfd08b2a_17    conda-forge
libgcc-ng                 9.3.0               h5dbcf3e_17    conda-forge
libgfortran-ng            9.3.0               he4bcb1c_17    conda-forge
libgfortran5              9.3.0               he4bcb1c_17    conda-forge
libgomp                   9.3.0               h5dbcf3e_17    conda-forge
libssh2                   1.9.0                h1ba5d50_1
libstdcxx-devel_linux-64  9.3.0               h4084dd6_17    conda-forge
libstdcxx-ng              9.3.0               h2ae2ef3_17    conda-forge
libuv                     1.40.0               h7b6447c_0
lz4-c                     1.9.2                heb0550a_3
ncurses                   6.2                  he6710b0_1
openssl                   1.1.1h               h516909a_0    conda-forge
rhash                     1.4.0                h1ba5d50_0
sysroot_linux-64          2.12                h77966d4_13    conda-forge
xz                        5.2.5                h7b6447c_0
zlib                      1.2.11               h7b6447c_3
zstd                      1.4.5                h9ceee32_0

Details about conda and system ( conda info ):

$ conda info
(cmake-tests) traversaro@IITICUBLAP102:~/1d6e3bb4e737ba80ef6ad255e3734a32$ conda info

     active environment : cmake-tests
    active env location : /home/traversaro/miniconda3/envs/cmake-tests
            shell level : 2
       user config file : /home/traversaro/.condarc
 populated config files : /home/traversaro/.condarc
          conda version : 4.8.3
    conda-build version : not installed
         python version : 3.8.3.final.0
       virtual packages : __glibc=2.31
       base environment : /home/traversaro/miniconda3  (writable)
           channel URLs : https://repo.anaconda.com/pkgs/main/linux-64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/r/linux-64
                          https://repo.anaconda.com/pkgs/r/noarch
          package cache : /home/traversaro/miniconda3/pkgs
                          /home/traversaro/.conda/pkgs
       envs directories : /home/traversaro/miniconda3/envs
                          /home/traversaro/.conda/envs
               platform : linux-64
             user-agent : conda/4.8.3 requests/2.24.0 CPython/3.8.3 Linux/4.19.104-microsoft-standard ubuntu/20.04.1 glibc/2.31
                UID:GID : 1000:1000
             netrc file : None
           offline mode : False

[traversaro]

The problem emerged in conda-forge/gazebo-feedstock#37 (comment), where the CMake calls to link_directories("/home/traversaro/miniconda3/envs/<env_name>/lib") where ignored because "/home/traversaro/miniconda3/envs/<env_name>/lib" was in CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES, even if the linker was not actually searching in that directory. Fortunately most CMake projects do not use link_directories and instead pass the absolute path of the libraries when linking them, so this bug should not affect most CMake projects.

[traversaro]

I am not sure, but if anyone is interesting in investigating this probably a good file were to start is : https://github.com/Kitware/CMake/blob/v3.19.1/Modules/CMakeParseImplicitLinkInfo.cmake .

[traversaro]

The problem emerged in conda-forge/gazebo-feedstock#37 (comment), where the CMake calls to link_directories("/home/traversaro/miniconda3/envs/<env_name>/lib") where ignored because "/home/traversaro/miniconda3/envs/<env_name>/lib" was in CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES, even if the linker was not actually searching in that directory. Fortunately most CMake projects do not use link_directories and instead pass the absolute path of the libraries when linking them, so this bug should not affect most CMake projects.

Actually, even if a project uses link_directories, the LDFLAGS environment variable should pass all the necessary linker options to CMake to overcome this problem. I noticed this problem only because I was working with a project that was overwriting the value of the CMAKE_<TYPE>_LINKER_FLAGS (see conda-forge/gazebo-feedstock#38 (comment)).

[jakirkham]

Is this still an issue?