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

Tracking issue for adding a new cdylib crate type #33132

Closed
alexcrichton opened this issue Apr 21, 2016 · 0 comments
Closed

Tracking issue for adding a new cdylib crate type #33132

alexcrichton opened this issue Apr 21, 2016 · 0 comments
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented.

Comments

@alexcrichton
Copy link
Member

Tracking issue for rust-lang/rfcs#1510

@alexcrichton alexcrichton added T-tools B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. labels Apr 21, 2016
eddyb pushed a commit to eddyb/rust that referenced this issue May 16, 2016
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 added a commit to alexcrichton/rust that referenced this issue May 18, 2016
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
bors added a commit that referenced this issue 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
alexcrichton added a commit to alexcrichton/rust that referenced this issue May 19, 2016
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
bors added a commit that referenced this issue 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented.
Projects
None yet
Development

No branches or pull requests

1 participant