================
@@ -170,11 +170,12 @@ if(ENABLE_SHARED)
# implicitly be exported from libclang.
target_compile_definitions(libclang PRIVATE CLANG_BUILD_STATIC)
elseif(APPLE)
- set(LIBCLANG_LINK_FLAGS " -Wl,-compatibility_version -Wl,1")
- set(LIBCLANG_LINK_FLAGS "${LIBCLANG_LINK_FLAGS} -Wl,-current_version
-Wl,${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}.${LLVM_VERSION_PATCH}")
-
- set_property(TARGET libclang APPEND_STRING PROPERTY
- LINK_FLAGS ${LIBCLANG_LINK_FLAGS})
+ if(LLVM_VERSIONED_DYLIB_NAME_ON_DARWIN)
----------------
tamird wrote:
> I think there is still a version number on the dylib right here right? It is
> just not equal to llvm version.
>
> macOS toolchain has always been shipping with no version and new toolchain
> cannot have a version on it, otherwise, it will break compatibility with old
> tools. Let me know if I misunderstood the code.
I think this is not correct; even before this PR libclang and libLTO had
explicit version numbers, they were just doing it manually using
`-compatibility_version` and `-current_version`. The second commit in this PR
kept that behavior but changed the implementation to use
`MACHO_COMPATIBILITY_VERSION` and `MACHO_CURRENT_VERSION`.
https://github.com/llvm/llvm-project/pull/189004
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
