Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[question] How can I find the shared zlib package in CMake on Windows #17513

Open
1 task
molotok-sms opened this issue Dec 19, 2024 · 2 comments
Open
1 task
Assignees

Comments

@molotok-sms
Copy link

molotok-sms commented Dec 19, 2024

What is your question?

Hi!
It seems I have read a lot of materials, but I still don't know how I can find the SHARED ZLIB package in CMake on Windows.

As you know:

  • the ".lib" file has the name "zdll.lib";
  • the ".dll" file has the name "zlib.dll".

I have the CMake v3.31.1 and Conan 2.10.0.

I am trying to do it in that way:

find_package(ZLIB 1.3.1 CONFIG REQUIRED)

and I have the error:

-- VERBOSE Conan: Target declared 'ZLIB::ZLIB'
-- VERBOSE Conan: Library zdll found C:/.conan/data/b/zlib34aeb5be2e981/p/lib/zdll.lib
-- STATUS Cannot locate shared library: zdll
-- DEBUG DLL library not found, creating UNKNOWN IMPORTED target
-- VERBOSE Conan: Found: C:/.conan/data/b/zlib34aeb5be2e981/p/lib/zdll.lib

-- VERBOSE Conan: Library zdll found C:/.conan/data/b/zlib34aeb5be2e981/p/lib/zdll.lib
-- STATUS Cannot locate shared library: zdll
-- DEBUG DLL library not found, creating UNKNOWN IMPORTED target
-- VERBOSE Conan: Found: C:/.conan/data/b/zlib34aeb5be2e981/p/lib/zdll.lib

The recipe of Zlib contains the following lines:

libname = "zdll" of self.options.shared else "zlib"

but the conan_package_library_targets function from the cmakedeps_macros.cmake file doesn't know how to check this shared library in the right way.

How can I find the shared Zlib library in CMake from Conan on Windows?

Have you read the CONTRIBUTING guide?

  • I've read the CONTRIBUTING guide
@memsharded memsharded self-assigned this Dec 19, 2024
@memsharded
Copy link
Member

Hi @molotok-sms

Thanks for your feedback.

The message STATUS Cannot locate shared library: zdll has been removed in latest Conan 2.11, because it is slightly confusing.

The thing is that it doesn't matter much that the dll is not found. The find_package() + target_link_libraries(... ZLIB::ZLIB) works, and it is possible to build and run against zlib as a shared library. If you can't, please let us know the details to reproduce and how the link step fails.

If you want to have targets defined as SHARED IMPORTED, instead of the default INTERFACE IMPORTED targets that the CMakeDeps is generating right now, you want to check the new CMakeDeps generator that is being documented in the "Incubating" section, see https://docs.conan.io/2/incubating.html.

@molotok-sms
Copy link
Author

molotok-sms commented Dec 23, 2024

In accordance with CMake documentation, my tests and tests of my collegues, the present of such Unknown Targets is not enough and it does not work in my environment.

The CMake documentation says about TARGET_RUNTIME_DLLS:

Note Imported Targets are supported only if they know the location of their .dll files. An imported SHARED library must have IMPORTED_LOCATION set to its .dll file. See the add_library imported libraries section for details. Many Find Modules produce imported targets with the UNKNOWN type and therefore will be ignored.

Link: https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html#:~:text=%3E%0A%20%20COMMAND_EXPAND_LISTS%0A)-,Note,-Imported%20Targets%20are

Cases:

  1. Regular: If the names of .lib and .dll files are equal, the Conan will find both files without any issues and fill the CMake Target with all needed information.
  2. Problematic: If the that names are different, the Conan will create Unknown Target and fill only IMPORTED_LOCATION and set to the path to .lib file instead of .dll file. Thus, we have not only the error "Cannot locate shared library", but we have empty TARGET_RUNTIME_DLLS and unability to find right DLL too. The program tries to be linked only with existence libraries in my environment in such cases.

The good and short example of the regular case is zstd (zstd.lib and zstd.dll).
The examples of the problematic case are openssl (libcrypto.lib and libssl.lib against libcrypto-3-x64.dll and libssl-3-x64.dll) and zlib (zdll.lib and zlib.dll).

At the same time, I managed to fix the issue with OpenSSL:

set(_OLD_CMAKE_FIND_LIBRARY_SUFFIXES ${CMAKE_FIND_LIBRARY_SUFFIXES})
# Allows to find lib(crypto|ssl)-3-x64.dll instead of lib(crypto|ssl).dll
set(CMAKE_FIND_LIBRARY_SUFFIXES -3-x64.dll ${CMAKE_FIND_LIBRARY_SUFFIXES})

find_package(OpenSSL 3.3.2 CONFIG REQUIRED COMPONENTS Crypto SSL)

set(CMAKE_FIND_LIBRARY_SUFFIXES ${_OLD_CMAKE_FIND_LIBRARY_SUFFIXES})

but it can't be applied to zlib file names.

I haven't managed to find now, but I have seen the proposal to make separate declarations of static and shared library names, something like self.cpp_info.libs.SharedLibrary('libName', 'dllName') and it can fix the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants