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 a new crate type, cdylib #33553

Merged
merged 2 commits into from
May 20, 2016
Merged

Conversation

alexcrichton
Copy link
Member

This commit is an implementation of RFC 1510 which adds a new crate type,
cdylib, to the compiler. This new crate type differs from the existing dylib
crate type in a few key ways:

  • No metadata is present in the final artifact
  • Symbol visibility rules are the same as executables, that is only reachable
    extern functions are visible symbols
  • LTO is allowed
  • All libraries are always linked statically

This commit is relatively simple by just plubming the compiler with another
crate type which takes different branches here and there. The only major change
is an implementation of the Linker::export_symbols function on Unix which now
actually does something. This helps restrict the public symbols from a cdylib on
Unix.

With this PR a "hello world" cdylib is 7.2K while the same dylib is 2.4MB,
which is some nice size savings!

Closes #33132

@rust-highfive
Copy link
Collaborator

r? @jroesch

(rust_highfive has picked a reviewer for you, use r? to override)

@alexcrichton
Copy link
Member Author

r? @brson

@rust-highfive rust-highfive assigned brson and unassigned jroesch May 11, 2016
@brson
Copy link
Contributor

brson commented May 13, 2016

@bors r+

@brson brson closed this May 13, 2016
@bors
Copy link
Contributor

bors commented May 13, 2016

📌 Commit a3f5d08 has been approved by brson

@brson brson reopened this May 13, 2016
let res = (|| -> io::Result<()> {
let mut f = BufWriter::new(File::create(&path)?);
for sym in exported_symbols(sess, trans, crate_type) {
writeln!(f, " {}", sym)?;
Copy link
Member

Choose a reason for hiding this comment

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

This doesn't seem to be enough for iOS, see failure.

@eddyb
Copy link
Member

eddyb commented May 13, 2016

@bors r- Likely responsible for this failure.

@alexcrichton
Copy link
Member Author

Indeed! looks quite suspicious

@alexcrichton
Copy link
Member Author

@bors: r=brson bfe7a80

@Manishearth
Copy link
Member

Travis fails

@bors
Copy link
Contributor

bors commented May 14, 2016

⌛ Testing commit bfe7a80 with merge 2d45326...

@bors
Copy link
Contributor

bors commented May 14, 2016

💔 Test failed - auto-mac-64-opt-rustbuild

@eddyb
Copy link
Member

eddyb commented May 14, 2016

I'm working on rebasing this over #33602 because otherwise I'd need windows to investigate my metadata problem.
Could be delayed for a few days by my flight, so if you don't hear anything from me, feel free to merge this.

@alexcrichton
Copy link
Member Author

@bors: r=brson 557aae0

@eddyb I've applied your patch to retain the metadata symbol for dylibs, let's see how far it gets...

@bors
Copy link
Contributor

bors commented May 17, 2016

⌛ Testing commit 557aae0 with merge 3ad8865...

@bors
Copy link
Contributor

bors commented May 17, 2016

💔 Test failed - auto-linux-64-opt-rustbuild

bors added a commit that referenced this pull request May 19, 2016
rustc: Add a new crate type, cdylib

This commit is an implementation of [RFC 1510] which adds a new crate type,
`cdylib`, to the compiler. This new crate type differs from the existing `dylib`
crate type in a few key ways:

* No metadata is present in the final artifact
* Symbol visibility rules are the same as executables, that is only reachable
  `extern` functions are visible symbols
* LTO is allowed
* All libraries are always linked statically

This commit is relatively simple by just plubming the compiler with another
crate type which takes different branches here and there. The only major change
is an implementation of the `Linker::export_symbols` function on Unix which now
actually does something. This helps restrict the public symbols from a cdylib on
Unix.

With this PR a "hello world" `cdylib` is 7.2K while the same `dylib` is 2.4MB,
which is some nice size savings!

[RFC 1510]: rust-lang/rfcs#1510

Closes #33132
@bors
Copy link
Contributor

bors commented May 19, 2016

💔 Test failed - auto-linux-musl-64-opt

@alexcrichton
Copy link
Member Author

@bors: r=brson 0192796

@bors
Copy link
Contributor

bors commented May 19, 2016

⌛ Testing commit 0192796 with merge 89347bf...

@bors
Copy link
Contributor

bors commented May 19, 2016

💔 Test failed - auto-mac-64-nopt-t

alexcrichton and others added 2 commits May 19, 2016 15:32
This commit is an implementation of [RFC 1510] which adds a new crate type,
`cdylib`, to the compiler. This new crate type differs from the existing `dylib`
crate type in a few key ways:

* No metadata is present in the final artifact
* Symbol visibility rules are the same as executables, that is only reachable
  `extern` functions are visible symbols
* LTO is allowed
* All libraries are always linked statically

This commit is relatively simple by just plubming the compiler with another
crate type which takes different branches here and there. The only major change
is an implementation of the `Linker::export_symbols` function on Unix which now
actually does something. This helps restrict the public symbols from a cdylib on
Unix.

With this PR a "hello world" `cdylib` is 7.2K while the same `dylib` is 2.4MB,
which is some nice size savings!

[RFC 1510]: rust-lang/rfcs#1510

Closes rust-lang#33132
@alexcrichton
Copy link
Member Author

@bors: r=brson 0d2c26c

@bors
Copy link
Contributor

bors commented May 20, 2016

⌛ Testing commit 0d2c26c with merge d27bdaf...

bors added a commit that referenced this pull request May 20, 2016
rustc: Add a new crate type, cdylib

This commit is an implementation of [RFC 1510] which adds a new crate type,
`cdylib`, to the compiler. This new crate type differs from the existing `dylib`
crate type in a few key ways:

* No metadata is present in the final artifact
* Symbol visibility rules are the same as executables, that is only reachable
  `extern` functions are visible symbols
* LTO is allowed
* All libraries are always linked statically

This commit is relatively simple by just plubming the compiler with another
crate type which takes different branches here and there. The only major change
is an implementation of the `Linker::export_symbols` function on Unix which now
actually does something. This helps restrict the public symbols from a cdylib on
Unix.

With this PR a "hello world" `cdylib` is 7.2K while the same `dylib` is 2.4MB,
which is some nice size savings!

[RFC 1510]: rust-lang/rfcs#1510

Closes #33132
@bors bors merged commit 0d2c26c into rust-lang:master May 20, 2016
@bluss bluss added the relnotes Marks issues that should be documented in the release notes of the next release. label May 21, 2016
@bluss
Copy link
Member

bluss commented May 21, 2016

This is kind of immediately a new feature on the stable release where this is included, isn't it? If I'm wrong, then the relnote tag can be removed again.

@torkleyy
Copy link

torkleyy commented Apr 9, 2017

@alexcrichton How can I compile a crate as cdylib without modifying Cargo.toml? I thought it would be cargo rustc -- --crate-type cdylib, but the crate-type option is just ignored.

@alexcrichton
Copy link
Member Author

@torkleyy unfortunately that's not possible right now (short of generating a new Cargo.toml. Would you like to open a new issue at rust-lang/cargo?

@torkleyy
Copy link

@alexcrichton Thanks for your reply!

Would you like to open a new issue at rust-lang/cargo?

Sure, I'll do that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
relnotes Marks issues that should be documented in the release notes of the next release.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants