4

When I run FindPackage(PythonLibs), it finds the static python library first, python3.5m.a, rather than python3.5m.so. Is this the expected behavior of CMake? I suspect that it is not as per CMake bug report; however, this bug report was submitted in 2005. Things change over 13 years. If shared libraries have preference then any idea why CMake would find a static library over a shared one?

I have already fixed the build issue by just telling CMake where the proper library is for my own build using the SET() command. I'm looking for an answer which leads to a better understanding of CMake's behavior in this context because I'm trying to solve a different problem, and finding the static over the shared library seemed odd to me. Thanks!

System/Problem Information:

  • Ubuntu 16.04, 64 bit
  • Compiled Python 3.5.5 with enabled-shared
  • CMake 3.11.0
  • Edit as per Tsyvarev comment: the shared and static libraries are in the same directory

If you look at the cmake files, specifically FindPythonLibs.cmake (CMake 3.11.0) at lines 142-163, it looks to me that it finds the shared library then the static, but again I'm not an expert at CMake (it is a CMake noob trying to pick out what the source code does with very little context).

Thank you for taking time from your day to read this question. Any help is appreciated.

Edit: 4/13/18

Well, this is interesting. I checked the CMAKE_FIND_LIBRARY_SUFFIXES variable, and the value was: ".so.a". This is almost becoming interesting enough for me to figure out how to debug CMake files as per this question/answer. When/If I get around to it, I'll update my post again.

Edit 4/16/18

Well, I started gearing up to do the debugging process. As I was gearing up, I figured out the mistake. I forgot to delete the CMakeCache.txt when I built the shared version of python 3.5.5, so the FIND_PACKAGE command was not re-running. Thank you for taking your time replying to this question, Tsyvarev. I learned something new.

skincell
  • 407
  • 3
  • 7
  • 3
    If both static and shared libraries are **in the same directory**, you may try to specify preferences of libraries via [CMAKE_FIND_LIBRARY_SUFFIXES](https://cmake.org/cmake/help/v3.9/variable/CMAKE_FIND_LIBRARY_SUFFIXES.html) variable: `set(CMAKE_FIND_LIBRARY_SUFFIXES ".so" ".a")`. Do not forget to clear CMake cache (`CMakeCache.txt`) before re-search the library. – Tsyvarev Apr 12 '18 at 21:35
  • Good tip, I never knew that you could do that. Do you know if there is a built in preference for a shared versus a static library if both libraries are in the same directory? – skincell Apr 12 '18 at 21:51
  • 1
    Any preference is expressed via that variable (*CMAKE_FIND_LIBRARY_SUFFIXES*). You may even read its value for determine which library is preferred by default. However, I am not aware about CMake policy for default setting this variable: technically (but unlikely), when read its default value, you may obtain one value in one CMake version and another - in another version. – Tsyvarev Apr 12 '18 at 22:04
  • I actually a clue to this when I browsed your previous answers/comments @Tsyvarev in which you suggested or someone suggested to delete the CMakeCache.txt. Once I saw that I had a sinking feeling, but I kept on denying it until I literally ran into it. I can either sum up the answer about dynamic versus static preference for libraries or you can. Let me know your preference. – skincell Apr 16 '18 at 17:26

1 Answers1

2

If both static and shared libraries are in the same directory, you may try to specify preferences of libraries via CMAKE_FIND_LIBRARY_SUFFIXES variable:

# Prefer dynamic libraries to static ones
set(CMAKE_FIND_LIBRARY_SUFFIXES ".so" ".a")

Do not forget to clear CMake cache (CMakeCache.txt file in the build directory) before re-search the library.

Requirement for libraries to be located in the same directory is important:

Standard algorithm of find_library command searches all possible library names in a directory before switching to the next directory. This behavior is changed by NAMES_PER_DIR option, but it is rarely used in "Find" scripts.

Tsyvarev
  • 60,011
  • 17
  • 110
  • 153