Skip to content

Expose musl/libc++/clang toolchain externally #946

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

Closed
LucioFranco opened this issue Sep 27, 2019 · 14 comments
Closed

Expose musl/libc++/clang toolchain externally #946

LucioFranco opened this issue Sep 27, 2019 · 14 comments
Labels
have: nice This feature is nice to have. It is low priority. needs: approval Needs review & approval before work can begin. type: task Generic non-code related tasks

Comments

@LucioFranco
Copy link
Contributor

LucioFranco commented Sep 27, 2019

@a-rodin has built a pretty fantastic toolchain image that can compile rust binaries that include c++/c dependencies with cross-lang lto. This is something that is non-trivial and could benefit the wider rust community.

I suggest that we create a separate repo to keep track of this toolchain image and then have vectors specific builder add the dependencies like OpenSSL. This would also benefit us in the fact that we would not need to rebuild the whole image compiling llvm, rustc, and clang each time we would like to add a new dependency to the build/release process.

Reference #945 (comment)

@ghost
Copy link

ghost commented Sep 27, 2019

Thanks @LucioFranco. I like this idea.

The cross-lang LTO was actually disabled later because typetag's dependency rust-ctor didn't support LLD. The problem seems to be solved recently in this PR, where, notably, there is a call from the maintainer for creating a test case using alternative linkers. I think we can publish a builder image with cross-lang LTO enabled and also contribute to rust-ctor by creating a test using our image for building.

@binarylogic
Copy link
Contributor

This is a naive question, but would that actually benefit other Rust developers, or is it highly specific to Vector?

@binarylogic binarylogic added domain: operations needs: approval Needs review & approval before work can begin. type: task Generic non-code related tasks labels Sep 27, 2019
@binarylogic
Copy link
Contributor

Please ignore my comment, I just read the conversation on the PR 😄

@ghost
Copy link

ghost commented Oct 9, 2019

Additionally, I think we can unify it with the builder for armv7-unknown-linux-musleabihf.

@LucioFranco
Copy link
Contributor Author

@a-rodin does clang support changing its target like rustc can? Meaning we can build multiple toolchains into the image?

@ghost
Copy link

ghost commented Oct 9, 2019

Clang itself supports, although the libraries would need to be put into separate prefixes. However, I was thinking about having a single Dockerfile, but two images that are built with different build args, probably in CI.

@ghost
Copy link

ghost commented Oct 9, 2019

Also, with multi-arch support in place we would be able to easily create builders for i386-unknown-linux-musl and aarch64-unknown-linux-musl.

@LucioFranco
Copy link
Contributor Author

Yeah, that makes sense!

@ghost
Copy link

ghost commented Oct 16, 2019

I think it makes sense to do this after #859, #1035, and #1036 are done (but not necessarily merged) to stabilize requirements for the exposed toolchains.

@ghost
Copy link

ghost commented Nov 1, 2019

I've created a repository https://github.com/timberio/rust-toolchain. For now it contains only a Dockerfile which can be built with different args, the idea is to use supply different in CircleCI to create images for different target architectures.

@binarylogic
Copy link
Contributor

Re-opening this since we want to move these images into the Vector repo and re-build the images each night (or maintain them in some way)

@binarylogic binarylogic assigned MOZGIII and unassigned ghost Feb 10, 2020
@binarylogic
Copy link
Contributor

Noting, this should be part of our migration to GH actions.

@binarylogic binarylogic added this to the Move to Github Actions milestone Feb 10, 2020
@binarylogic binarylogic assigned ghost and unassigned MOZGIII Apr 4, 2020
@binarylogic binarylogic unassigned ghost May 4, 2020
@binarylogic
Copy link
Contributor

Marking this as low priority since we seem to be moving towards Glibc builds.

@binarylogic binarylogic added the have: nice This feature is nice to have. It is low priority. label May 4, 2020
@binarylogic
Copy link
Contributor

Closing this since we're moving to glibc.

@binarylogic binarylogic removed this from the Move to Github Actions milestone Jul 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
have: nice This feature is nice to have. It is low priority. needs: approval Needs review & approval before work can begin. type: task Generic non-code related tasks
Projects
None yet
Development

No branches or pull requests

3 participants