Skip to content
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

SONAME Configuration & Versioning Policy #49

Closed
damaestro opened this issue Mar 14, 2024 · 6 comments
Closed

SONAME Configuration & Versioning Policy #49

damaestro opened this issue Mar 14, 2024 · 6 comments

Comments

@damaestro
Copy link
Contributor

We need to configure proper soname's and versioning for downstream packaging policy compliance. The goal is to provide an ABI guarantee for any given soname. This can be accomplished by soname versioning or library symbol versioning. The simpler solution is likely the right one. Soname bumps are usually more involved and will require rebuilding all linked packages.

Fedora: https://docs.fedoraproject.org/en-US/packaging-guidelines/C_and_C++/

Debian: https://www.debian.org/doc/manuals/maint-guide/advanced.en.html#library

Based on the fedora-review tool, there is one soname that needs addressing:

W: no-soname /usr/lib64/libopenxr_wivrn.so

Upstream Monado addressed this in https://gitlab.freedesktop.org/monado/monado/-/issues/335

@damaestro
Copy link
Contributor Author

This is likely invalid. libopenxr_wivrn.so is not to be linked against and should be defined as a MODULE and is only loaded at runtime. This is a tracking bug pending resolution upstream and confirmation in this project.

@xytovl
Copy link
Collaborator

xytovl commented Mar 14, 2024

libopenxr_wivrn.so is produced by https://gitlab.freedesktop.org/monado/monado/-/blob/2d26946ffa20d274aefc528e2728175cc76a6227/src/xrt/targets/openxr/CMakeLists.txt#L17 which is already defined as MODULE

This is expected to only be loaded at runtime, what more is needed to address the warning?

@damaestro
Copy link
Contributor Author

The only additional change would be if we move libopenxr_monado.so to /usr/lib[64]/monado/libopenxr_monado.so we should also move libopenxr_wivrn.so to /usr/lib[64]/wivrn/libopenxr_wivrn.so.

@damaestro
Copy link
Contributor Author

Yes, we need to move libopenxr_wivrn.so to /usr/lib[64]/wivrn/libopenxr_wivrn.so so it is outside of the ld load path for Fedora packaging. I've tested this with the monado vulkan layers and it's working if everything is still configured correctly. https://gitlab.freedesktop.org/monado/utilities/vulkan-layers/-/issues/3

Per https://github.com/KhronosGroup/Vulkan-Loader/blob/main/docs/LoaderInterfaceArchitecture.md there is no prescribed location and everything is configuration driven.

@damaestro
Copy link
Contributor Author

Pending evaluation of https://gitlab.freedesktop.org/monado/monado/-/blob/main/doc/packaging-notes.md this might not be needed. https://gitlab.freedesktop.org/monado/monado/-/merge_requests/2193 was rejected based on the proposed standard.

@damaestro
Copy link
Contributor Author

I've confirmed that libopenxr_wivrn.so (an OpenXR Runtime) will remain unversioned and visible to the linker. I'm currently in a review for a Fedora packaging policy that encodes this decision. The only change that we'll need to make for WiVRn will be the file system location and how the new location is exposed the linker. I'll open a new issue once we get to that point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants