Skip to content

liballoc does not need liblibc under certain configurations #20237

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

Merged
merged 5 commits into from
Jan 8, 2015

Conversation

Ericson2314
Copy link
Contributor

libc is only used when the heap allocations are not defined externally, or defined in another crate. I assume these extern* configurations were added for the sake of those of us experimenting with freestanding Rust. Avoiding libc where possible is often very important for us.

@rust-highfive
Copy link
Contributor

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see CONTRIBUTING.md for more information.

@Ericson2314
Copy link
Contributor Author

This should be g2g. The second commit was needed because the 100 char lint. The third fixes preexisting bugs.

@emberian
Copy link
Member

emberian commented Jan 3, 2015

Looks good to me, #rust-osdev has been clamoring for this. @aturon / @alexcrichton what do you think about the use of feature here? AIUI the #rust-osdev people have pulled this out into a cargoified crate.

@Ericson2314
Copy link
Contributor Author

Yup, I am building core through collections, and an allocator in a separate crate, all with cargo and everything is working great! I see that "feature" isn't the ideal word for this, but seeing that's what cargo offers I can only hope a stray feature behind the facade is better than one on it.

@alexcrichton
Copy link
Member

Huh, I thought I saw this get approved awhile ago. Sorry this has been sitting for awhile @Ericson2314!

I'm not sure that we'll want to commit long-term to a strategy like this, but I'm pretty ok with this for now as it's basically just an experimental crate. So long as it builds for master continuously, we should be good!

@Ericson2314
Copy link
Contributor Author

No worries at all, cmr did r+ it, but then i pushed more commits. Yeah long term the allocator API will render messing with liballoc unnecessary I assume. Thank you both!

bors added a commit that referenced this pull request Jan 3, 2015
…crichton

libc is only used when the heap allocations are not defined externally, or defined in another crate. I assume these extern* configurations were added for the sake of those of us experimenting with freestanding Rust. Avoiding libc where possible is often very important for us.
alexcrichton added a commit to alexcrichton/rust that referenced this pull request Jan 8, 2015
libc is only used when the heap allocations are not defined externally, or defined in another crate. I assume these extern* configurations were added for the sake of those of us experimenting with freestanding Rust. Avoiding libc where possible is often very important for us.
@bors bors merged commit b1b4bc9 into rust-lang:master Jan 8, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants