You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We haven't, to my knowledge, tried to make an fully established semantics for dylibs. (Though if you look at rust-lang/rust#34909 (comment) you at least get a nice chart of different combinations and what happened on them, at least as of 2017...)
Instead, we've discouraged their use, focusing on the static linking case, and pointing people at cdylib when they absolutely need dynamic loading (since in that case, we can actually provide some sort of stable ABI guarantee).
But this means that every time dylibs come up, its a bit of a black art figuring out what the users intended. (See for example rust-lang/rust#82151 )
Its also a black art to identify the developers who would be best able to dissect the problem in the first place.
Before this meeting would start, I would want a pre-written document for the meeting, listing the known problems with dylibs today. Then we could spend the meeting discussing the problems, to tease out which things we think we can resolve, and then find volunteers to work on it.
About this issue
This issue corresponds to a meeting proposal for the compiler team steering meeting. It corresponds to a possible topic of
discussion. You can read more about the steering meeting procedure
here.
Comment policy
These issues are meant to be used as an "announcements channel"
regarding the proposal, and not as a place to discuss the technical
details. Feel free to subscribe to updates. We'll post comments when
reviewing the proposal in meetings or making a scheduling decision.
In the meantime, if you have questions or ideas, ping the proposers
on Zulip (or elsewhere).
The text was updated successfully, but these errors were encountered:
Summary
dylibs need directors: We need dedicated dylib working/project group. (weak title joke, I know... I'm in a rush here...)
Dynamic libraries are a known weak spot in the Rust ecosystem.
E.g. consider this five year old bug:
"Cannot link to
--crate-type dylib
#34909We haven't, to my knowledge, tried to make an fully established semantics for dylibs. (Though if you look at rust-lang/rust#34909 (comment) you at least get a nice chart of different combinations and what happened on them, at least as of 2017...)
Instead, we've discouraged their use, focusing on the static linking case, and pointing people at cdylib when they absolutely need dynamic loading (since in that case, we can actually provide some sort of stable ABI guarantee).
But this means that every time dylibs come up, its a bit of a black art figuring out what the users intended. (See for example rust-lang/rust#82151 )
Its also a black art to identify the developers who would be best able to dissect the problem in the first place.
Before this meeting would start, I would want a pre-written document for the meeting, listing the known problems with dylibs today. Then we could spend the meeting discussing the problems, to tease out which things we think we can resolve, and then find volunteers to work on it.
About this issue
This issue corresponds to a meeting proposal for the compiler team
steering meeting. It corresponds to a possible topic of
discussion. You can read more about the steering meeting procedure
here.
Comment policy
These issues are meant to be used as an "announcements channel"
regarding the proposal, and not as a place to discuss the technical
details. Feel free to subscribe to updates. We'll post comments when
reviewing the proposal in meetings or making a scheduling decision.
In the meantime, if you have questions or ideas, ping the proposers
on Zulip (or elsewhere).
The text was updated successfully, but these errors were encountered: