ld: `libvulkan.dylib` has incorrect current version
juan-lunarg opened this issue · 6 comments
Describe the bug
Currently the Apple build produces the following warning twice
(For the loader
and vulkan-framework
):
ld: warning: truncating -dylib_current_version to fit in 32-bit space used by old mach-o format
From the ld man page:
-current_version number
Specifies the current version number of the library. The current version of the library can be obtained programmatically by the user of the library so it can determine exactly which version of the library it is using. The format of number is X[.Y[.Z]] where X must be a positive non-zero number less
than or equal to 65535, and .Y and .Z are optional and if present must be non-negative numbers less than or equal to 255. If the version number is not specified, it has a value of 0. This option is also called -dylib_current_version for compatibility.
This is caused by setting the VERSION
property in CMake and setting it to ${VULKAN_LOADER_VERSION}
.
-current_version
1.3.268
As a result otool
reports the incorrect version for the loader.
$ otool -L build/loader/libvulkan.dylib
build/loader/libvulkan.dylib:
@rpath/libvulkan.1.dylib (compatibility version 1.0.0, current version 1.3.255)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1336.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 2048.1.255)
Thoughts?
My only thought is to only report the major/minor version.
$ otool -L build/loader/libvulkan.dylib
build/loader/libvulkan.dylib:
@rpath/libvulkan.1.dylib (compatibility version 1.0.0, current version 1.3.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1336.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 2048.1.255)
I'm not sure if this is better though.
Also it looks like Vulkan doesn't follow strict semantic versioning?
Patch version MUST be reset to 0 when minor version is incremented
Vulkan does indeed not follow semantic versioning, I don’t know how that idea spread as I do not think the specification states it is using sem-ver anywhere.
I find it funny that only after 7 years of weekly header updates would the patch version exceed what dylib versions can handle.
I do not have a good solution off the top of my head; removing the patch is weird but saying we are “255” (but actually higher) is also wrong.
There may not be a good solution unfortunately since the Vk version packing uses the 32 bits very differently than how dylibs use them.
Also it looks like Vulkan doesn't follow strict semantic versioning?
Patch version MUST be reset to 0 when minor version is incremented
Seems that patch versions reset on MAJOR version increments. https://registry.khronos.org/vulkan/specs/1.3-extensions/html/chap46.html#_patch_versions
I double checked all the other Vulkan repos. The loader was the only repo with this issue.
NOTE: This PR caused a regression. See #1408 for the fix