-
Notifications
You must be signed in to change notification settings - Fork 2.4k
Description
Describe the bug
The Swift interface exposed via the libzstd target defined in Package.swift currently does not include any of the static-linking-only functions, and there is no way for a swift app/package depending on zstd to enable these APIs, even if zstd ends up getting statically linked.
To Reproduce
Add zstd as a dependency to a swift package, and try to use one of the static-only APIs (eg ZSTD_isFrame)
Expected behavior
Clearly it should be possible to always use the full API, regardless of which language it is being bridged into (provided you're statically linking the library).
Possible Solutions
There are multiple ways this could be resolved:
- we could introduce a shim header that sets the
ZSTD_STATIC_LINKING_ONLYdefine and then includes zstd.h, and change the modulemap to include the shim header instead of directly including zstd.h- this would resolve the issue, but unconditionally requiring static linking via the modulemap seems like a bad idea, since it'd also affect other (non-swift-package-related) situations where the modulemap is used
- we could introduce a second, separate modulemap that is used only by the SPM package (i.e., the Package.swift file)
- this approach would ensure that any existing code / setups that use the modulemap will continue to work unchanged
(Note: simply adding .define("ZSTD_STATIC_LINKING_ONLY") to the cSettings array in Package.swift does not work, since flags defined in this way only affect the compilation of the code, but do not affect the clang importer.)
Additional context
Tbh i have no idea if any / which other things (besides Swift's clang importer) use the modulemap file, and it might actually be safe to simply modify it in place, but i'm not comfortable doing that and think it'd be a bad idea, so adding the secondary, Swift-only one seems like the best approach.