1

I have a CMakeLists.txt. I use it for generating a makefile with ccmake. Then upon make, my sources are compiled ok. At link time, the command line produced is essentially

/opt/rh/devtoolset-6/root/usr/bin/c++ myprog.cc.o -o myprog -Ldir3 -L/opt/rh/devtoolset-3/root/usr/lib/gcc/x86_64-redhat-linux/4.9.2 ... -Wl,-rpath,dir4:dir5:/opt/rh/devtoolset-3/root/usr/lib/gcc/x86_64-redhat-linux/4.9.2 ...

The two spots specifying the search path

/opt/rh/devtoolset-3/root/usr/lib/gcc/x86_64-redhat-linux/4.9.2

should actually point to

/opt/rh/devtoolset-6/root/usr/lib/gcc/x86_64-redhat-linux/6.2.1

How can I fix this?


I have devtoolset-3 in my system, but I do not know where this search path is set, or how to change it. I actually expected that to take place automatically after executing

scl-devtoolset-6

(in my .bashrc), the same way the correct version /opt/rh/devtoolset-6/root/usr/bin/c++ is detected without me doing anything else.

Of course, I get many linking time errors due to version mismatches.

The only place where I see the search path set is in line

link_directories(${LIBDIR_MY})

in CMakeLists.txt, and LIBDIR_MY points to dir3, which is correctly added in the linking command line. But I found no place where .../devtoolset-3/... is added.

Possible origins of -L:

  1. link_directories in CMakeLists.txt: checked.
  2. target_link_libraries: Where? What is the expected file name pattern to look for?
  3. link_libraries: Where? What is the expected file name pattern to look for?
  4. CMAKE_LIBRARY_PATH: Checked. It is not set.
  5. A find_package command: See below
  6. Somewhere else?

This How do I add a library path in cmake? does not add to my question.


Update 1:

There was in fact a find_package(mylib) (actually, with a different name) in CMakeLists.txt. Going to the dir of mylib and issuing find . -name “*” -type f -exec grep /opt/rh/devtoolset-3 {} \; there were two files that matched:

  1. build/CMakeCache.txt: two occurrences of devtoolset-3

    PETSC_LIBRARIES:STRING=...devtoolset-3...
    FIND_PACKAGE_MESSAGE_DETAILS_PETSc:INTERNAL=[...devtoolset-3...][YES][v()]
    

    It appears to me that this stems from file CMake/cmake-modules/FindPETSc.cmake (possibly invoked by line find_package (PETSc REQUIRED) in CMakeLists.txt), which has a line

    set (PETSC_LIBRARIES ${PETSC_LIBRARIES_ALL} CACHE STRING "PETSc libraries" FORCE)
    

    and many prior lines

    set (PETSC_LIBRARIES_<various terms> ...)
    

Notes: I do not know where in that file devtoolset-3 is first detected and set.

  1. build/include/summit/mylibConfig.cmake. I still could not track down what made devtoolset-3 appear here.
  • Option `-L` is also produced by `target_link_libraries`/`link_libraries` called with imported target. For answer the question "how to replace -L option" we need to know where this option is originated... – Tsyvarev Feb 27 '18 at 23:04
  • @Tsyvarev - To track down the possible origin of that `-L` from `target_link_libraries`/`link_libraries`, I could e.g. `find -exec grep target_link_libraries {} \;` (very primitive). What is the expected `` where I can possibly find it? Is there a more systematic way of ruling out possible locations of `target_link_libraries`/`link_libraries`? – sancho.s ReinstateMonicaCellio Feb 28 '18 at 07:27
  • I would suggest to check `CMakeCache.txt` (located in the project's build directory) first. The variable, contained given path, is likely related to some 3d-party package you used via `find_package()`. Knowing the variable's prefix may hint about which actual package defines it. BTW, your linker command line should contain linking with a library (`-l` option) to the library, located in the directory specified by `-L` option. – Tsyvarev Feb 28 '18 at 07:34
  • You might also check your install. `share/cmake-ver/Modules/` – Ben Feb 28 '18 at 13:47
  • There was in fact a `find_package` in `CMakeLists.txt`. Going to the dir of that package and issuing `find . -name “*” -type f -exec grep /opt/rh/devtoolset-3 {} \;` there were two files that matched. – sancho.s ReinstateMonicaCellio Feb 28 '18 at 17:19
  • @Tsyvarev - Please see posted answer. – sancho.s ReinstateMonicaCellio Apr 27 '18 at 09:05

1 Answers1

0

I found the culprit. As hinted at in Update 1 of the OP, the sequence is the following:

  1. Line find_package (PETSc REQUIRED) in file (1) CMakeLists.txt forced processing file (2) CMake/cmake-modules/FindPETSc.cmake.
  2. Line*1 petsc_get_variable (PETSC_EXTERNAL_LIB_BASIC petsc_libs_external) in file (2) CMake/cmake-modules/FindPETSc.cmake sets a local cmake variable petsc_libs_external from the value of the variable PETSC_EXTERNAL_LIB_BASIC read from file (3) ~/petsc-3.8.2/lib/petsc/conf/petscvariables.
  3. PETSC_EXTERNAL_LIB_BASIC is not set explicitly in file (3) ~/petsc-3.8.2/lib/petsc/conf/petscvariables. Line include ~/petsc-3.8.2/arch-linux2-c-debug/lib/petsc/conf/petscvariables forces reading file (4) ~/petsc-3.8.2/arch-linux2-c-debug/lib/petsc/conf/petscvariables.
  4. Line PETSC_EXTERNAL_LIB_BASIC = ... -Wl,-rpath,/opt/rh/devtoolset-3/root/usr/lib/gcc/x86_64-redhat-linux/4.9.2 -L/opt/rh/devtoolset-3/root/usr/lib/gcc/x86_64-redhat-linux/4.9.2 -Wl,-rpath,/opt/rh/devtoolset-3/root/usr/lib64 -L/opt/rh/devtoolset-3/root/usr/lib64 -Wl,-rpath,/opt/rh/devtoolset-3/root/usr/lib -L/opt/rh/devtoolset-3/root/usr/lib ... in file (4) /home/sserebrinsky/petsc-3.8.2/arch-linux2-c-debug/lib/petsc/conf/petscvariables brings the "undesired" directories into the executed command line.


*1 (petsc_get_variable is a macro defined in FindPETSc.cmake)