https://linen.dev logo
Powered by
Deploy fails because build step requires clang
# help
a
Original message from @white-daybreak-71067 I'm just trying to deploy for the first time and my nsi-sys crate fails. The latter is a wrapper crate that runs bindgen during build.rs and requires clang (or parts of it) because of this:
Copy code
2023-04-19T17:18:15.920848368Z  INFO error: failed to run custom build command for `nsi-sys v0.7.0`
2023-04-19T17:18:15.923115118Z  INFO 
2023-04-19T17:18:15.925751628Z  INFO Caused by:
2023-04-19T17:18:15.928176656Z  INFO   process didn't exit successfully: `/opt/shuttle/shuttle-builds/polyhedrobot/target/release/build/nsi-sys-18bb7f3eda5b6449/build-script-build` (exit status: 101)
2023-04-19T17:18:15.930241605Z  INFO   --- stdout
2023-04-19T17:18:15.932268555Z  INFO   cargo:rerun-if-changed=include/wrapper.h
2023-04-19T17:18:15.934279858Z  INFO   cargo:rerun-if-env-changed=TARGET
2023-04-19T17:18:15.936822625Z  INFO   cargo:rerun-if-env-changed=BINDGEN_EXTRA_CLANG_ARGS_x86_64-unknown-linux-gnu
2023-04-19T17:18:15.939131674Z  INFO   cargo:rerun-if-env-changed=BINDGEN_EXTRA_CLANG_ARGS_x86_64_unknown_linux_gnu
2023-04-19T17:18:15.941228988Z  INFO   cargo:rerun-if-env-changed=BINDGEN_EXTRA_CLANG_ARGS
2023-04-19T17:18:15.943294478Z  INFO 
2023-04-19T17:18:15.945689639Z  INFO   --- stderr
2023-04-19T17:18:15.947817198Z  INFO   include: /usr/local/cargo/registry/src/panamax-d16f25348226fbb1/nsi-sys-0.7.0/include
2023-04-19T17:18:15.950151660Z  INFO   thread 'main' panicked at 'Unable to find libclang: "couldn't find any valid shared libraries matching: ['libclang.so', 'libclang-*.so', 'libclang.so.*', 'libclang-*.so.*'], set the `LIBCLANG_PATH` environment variable to a path where one of these files can be found (invalid: [])"', /usr/local/cargo/registry/src/panamax-d16f25348226fbb1/bindgen-0.65.1/lib.rs:603:31
2023-04-19T17:18:15.952413420Z  INFO   note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
2023-04-19T17:18:15.954583857Z  INFO warning: build failed, waiting for other jobs to finish...
5]josh: I'm not sure but I don't think this is something that should work at the moment (due to not having clang stuff). I'll get in touch with engineering for you re this 16:47]virtualritz: Well, the stuff I work on often uses wrapper crates. And that means the wrapped lib is usually C/C++. And needs to be built during cargo build. [16:47]virtualritz: I would say this is fairly common. [16:48]virtualritz: Another thing I was curios about but couldn't get to yet as the build broke before is downloading and linking a closed source 3rd party lib. My nsi-core crate downloads the 3Delight renderer during build and dynamically loads symbols from that lib at runtime. [16:48]virtualritz: I.e. the system's dynamic linker does not know about this. [16:49]virtualritz: The downloaded artifact must be 'in place' at runtime. I am very curious if this will work.
Actually I was just wondering - would static linking maybe be something we could try?
w
Maybe there is some confusion here.
The build above breaks on 
bindgen
(not my crate) which tries to run 
clang
as part of the 
build.rs
of the 
nsi-sys
crate.
What I was talking about after is if the 
build.rs
of the 
nsi-core
crate will have the desired effect. But that depends on 
nsi-sys
so we need get that to build on your infrastructure first. 🙂
While that crate supports actual linking it can't support static linking since there is no such artifact distributed by 3Delight. You can only get 
lib3delight.{so/dylib/dll}
. There is no 
lib3delight.{a/lib}
artifact. The best my crate can hence do is dynamically link against the lib at compile time. But that still means the host system's dynamic linker must find it at runtime. I.e. either it needs to live alongside the deployed executable or 
LD_LIBRARY_PATH
(Linux/macOS) resp. 
PATH
(Windows) needs to be set so it can be found.
Hence my curiosity if either of this will work. But let's first resolve the missing 
clang
issue for 
bindgen
.
I think 
bindgen
is popular enough that this will become a concern for shuttle soonish anyway.
k
Hey! We have a feature request for specifying native dependencies, but we haven't put much thought into the implementation yet:
The simplest solution in the meantime would be to install 
clang
in all deployer images, but I'm not sure what the drawbacks would be. 🤔
As for the .so file the executable will be put in a separate directory from the source code after it is compiled, so I'm not sure that will work without the 
LD_LIBRARY_PATH
being set. Which you won't be able to set before compilation.
We'd like to support this though if we can, thanks for the write-up of your requirements. It's a bit late here but I'll think about this, and feel free to add to this/correct me if I've misunderstood something!
g
I have found a hacky way to add external dependencies. Will polish it a bit (verify that it works for a real project) and can then show how to do it (maybe even in docs) until #703 is designed.
The initial idea had severe drawbacks, and didn't work for my project, so made a new workaround with a new and fresh set of other drawbacks 😊. But now it works at least 😄 ...almost ...3hrs later: finally 😐
This is my solution https://github.com/shuttle-hq/shuttle/issues/703#issuecomment-1515606621 My discord bot that could not run in shuttle after i added voice chat can now run due to this 😄
w
I think if the lib is downloaded during build, it goes into 
target/release/nsi-core
. But what I could do is have it go into some folder I read from the environment.
I.e. if shuttle shared the final executable destination via an environment variable during 
build.rs
, and this destination already existed and was readable, any artifacts required at runtime could be stashed there by 
build.rs
. This would work for the second issue, an opaque dylib artifact dependency.
For the first case, while I appreciate the work @gentle-ice-1561 has done, the reason I would use shuttle is exactly to avoid fiddling like this. I.e. I would like stuff to just work as it does already on e.g. 
docs.rs
.
g
Yeah, the point of shuttle is to simplify deploys, so this is obv not a good enough solution. What do you think about the suggested designs I have in the GH issue?
w
I commented on the issue. 🙂
@kind-area-3810 That said: I think the basic build environment to compile C/C++ deps should be there. I.e. what you get on a GH runner w/o adding anything. See https://github.com/actions/runner-images#software-and-image-support. I will open a separate issue for this.
k
Thanks! I'll take a look in the morning.
Sorry @white-daybreak-71067, I got a bit swamped today. Your feature requests look very reasonable to me at first glance, but I'll need to get back to you next week.
w
No wuckers. Have great weekend! 😊
Regarding #807: I unfortunately don't have spare time for this for now. I got interested in shuttle because I always wanted to try running some of my side projects cloud-side w/o jumping through all the hoops this usually involves. And maybe even turn one of them into something that people would pay for. It seems some hoops are still there for now with shuttle for the stuff I do. I'm super happy to test anything that you guys come up with for #807 & #808 but I can't help with implementation atm.
k
That's very understandable! We'll see if we can get this going soon, but it might be de-prioritized until we finish pulling the building into a separate service. Thanks again for the well described issues!
PreviousNext
Powered by