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

Statically link the runtime to core #3361

Closed
brson opened this issue Sep 3, 2012 · 5 comments
Closed

Statically link the runtime to core #3361

brson opened this issue Sep 3, 2012 · 5 comments
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup.

Comments

@brson
Copy link
Contributor

brson commented Sep 3, 2012

The core library is now the Rust runtime, so the runtime doesn't need to exist as a dynamic library. std and a number of tests currently make calls directly into rt, so those dependencies will need to be severed.

@catamorphism
Copy link
Contributor

Not critical for 0.6, de-milestoning

@catamorphism
Copy link
Contributor

Nominating for milestone 5, production-ready

@bstrie
Copy link
Contributor

bstrie commented May 29, 2013

I've opened #6809 for the sub-task of severing the dependencies between the runtime and libextra/the test suite.

@graydon
Copy link
Contributor

graydon commented Jun 20, 2013

just a bug, removing milestone/nomination.

@catamorphism
Copy link
Contributor

Bug triage; carry on.

alexcrichton added a commit to alexcrichton/rust that referenced this issue Nov 19, 2013
This commit alters the build process of the compiler to build a static
librustrt.a instead of a dynamic version. This means that we can stop
distributing librustrt as well as default linking against it in the compiler.

This also means that if you attempt to build rust code without libstd, it will
no longer work if there are any landing pads in play. The reason for this is
that LLVM and rustc will emit calls to the various upcalls in librustrt used to
manage exception handling. In theory we could split librustrt into librustrt and
librustupcall. We would then distribute librustupcall and link to it for all
programs using landing pads, but I would rather see just one librustrt artifact
and simplify the build process.

The major benefit of doing this is that building a static rust library for use
in embedded situations all of a sudden just became a whole lot more feasible.

Closes rust-lang#3361
jaisnan added a commit to jaisnan/rust-dev that referenced this issue Jul 29, 2024
This regression test ensures that issue rust-lang#2874 does not reoccur, which
was last encountered in commit 9190831.

Resolves rust-lang#2874

By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 and MIT licenses.

---------

Co-authored-by: Jacob Salzberg <salzber@amazon.com>
Co-authored-by: Jaisurya Nanduri <91620234+jaisnan@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup.
Projects
None yet
Development

No branches or pull requests

4 participants