-
Notifications
You must be signed in to change notification settings - Fork 569
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
No library versions in soname #3046
Comments
See also the corresponding discussion for Shaderc: google/shaderc#381 |
This is currently blocking a whole bunch of packages in Debian (and its derivatives) since anything using glslang in its build process won't migrate because of this. Debian bug is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956510 |
I'm likely missing something (or several things), but why wouldn't something like this fix the issue?
Before the change:
After the above change:
|
Well, because it's not just the lack of a soname - it's the lack of a meaningful soname :) which should change every time the ABI changes incompatibly. |
Wouldn't whoever made that ABI breaking change bump SOVERSION up at that point? Or are you saying that needs to happen programmatically? Thanks Ryan. |
Ok, I see... this is described in #3214. |
In Unix world it's common for libraries to have version in soname (usually major and minor, major changes when there are backward incompatible ABI changes).
But current sonames for libraries don't have version info:
libSPIRV-Tools-link.so
libSPIRV-Tools-opt.so
libSPIRV-Tools-reduce.so
libSPIRV-Tools-shared.so
libSPIRV-Tools.so
From packaging POV (RPM in my case) .so files are usually symlinks to versioned library files and packaged to -devel (development) packages. Could be nice to see versioned library files/sonames and non-versioned -devel symlinks here too.
The text was updated successfully, but these errors were encountered: