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

rustc: Add some support for mixing rlibs and dylibs #13892

Merged
merged 1 commit into from May 7, 2014

Conversation

alexcrichton
Copy link
Member

Currently, rustc requires that a linkage be a product of 100% rlibs or 100%
dylibs. This is to satisfy the requirement that each object appear at most once
in the final output products. This is a bit limiting, and the upcoming libcore
library cannot exist as a dylib, so these rules must change.

The goal of this commit is to enable some use cases for mixing rlibs and
dylibs, primarily libcore's use case. It is not targeted at allowing an
exhaustive number of linkage flavors.

There is a new dependency_format module in rustc which calculates what format
each upstream library should be linked as in each output type of the current
unit of compilation. The module itself contains many gory details about what's
going on here.

cc #10729

@alexcrichton alexcrichton reopened this May 2, 2014
@brson brson mentioned this pull request May 2, 2014
9 tasks
@alexcrichton
Copy link
Member Author

cc #13851, this is blocking libcore on windows

//! into a crate D (because library A appears twice).
//!
//! The job of this module is to calculate what format each upstream crate
//! should be used when linking eachoutput type requested in this session. This
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: "each output"

Currently, rustc requires that a linkage be a product of 100% rlibs or 100%
dylibs. This is to satisfy the requirement that each object appear at most once
in the final output products. This is a bit limiting, and the upcoming libcore
library cannot exist as a dylib, so these rules must change.

The goal of this commit is to enable *some* use cases for mixing rlibs and
dylibs, primarily libcore's use case. It is not targeted at allowing an
exhaustive number of linkage flavors.

There is a new dependency_format module in rustc which calculates what format
each upstream library should be linked as in each output type of the current
unit of compilation. The module itself contains many gory details about what's
going on here.

cc rust-lang#10729
@alexcrichton
Copy link
Member Author

Now with all tests passing! (sorry, should have run make check earlier)

@flaper87
Copy link
Contributor

flaper87 commented May 2, 2014

amazing work, very enlightening! thanks!

bors added a commit that referenced this pull request May 7, 2014
Currently, rustc requires that a linkage be a product of 100% rlibs or 100%
dylibs. This is to satisfy the requirement that each object appear at most once
in the final output products. This is a bit limiting, and the upcoming libcore
library cannot exist as a dylib, so these rules must change.

The goal of this commit is to enable *some* use cases for mixing rlibs and
dylibs, primarily libcore's use case. It is not targeted at allowing an
exhaustive number of linkage flavors.

There is a new dependency_format module in rustc which calculates what format
each upstream library should be linked as in each output type of the current
unit of compilation. The module itself contains many gory details about what's
going on here.

cc #10729
@bors bors closed this May 7, 2014
@bors bors merged commit a82f921 into rust-lang:master May 7, 2014
@huonw
Copy link
Member

huonw commented May 7, 2014

I was thinking about this today: should we have a way to manually specify the desired linkage?

#[link_to(rlib)] extern crate foo;
#[link_to(dylib)] extern crate bar;

(or something)

@alexcrichton alexcrichton deleted the mixing-rlib-dylib-deps branch May 7, 2014 15:42
@alexcrichton
Copy link
Member Author

I do think that we'll eventually have to grow use cases such as that, but for now I wanted to go with the "simple as possible" implementation. I was hoping to better understand the use case for manually specifying a linkage before adding it, mainly because I'm not convinced that the algorithm implemented here is always sufficient!

@pnkfelix pnkfelix changed the title rustc: Add some suppot for mixing rlibs and dylibs rustc: Add some support for mixing rlibs and dylibs May 7, 2014
bors added a commit that referenced this pull request May 7, 2014
This is the second step in implementing #13851. This PR cannot currently land until a snapshot exists with #13892, but I imagine that this review will take longer.

This PR refactors a large amount of functionality outside of the standard library into a new library, libcore. This new library has 0 dependencies (in theory). In practice, this library currently depends on these symbols being available:

* `rust_begin_unwind` and `rust_fail_bounds_check` - These are the two entry points of failure in libcore. The symbols are provided by libstd currently. In the future (see the bullets on #13851) this will be officially supported with nice error mesages. Additionally, there will only be one failure entry point once `std::fmt` migrates to libcore.
* `memcpy` - This is often generated by LLVM. This is also quite trivial to implement for any platform, so I'm not too worried about this.
* `memcmp` - This is required for comparing strings. This function is quite common *everywhere*, so I don't feel to bad about relying on a consumer of libcore to define it.
* `malloc` and `free` - This is quite unfortunate, and is a temporary stopgap until we deal with the `~` situation. More details can be found in the module `core::should_not_exist`
* `fmod` and `fmodf` - These exist because the `Rem` trait is defined in libcore, so the `Rem` implementation for floats must also be defined in libcore. I imagine that any platform using floating-point modulus will have these symbols anyway, and otherwise they will be optimized out.
* `fdim` and `fdimf` - Like `fmod`, these are from the `Signed` trait being defined in libcore. I don't expect this to be much of a problem

These dependencies all "Just Work" for now because libcore only exists as an rlib, not as a dylib.

The commits themselves are organized to show that the overall diff of this extraction is not all that large. Most modules were able to be moved with very few modifications. The primary module left out of this iteration is `std::fmt`. I plan on migrating the `fmt` module to libcore, but I chose to not do so at this time because it had implications on the `Writer` trait that I wanted to deal with in isolation. There are a few breaking changes in these commits, but they are fairly minor, and are all labeled with `[breaking-change]`.

The nastiest parts of this movement come up with `~[T]` and `~str` being language-defined types today. I believe that much of this nastiness will get better over time as we migrate towards `Vec<T>` and `Str` (or whatever the types will be named). There will likely always be some extension traits, but the situation won't be as bad as it is today.

Known deficiencies:

* rustdoc will get worse in terms of readability. This is the next issue I will tackle as part of #13851. If others think that the rustdoc change should happen first, I can also table this to fix rustdoc first.
* The compiler reveals that all these types are reexports via error messages like `core::option::Option`. This is filed as #13065, and I believe that issue would have a higher priority now. I do not currently plan on fixing that as part of #13851. If others believe that this issue should be fixed, I can also place it on the roadmap for #13851.

I recommend viewing these changes on a commit-by-commit basis. The overall change is likely too overwhelming to take in.
@emberian
Copy link
Member

@alexcrichton this didn't change any of the documentation; at least the manual (http://static.rust-lang.org/doc/master/rust.html#linkage) has outdated information.

@alexcrichton
Copy link
Member Author

Oops, thanks!

alexcrichton added a commit to alexcrichton/rust that referenced this pull request May 12, 2014
After allowing mixing rlibs and dylibs in rust-lang#13892, the documentation was not
updated accordingly to reflect this new capability.
alexcrichton added a commit to alexcrichton/rust that referenced this pull request May 13, 2014
After allowing mixing rlibs and dylibs in rust-lang#13892, the documentation was not
updated accordingly to reflect this new capability.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants