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

Do static linking by default #10209

Closed
brson opened this Issue Oct 31, 2013 · 7 comments

Comments

Projects
None yet
5 participants
@brson
Contributor

brson commented Oct 31, 2013

I currently believe there is little hope that Rust libraries can offer any meaningful binary forward compatibility or upgradability. Since this is one of the primary benefits of dynamic linking (the other being reduction in code size), and static linking having other advantages of convenience, perhaps we should prefer static linking by default.

cc #10208 #10188

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Nov 1, 2013

Contributor

Nominating, though I think we can live without this for 1.0

Contributor

brson commented Nov 1, 2013

Nominating, though I think we can live without this for 1.0

@pnkfelix

This comment has been minimized.

Show comment
Hide comment
@pnkfelix

pnkfelix Nov 7, 2013

Member

P-low, not necessary to do this (or decide about doing it) for 1.0.

Member

pnkfelix commented Nov 7, 2013

P-low, not necessary to do this (or decide about doing it) for 1.0.

@wycats

This comment has been minimized.

Show comment
Hide comment
@wycats

wycats Nov 14, 2013

Contributor

As an embedded user of Rust, this would be really really nice and would make 1.0 significantly more appealing.

Contributor

wycats commented Nov 14, 2013

As an embedded user of Rust, this would be really really nice and would make 1.0 significantly more appealing.

@liigo

This comment has been minimized.

Show comment
Hide comment
@liigo

liigo Nov 14, 2013

Contributor

+1 for static linking by default

Contributor

liigo commented Nov 14, 2013

+1 for static linking by default

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Dec 1, 2013

Member

I believe that as it stands today #10740 blocks this bug.

Member

alexcrichton commented Dec 1, 2013

I believe that as it stands today #10740 blocks this bug.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Dec 17, 2013

Member

Now that #10740 is closed, I'm still not entirely convinced that we should do this by default. This makes linking fn main() {} 4.5x slower from 20ms to 90ms, which is a pretty noticeable hit when dealing with small programs. We should investigate how to optimize compile times for small programs and then I believe that static linking would be an excellent default.

Member

alexcrichton commented Dec 17, 2013

Now that #10740 is closed, I'm still not entirely convinced that we should do this by default. This makes linking fn main() {} 4.5x slower from 20ms to 90ms, which is a pretty noticeable hit when dealing with small programs. We should investigate how to optimize compile times for small programs and then I believe that static linking would be an excellent default.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jan 19, 2014

Member

Closing, we prefer static linking by default, and #11253 is the tracker for whether we should output an rlib or a dylib by default for libraries.

Member

alexcrichton commented Jan 19, 2014

Closing, we prefer static linking by default, and #11253 is the tracker for whether we should output an rlib or a dylib by default for libraries.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment