Closed brainstorm closed 4 years ago
@softprops, after reading this, I wonder if we shall add this to the Dockerfile
:
rustup target add x86_64-unknown-linux-musl
And then on /usr/local/bin/build.sh
pass that same --target
accordingly?
sorry for the delay. I'll try to take a closer look into this with in the coming week.
Yay, thanks @softprops! Looking forward to have this merged in :)
:wave:
Sorry for the delay on this. There's actually a proposal that might help for custom dependency needs https://github.com/softprops/lambda-rust/issues/6
Oh yeah, that one looks neat! OTOH, my PR is really just including clang in the mix, that's a pretty common base requirement I reckon? :-S
Noticed the alinux2
docker container switch... perhaps clang is installed by default in Amazon Linux 2?
I understand the point made in #53 (divergence from upstream lambda environment/image)... OTOH, a quite rust-official docker container that cannot compile *-sys
(C bindgen/native) crates can be a bit disappointing DX.
That being said, let me refresh this branch a bit, there might be a more acceptable workaround than pulling in more deps than strictly necessary. If that works I can close this PR with some peace of mind about this ;)
Coincidentally that native rust crate requires docker to build (because cross and MUSL), so the level of inception would get a bit too ridiculous when combined with this builder XD
And now I understand what you mean, this is only meant to be a runtime environment, not a build-time env, closing.
Fixes issue #53, where an old LLVM/clang version was preventing rust-htslib crate from compiling inside the docker container.
Might affect other bindgen crates in the future so it is worth having
llvm-config
et al present on$PATH
and reasonably up to date, imho.Perhaps that clang version should be updated accordingly upstream on
lambci
container itself as well?