1

I try to find a package (SDL2 and SDL2_image) I know exists and is installed in a custom directory. Since I am on Linux it should search all of these subdirectories, but it just does not and I see no reason why.

<prefix>/(lib/<arch>|lib*|share)/cmake/<name>*/                 (U)
<prefix>/(lib/<arch>|lib*|share)/<name>*/                       (U)
<prefix>/(lib/<arch>|lib*|share)/<name>*/(cmake|CMake)/         (U)
<prefix>/<name>*/(lib/<arch>|lib*|share)/cmake/<name>*/         (W/U)
<prefix>/<name>*/(lib/<arch>|lib*|share)/<name>*/               (W/U)
<prefix>/<name>*/(lib/<arch>|lib*|share)/<name>*/(cmake|CMake)/ (W/U)

I tried CMAKE_PREFIX_PATH, SDL2_ROOT, HINTS, PATHS etc. and also checked the NO_* variables, but even with set(CMAKE_FIND_DEBUG_MODE TRUE) it just shows <prefix>/SDL2Config.cmake and <prefix>/sdl2-config.cmake as guesses for all of the prefixes it found.

I am at a loss, why it just refuses to search the documented subdirectories. I don't want to specify the full path, because that just hardcodes something that could change in the future and is different depending on the system.

I am using CMake 3.24.1. Any help is appreciated.

Code:

set(CMAKE_PREFIX_PATH ${SDL_INSTALL_DIR})

set(CMAKE_FIND_DEBUG_MODE TRUE)
find_package(SDL2           REQUIRED)
find_package(SDL2_image     REQUIRED)
set(CMAKE_FIND_DEBUG_MODE FALSE)
SkryptX
  • 813
  • 1
  • 9
  • 24
  • 1
    Is the custom path you installed SDL2 in part of the default search path? If not, please provide a [mcve] that shows your exact call to `find_package`. – Stephen Newell Sep 27 '22 at 20:25
  • Please, add to the question post the exact invocation of `find_package` and the exact output with `set(CMAKE_FIND_DEBUG_MODE TRUE)`. Otherwise, your problem is unclear. – Tsyvarev Sep 27 '22 at 20:55
  • @StephenNewell No it is not part of the default search path. That's why I want to set the `CMAKE_PREFIX_PATH` or the `SDL2_ROOT` to specify my own directory. But an old version of SDL2 is in the system /usr directory and even there it does not find it. The reason seems to be that I am trying to use `find_package` when cross-compiling and CMake just throws out all the assumptions and does not search anywhere anymore. There are many other threads about that problem, that you are not able to resolve host dependencies while cross-compiling. – SkryptX Sep 28 '22 at 08:09
  • If I try the same `find_package` code outside of the cross-compiling environment it correctly searches the path and finds the config package. In the documentation for `find_package` is mentioned that is searches all the paths regardless of the OS, but that's proobably only half the truth like so many things in the CMake documentation. – SkryptX Sep 28 '22 at 08:34
  • So, is you problem that CMake doesn't search under directory `SDL_INSTALL_DIR` **at all** or is your problem that CMake searches under that directory but does not consider specific **path suffix**? Currently your question post **contradicts** to your comments. – Tsyvarev Sep 28 '22 at 09:35
  • @Tsyvarev It don't see where I contradict myself, but: Yes it does search the `CMAKE_PREFIX_PATH` (and all the other found paths like `PATH`) with `/SDL2Config.cmake` and `/sdl2-config.cmake`, but no prefix or path is searched with the appropriate prefix suffixes like `lib64/cmake/SDL2` like they are described in the documentation (and above). – SkryptX Sep 28 '22 at 09:49
  • From `find_package` [documentation](https://cmake.org/cmake/help/latest/command/find_package.html#config-mode-search-procedure): "Paths with `lib64` are searched on 64 bit platforms if the FIND_LIBRARY_USE_LIB64_PATHS property is set to TRUE." Is `FIND_LIBRARY_USE_LIB64_PATHS` global property set in your cross-compilation environment? – Tsyvarev Sep 28 '22 at 11:24
  • Knowing that you were cross-compiling would have been extremely useful, since your toolchain file should be specifying search paths. – Stephen Newell Sep 28 '22 at 12:58
  • @Tsyvarev Didn't change anything, but I tried renaming the directory from `lib64` to just `lib` and it somehow finds it. Its just very unfortunate that the `CMAKE_FIND_DEBUG_MODE` doesn't print that it also searches there. @StephenNewell The realization that it is related to the environment I'm in was part of the debugging process, not something I knew before, that it would ruin my day like that. – SkryptX Sep 28 '22 at 13:25

1 Answers1

1

Several things I learned during debugging this problem:

  1. CMAKE_FIND_DEBUG_MODE for find_package(..) doesn't actually show if it tried path suffixes or not. And you also don't see if it took the shown path as prefix path or absolute path. Path suffixes only get appended to prefix paths like CMAKE_PREFIX_PATH or <package>_ROOT. This is true for CMake 3.24.1. find_library(..) for example has a much more comprehensive debug output.

  2. If you are in a cross-compiling all the usual "good guesses" go out of the window or don't work. Be very careful and check EVERYTHING when setting up the environment. Even things like the selected compiler matter, since it is used to determine the library path (32/64bit for example, through CMAKE_SIZEOF_VOID_P)

  3. You cannot fix a broken environment by setting variables locally. They usually don't have any effect for reasons only the underlying code can explain to you. Example FIND_LIBRARY_USE_LIB64_PATHS is documented, but enabling it usually doesn't have any effect since the underlying check looks like below. If your environment doesn't advertise 64-bit nothing will happen. And if it already is 64-bit this flag is most likely already set automatically.

    if (this->Makefile->PlatformIs64Bit() && 
    this->Makefile->GetState()->GetGlobalPropertyAsBool(
       "FIND_LIBRARY_USE_LIB64_PATHS")) {
    this->UseLib64Paths = true;
}

  4. Read carefully what is said in the documentation. It is painful, but you might miss a crucial detail like that FIND_LIBRARY_USE_LIB64_PATHS is a global property and not a variable.

SkryptX
  • 813
  • 1
  • 9
  • 24