KhronosGroup/Vulkan-Loader

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?

@richard-lunarg / @charles-lunarg

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