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

Fix missing version info in host binaries on Unix #34520

Merged
merged 1 commit into from
Apr 6, 2020

Conversation

elinor-fung
Copy link
Member

@elinor-fung elinor-fung commented Apr 3, 2020

Fix #34505

With this:

> strings artifacts/bin/linux-x64.Release/corehost/*.so | grep '@(#'
@(#)Version 42.42.42.42424 @Commit: 805cd002a7e5dd4647efae50a6b5d16f713da23e
@(#)Version 42.42.42.42424 @Commit: 805cd002a7e5dd4647efae50a6b5d16f713da23e
@(#)Version 42.42.42.42424 @Commit: 805cd002a7e5dd4647efae50a6b5d16f713da23e

The three occurrences are libhostfxr, libhostpolicy, and libnethost. dotnet also has the version as expected and apphost does not have the version as expected.

Copy link
Contributor

@lpereira lpereira left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, although it might be a good idea to use CMake's SOVERSION property in shared libraries, too.

@elinor-fung elinor-fung merged commit e622160 into dotnet:master Apr 6, 2020
@elinor-fung
Copy link
Member Author

Hm, yeah, looks like we don't use SOVERSION / VERSION right now. Just read a bit about it - probably worth looking into. Not sure how that plays with the current versioning through resources we do on Windows though.

@elinor-fung elinor-fung deleted the hostVersion-unix branch April 6, 2020 17:42
@janvorli
Copy link
Member

janvorli commented Apr 7, 2020

@lpereira so you are suggesting that we should consider adding version to the filename of the libraries?

@lpereira
Copy link
Contributor

lpereira commented Apr 7, 2020

On Unix, it's customary to have the ABI version in the library name (e.g. libc.so.6 for ABI version 6).

It's not easy to change now because that's a published interface, but it would have been easier to, for instance, look for libhostfxr.so.2 and assume it has the new-style interface rather than opening libhostfxr.so and probing for symbols.

Symbolic links can be used to point to the latest version, too. So we probably don't even need hostfxr to locate hostpolicy, we can just link -- and not even look ourselves for it with dlopen() and friends -- with libhostpolicy.so.5, and let the dynamic loader do the work of finding the latest version of that. (For instance, that could be /usr/lib64/dotnet/libhostpolicy.so.5 -> /usr/lib64/dotnet/libhostpolicy.so.5.0.0, if we used the SOVERSION and VERSION to match the .NET version -- and if .NET 5.0.1 is released, we just patch the symlink and next time something else starts, it's already using the new version.)

These changes would make .NET look less alien in Unix, IMHO.

@ghost ghost locked as resolved and limited conversation to collaborators Dec 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

libhostpolicy.so and libhostfxr.so are missing build hash string
4 participants