rustc: Add a new crate type, cdylib #33553

Merged
merged 2 commits into from May 20, 2016

Projects

None yet

9 participants

@alexcrichton
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
Collaborator

r? @jroesch

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

@alexcrichton
Member

r? @brson

@rust-highfive rust-highfive assigned brson and unassigned jroesch May 11, 2016
@brson
Contributor
brson commented May 13, 2016

@bors r+

@brson brson closed this May 13, 2016
@bors
Contributor
bors commented May 13, 2016

๐Ÿ“Œ Commit a3f5d08 has been approved by brson

@brson brson reopened this May 13, 2016
@eddyb eddyb added a commit to eddyb/rust that referenced this pull request May 13, 2016
@eddyb eddyb Rollup merge of #33553 - alexcrichton:cdylibs, r=brson
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
63fdbd7
@eddyb eddyb referenced this pull request May 13, 2016
Closed

Rollup of 29 pull requests #33610

@bors bors added a commit that referenced this pull request May 13, 2016
@bors bors Auto merge of #33610 - eddyb:rollup, r=eddyb
Rollup of 29 pull requests

- Successful merges: #33342, #33393, #33450, #33491, #33508, #33513, #33517, #33531, #33532, #33533, #33534, #33538, #33541, #33544, #33552, #33553, #33555, #33560, #33563, #33565, #33566, #33572, #33576, #33580, #33590, #33593, #33596, #33598, #33600
- Failed merges: #33578, #33602
1db8651
@eddyb eddyb commented on an outdated diff May 13, 2016
src/librustc_trans/back/linker.rs
@@ -198,8 +201,30 @@ impl<'a> Linker for GnuLinker<'a> {
self.cmd.arg("-Wl,-Bdynamic");
}
- fn export_symbols(&mut self, _: &Session, _: &CrateTranslation, _: &Path) {
- // noop, visibility in object files takes care of this
+ fn export_symbols(&mut self,
+ sess: &Session,
+ trans: &CrateTranslation,
+ tmpdir: &Path,
+ crate_type: CrateType) {
+ let path = tmpdir.join("list");
+ let res = (|| -> io::Result<()> {
+ let mut f = BufWriter::new(File::create(&path)?);
+ for sym in exported_symbols(sess, trans, crate_type) {
+ writeln!(f, " {}", sym)?;
@eddyb
eddyb May 13, 2016 Member

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

@eddyb
Member
eddyb commented May 13, 2016

@bors r- Likely responsible for this failure.

@alexcrichton
Member

Indeed! looks quite suspicious

@alexcrichton
Member

@bors: r=brson bfe7a80

@bors bors added a commit that referenced this pull request May 13, 2016
@bors bors Auto merge of #33610 - eddyb:rollup, r=eddyb
Rollup of 29 pull requests

- Successful merges: #33342, #33393, #33450, #33491, #33508, #33513, #33517, #33531, #33532, #33533, #33534, #33538, #33541, #33544, #33552, #33553, #33555, #33560, #33563, #33565, #33566, #33572, #33576, #33580, #33590, #33593, #33596, #33598, #33600
- Failed merges: #33578, #33602
a2831f7
@bors bors added a commit that referenced this pull request May 13, 2016
@bors bors Auto merge of #33610 - eddyb:rollup, r=eddyb
Rollup of 29 pull requests

- Successful merges: #33342, #33393, #33450, #33491, #33508, #33513, #33517, #33531, #33532, #33533, #33534, #33538, #33541, #33544, #33552, #33553, #33555, #33560, #33563, #33565, #33566, #33572, #33576, #33580, #33590, #33593, #33596, #33598, #33600
- Failed merges: #33578, #33602
244b73d
@Manishearth
Member

Travis fails

@bors
Contributor
bors commented May 14, 2016

โŒ›๏ธ Testing commit bfe7a80 with merge 2d45326...

@bors bors added a commit that referenced this pull request May 14, 2016
@bors bors Auto merge of #33553 - alexcrichton:cdylibs, r=brson
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
2d45326
@bors
Contributor
bors commented May 14, 2016

๐Ÿ’” Test failed - auto-mac-64-opt-rustbuild

@eddyb
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
Member

@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
Contributor
bors commented May 17, 2016

โŒ›๏ธ Testing commit 557aae0 with merge 3ad8865...

@bors bors added a commit that referenced this pull request May 17, 2016
@bors bors Auto merge of #33553 - alexcrichton:cdylibs, r=brson
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
3ad8865
@bors
Contributor
bors commented May 17, 2016

๐Ÿ’” Test failed - auto-linux-64-opt-rustbuild

@alexcrichton
Member

@bors: r=brson e3517db

@bors
Contributor
bors commented May 18, 2016

โŒ›๏ธ Testing commit e3517db with merge 8dc0f92...

@bors bors added a commit that referenced this pull request May 18, 2016
@bors bors Auto merge of #33553 - alexcrichton:cdylibs, r=brson
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
8dc0f92
@bors
Contributor
bors commented May 18, 2016

๐Ÿ’” Test failed - auto-win-msvc-64-opt-rustbuild

@retep998 retep998 commented on an outdated diff May 18, 2016
src/test/run-make/cdylib/Makefile
@@ -0,0 +1,10 @@
+include ../tools.mk
+
+all:
+ $(RUSTC) bar.rs
+ $(RUSTC) foo.rs
+ $(CC) $(CFLAGS) foo.c -lfoo -o $(call RUN_BINFILE,foo) -L $(TMPDIR)
@retep998
retep998 May 18, 2016 Member

This won't work for msvc.

@alexcrichton
Member

@bors: r=brson 451ab72

@alexcrichton
Member

@bors: r=brson 3a6926a

@bors
Contributor
bors commented May 18, 2016

โŒ›๏ธ Testing commit 3a6926a with merge 8915757...

@bors bors added a commit that referenced this pull request May 18, 2016
@bors bors Auto merge of #33553 - alexcrichton:cdylibs, r=brson
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
8915757
@bors
Contributor
bors commented May 18, 2016

๐Ÿ’” Test failed - auto-win-msvc-64-opt-rustbuild

@alexcrichton
Member

@bors: r=brson 698ba68

@bors
Contributor
bors commented May 19, 2016

โŒ›๏ธ Testing commit 698ba68 with merge 2e0b0d3...

@bors bors added a commit that referenced this pull request May 19, 2016
@bors bors Auto merge of #33553 - alexcrichton:cdylibs, r=brson
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
2e0b0d3
@bors
Contributor
bors commented May 19, 2016

๐Ÿ’” Test failed - auto-linux-musl-64-opt

@alexcrichton
Member

@bors: r=brson 0192796

@bors
Contributor
bors commented May 19, 2016

โŒ›๏ธ Testing commit 0192796 with merge 89347bf...

@bors bors added a commit that referenced this pull request May 19, 2016
@bors bors Auto merge of #33553 - alexcrichton:cdylibs, r=brson
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
89347bf
@bors
Contributor
bors commented May 19, 2016

๐Ÿ’” Test failed - auto-mac-64-nopt-t

alexcrichton and others added some commits May 10, 2016
@alexcrichton alexcrichton 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
07d373f
@eddyb @alexcrichton eddyb Mark the metadata symbol as reachable to fix OSX not finding dylibs.
0d2c26c
@alexcrichton
Member

@bors: r=brson 0d2c26c

@bors
Contributor
bors commented May 20, 2016

โŒ›๏ธ Testing commit 0d2c26c with merge d27bdaf...

@bors bors added a commit that referenced this pull request May 20, 2016
@bors bors Auto merge of #33553 - alexcrichton:cdylibs, r=brson
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
d27bdaf
@bors bors merged commit 0d2c26c into rust-lang:master May 20, 2016

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details
@bluss bluss added the relnotes label May 21, 2016
@bluss
Contributor
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.

@alexcrichton alexcrichton deleted the alexcrichton:cdylibs branch May 25, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment