Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Reorganize llvm and clang libs and bindings #2373

brson opened this Issue May 10, 2012 · 8 comments


None yet
5 participants

brson commented May 10, 2012

Right now we have a native library, rustllvm, that contains LLVM + some extra Rust-specific glue-code, and we have hand-written LLVM bindings in rustc. Soon we will also need clang bindings.

As part of integrating bindgen and its clang bindings I would like to restructure our llvm libs.

The gist of it is that we have two rust crates, llvm and clang, which contain bindings and are statically linked to their native libraries. The primary benefit is that we will have no native libraries for rust-based llvm consumers to deal with. The secondary benefit is that it clearly exposes the rust APIs for llvm so other tools can use them.

@ghost ghost assigned brson May 10, 2012


brson commented May 12, 2012

This arrangement probably won't work when it's time to make official Debian packages.

cinch commented Sep 30, 2012

when compiling the entire rust from a release tarball: why not depend on the host LLVM/Clang, if its installed?
"aptitude install llvm clang" and call it a day?
i'm getting build issues which are from fixed bugs in clang, which havent made it into rust yet, and the whole compile takes forever.
just an idea.


brson commented Sep 30, 2012

We have a number of GC-related patches on our fork right now, but the goal is to work on stock LLVM eventually.


brson commented Sep 30, 2012

With some effort we could probably get Rust to work with upstream LLVM, because the GC stuff is releatively self contained and only used in experimental builds.


pnkfelix commented Mar 22, 2013

Not critical for 0.6; de-milestoning


pnkfelix commented Jul 16, 2013

visiting for triage. I considered nominating this for a milestone, but honestly, I could imagine shipping 1.0 without teasing out our locally patched LLVM.

@brson When you said "This arrangement probably won't work when it's time to make official Debian packages.", which arrangement were you referring to? The current arrangement? Or the one you proposed? (my best guess is that you were referring to the current arrangement.)


thestinger commented Sep 11, 2013

Debian and Fedora aren't going to care for us not using the upstream LLVM, and we're going to need to be able to use the system libuv/gyp.


alexcrichton commented Feb 1, 2014

We have no clang bindings, and otherwise all the points of the issue have been worked out. The llvm and rustllvm libraries are both statically linked into rustc, so we don't have to worry about their distribution at all any more.

Closing in favor of #8275 (which is what's left to do on this issue).

@brson brson referenced this issue in Mozilla-Student-Projects/Projects-Tracker Sep 24, 2012


Improve Rust's integration with C code #26

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