-
Notifications
You must be signed in to change notification settings - Fork 273
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
When using BUILD_SHARED_LIBS=FALSE
, libzip doesn't link all of its dependencies statically
#464
Comments
BUILD_SHARED_LIBS
, libzip doesn't link all of its dependencies staticallyBUILD_SHARED_LIBS=FALSE
, libzip doesn't link all of its dependencies statically
You'll have to provide more details about what you're doing.
and I end up with a static binary that does not use any shared libraries.
(Please note that we do not have Windows expertise.) |
Your usage pattern example, that of directly executing a command line compiler where each dependency is manually passed into the compilation command, not utilizing CMake entirely with a project linking to libzip, is not relevant to the issue. I guess I need to clarify my usage pattern. I'm working entirely within a CMake project, that links to libzip via its CMake support, not direct command line usage, nor a manually-written makefile. The behavior I'm wanting of libzip's CMake support is that when a CMake project links libzip statically (my project), libzip's own CMake script code have libzip itself link to the static library form of zlib, or any of the other dependencies associated with the features of libzip enabled at build time, so a CMake project linking to libzip doesn't end up having any dynamic library links (outside of core operating system dynamic libraries, like glibc, of course). Presently, the executable in my project linking to libzip ends up with a dynamic link to zlib even when linking statically to libzip, not producing the result you achieved with the explicit compilation command. |
I understand what you're doing better, but you're basically asking me to reproduce your setup to find out if it's even a bug in libzip or in your usage of CMake. |
I figured out the "right solution" in the current structure of libzip's CMake code: In the CMake documentation for the FindZLIB module, the right way to get zlib statically linked is to enable the All that needs to be done is to add a few lines to
# ...
if(CMAKE_VERSION VERSION_GREATER_EQUAL 3.24)
option(ZLIB_USE_STATIC_LIBS "Use static zlib libraries" ${ZIP_STATIC})
endif()
find_package(ZLIB 1.1.2 REQUIRED)
# ...
# ...
if (NOT IS_SHARED)
include(CMakeFindDependencyMacro)
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${CMAKE_CURRENT_LIST_DIR}/modules")
set(ENABLE_BZIP2 @BZIP2_FOUND@)
set(ENABLE_LZMA @LIBLZMA_FOUND@)
set(ENABLE_ZSTD @ZSTD_FOUND@)
set(ENABLE_GNUTLS @GNUTLS_FOUND@)
set(ENABLE_MBEDTLS @MBEDTLS_FOUND@)
set(ENABLE_OPENSSL @OPENSSL_FOUND@)
if(CMAKE_VERSION VERSION_GREATER_EQUAL 3.24)
set(ZLIB_USE_STATIC_LIBS ON)
endif()
find_dependency(ZLIB 1.1.2)
if(ENABLE_BZIP2)
find_dependency(BZip2)
endif()
# ... The user of libzip does end up getting a dynamic link to zlib if the feature options, that themselves depend on zlib, aren't disabled (though maybe building them all with So I'd be satisfied with the addition of using static zlib in |
I think it's fair to assume that a user of libzip expects, when linking to it statically, that no shared dependencies are carried over to the user of libzip. Currently, at least zlib is being linked shared even when using the CMake option
-DBUILD_SHARED_LIBS=FALSE
, so zlib ends up becoming a shared library link of the user of libzip.I'm well aware that it's pretty safe to assume there's a system-installed zlib on any current POSIX/POSIX-like platform, like Linux or macOS, but that's not the case of Windows.
The text was updated successfully, but these errors were encountered: