-
Notifications
You must be signed in to change notification settings - Fork 6
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
cdylib: symbol versioning #38
Comments
Duplicate of #12, but I'll migrate that here.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In order to avoid compatibility issues in the future, we should make use of symbol versioning from the first release in order to avoid having to bump the SONAME when we eventually run into an incompatible change.
There are a few issues to note (I haven't tested these yet, I'm just collecting my notes from reading about this for a bit):
panic="abort"
?) which means some magic is necessary to use our version map for our own symbols. It also appears to include our symbols in its default version map, so you also need to define the symbols with alternative names and then use-Wl,--defsym=foo=foo_impl
to remap them. This will probably cause issues with cbindgen...asm(".symver ...")
/__attribute__(symver())
in Rust at the moment, so if we ever end up having the same symbol name in two different versions (ie. there was an incompatible semantics change for a function and we want new programs to not use the function) it might not be possible to generate a version map with the right symbols. I suspect that--defsym=...
can't be used for this purpose but we might want to look into that.I suspect defining a version map from the outset even if we don't know how to deal with (2) is probably a good idea.
The text was updated successfully, but these errors were encountered: