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

Use a proper SONAME for libshaderc.so #381

Closed
haasn opened this issue Sep 28, 2017 · 10 comments
Closed

Use a proper SONAME for libshaderc.so #381

haasn opened this issue Sep 28, 2017 · 10 comments
Labels
version/release Packaging, versioning, installing, prebuilt artifacts

Comments

@haasn
Copy link

haasn commented Sep 28, 2017

Instead of arbitrarily calling it libshaderc_shared.so it should be called libshaderc.so.VER where VER encodes the ABI version. This would also allow users to compile with -lshaderc universally instead of needing to change it to -lshaderc_shared to build a dynamically linked executable.

For more information see https://en.wikipedia.org/wiki/Soname

@dneto0
Copy link
Collaborator

dneto0 commented Oct 2, 2018

Fixed by #493

@dneto0 dneto0 closed this as completed Oct 2, 2018
@haasn
Copy link
Author

haasn commented Oct 2, 2018

There's just one thing I'd still like to nitpick about. You still appear to call it libshaderc_shared.so.1 rather than the more conventional/canonical libshaderc.so.1. Any reason for why this should be the case?

@dneto0
Copy link
Collaborator

dneto0 commented Oct 2, 2018

I paged that out of my brain. I think @AWoloszyn might remember.

@AWoloszyn
Copy link
Contributor

I think @antiagainst was the one who added shaderc_shared.

If I remember correctly, it was because for some reason we couldn't or didn't want to use the cmake BUILD_SHARED_LIBS flag to get a shared library out.

We end up building both libshaderc.a and libshaderc_shared.so, and they are named as such because CMake does not allow two targets to have the same name. We can probably fix this with a simple

set_target_properties(shaderc_shared OUTPUT_NAME shaderc)

Although looking at the documentation I am not sure if we would also have to specify the extension/prefix, in which case that would get a bit more complicated.

@antiagainst
Copy link
Contributor

@Kangz added shared library via #366.

I'm not sure we can give the same name to both the static and shared library on Windows:

https://stackoverflow.com/questions/2152077/is-it-possible-to-get-cmake-to-build-both-a-static-and-shared-version-of-the-sam

But I don't have a strong preference.

@Kangz
Copy link
Collaborator

Kangz commented Oct 3, 2018

I don't really have preferences. Having the shared library be shaderc and the static one be shaderc_static would be fine.

@antiagainst
Copy link
Contributor

Maybe we can stop building both static and shared library but let the user choose which one to build by exposing a option around CMake BUILD_SHARED_LIBS.

@AWoloszyn
Copy link
Contributor

I think we would be better off with the BUILD_SHARED_LIBS approach. We should be able to detect, and then build one or the other, and then the user gets to choose.

@haasn
Copy link
Author

haasn commented Oct 3, 2018

I think the usual approach is to let the user choose the build type (shared vs static). For most users, I don't see much of a point in building both at the same time.

@antiagainst
Copy link
Contributor

I've uploaded #498 for this.

@dneto0 dneto0 added the version/release Packaging, versioning, installing, prebuilt artifacts label Mar 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
version/release Packaging, versioning, installing, prebuilt artifacts
Projects
None yet
Development

No branches or pull requests

5 participants