-
Notifications
You must be signed in to change notification settings - Fork 13.3k
rustc: Allow cdylibs to link against dylibs #68448
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
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @zackmdavis (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
r? @alexcrichton |
@bors: r+ Thanks! |
📌 Commit 518cb70 has been approved by |
rustc: Allow cdylibs to link against dylibs Previously, rustc mandated that cdylibs could only link against rlibs as dependencies (not dylibs). This commit disables that restriction and tests that it works in a simple case. I don't have a windows rustc dev environment, so I guessed at the MSVC test code, I'm hoping the CI can run that for me. Additionally, we might want to consider emitting (through cargo or rustc) some metadata to help C users of a cdylib figure out where all the dylibs they need are. I don't think that should be needed to land this change, as it will still be usable by homogeneous build systems without it. My new test was templated off the `tests/run-make-fulldeps/cdylib` test. It seemed more appropriate to have it as a separate test, since both foo.rs and bar.rs would need to be replicated to make that test cover both cases, but I can do that if it would be preferred. If I'm doing anything out of order/process, please let me know; this is only my second change to rustc and the prior one was trivial. r? alexcrichton
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
💔 Test failed - checks-azure |
Previously, rustc mandated that cdylibs could only link against rlibs as dependencies (not dylibs). This commit disables that restriction and tests that it works in a simple case.
@alexcrichton |
@bors: r+ |
📌 Commit 72aaa3a has been approved by |
rustc: Allow cdylibs to link against dylibs Previously, rustc mandated that cdylibs could only link against rlibs as dependencies (not dylibs). This commit disables that restriction and tests that it works in a simple case. I don't have a windows rustc dev environment, so I guessed at the MSVC test code, I'm hoping the CI can run that for me. Additionally, we might want to consider emitting (through cargo or rustc) some metadata to help C users of a cdylib figure out where all the dylibs they need are. I don't think that should be needed to land this change, as it will still be usable by homogeneous build systems without it. My new test was templated off the `tests/run-make-fulldeps/cdylib` test. It seemed more appropriate to have it as a separate test, since both foo.rs and bar.rs would need to be replicated to make that test cover both cases, but I can do that if it would be preferred. If I'm doing anything out of order/process, please let me know; this is only my second change to rustc and the prior one was trivial. r? alexcrichton
☀️ Test successful - checks-azure |
Previously, rustc mandated that cdylibs could only link against rlibs as dependencies (not dylibs).
This commit disables that restriction and tests that it works in a simple case.
I don't have a windows rustc dev environment, so I guessed at the MSVC test code, I'm hoping the CI can run that for me.
Additionally, we might want to consider emitting (through cargo or rustc) some metadata to help C users of a cdylib figure out where all the dylibs they need are. I don't think that should be needed to land this change, as it will still be usable by homogeneous build systems without it.
My new test was templated off the
tests/run-make-fulldeps/cdylib
test. It seemed more appropriate to have it as a separate test, since both foo.rs and bar.rs would need to be replicated to make that test cover both cases, but I can do that if it would be preferred.If I'm doing anything out of order/process, please let me know; this is only my second change to rustc and the prior one was trivial.
r? alexcrichton