loopdev-3 does not build staticly

[richardstephens]

When building statically, loopdev-3 fails to build because bindgen cannot link libclang dynamically.

26.42 error: failed to run custom build command for `loopdev-3 v0.5.3`
26.42 
26.42 Caused by:
26.42   process didn't exit successfully: `/build/gallium/target/debug/build/loopdev-3-bbfda59809013abc/build-script-build` (exit status: 101)
26.42   --- stderr
26.42 
26.42   thread 'main' (4965) panicked at /usr/local/cargo/registry/src/index.crates.io-1949cf8c6b5b557f/bindgen-0.72.1/lib.rs:616:27:
26.42   Unable to find libclang: "the `libclang` shared library at /usr/lib/llvm21/lib/libclang.so.21.1.2 could not be opened: Dynamic loading not supported"
26.42   note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

It seems the most popular solution is to implement a command to generate bindings.rs and check in the generated copy. This also has the added benefit of providing a minor build speedup.

I am happy to open a PR with this if this solution is acceptable, or discuss alternatives.

[coderabbitai]

🔗 Related PRs

#69 - Increase bindgen dependency lower bound to 0.72.0 [merged]
#72 - loopdev-3 v0.5.3 [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[mulkieran]

@richardstephens Thanks for the issue. I think you might be combining two separate notions of "static". For the error that you have shown in the issue, I think the solution is to install clang. Then the build will proceed. That is how our CI always proceeds. The second idea of statically has to do with how loopdev builds and uses the bindings; in a single build step. I think that is unusual, but it has historically worked. Every other Rust library in the stratis-storage project uses a two-level design, where a separate library, implemented in the same repo, generates the bindings.rs file. The reason that I know of that loopdev-rs does not do the same is that we adopted it after it was abandoned by the original developer and have changed it just enough to keep it working since then. If you are convinced that this customary two level architecture is better and if that is your goal then let us know and we can try to work with you to adopt that architecture.

[richardstephens]

Hey @mulkieran - clang is already installed in this specific build environment - it is a requirement of other parts of our build.

The issue stems from the way bindgen works. It is not really possible to parse C header files without a C compiler. Invoking bindgen in a build script ends up using dlopen to load in the libclang, which is not supported in our build environment (Alpine Linux / musl libc, with RUSTFLAGS="-C target-feature=+crt-static")

In my fork over at https://github.com/richardstephens/loopdev-3 I have checked in a generated copy of the bindings.rs. We've switched the build that prompted the issue to reference this instead and they are working fine. I am happy to finish tidying up the code I used to generate this and open a PR.

There are alternative approaches and I'm happy to open a PR for one of those instead if you prefer, but I think the two-step process makes the most sense for a library like loopdev, which relies only on kernel functionality that has been stable for decades.

[mulkieran]

LOOP_CONFIGURE was added less than a decade ago, I think, so the library is not perfectly stable, though it does seem more stable than the libraries of the other Rust bindings that we support. I'm perplexed, though, because we have done some musl support in devicemapper-rs and this notion of simply packaging a previously generated bindings.rs file was not bruited in the discussions then. It looks like you are saying that in your build it is never possible to run bindgen because you do not support dynamically loading libclang. But that would require that all crates that you rely on that use bindgen-generated code follow the same approach as you are proposing for loopdev. I think it must be the case that many libraries do not get packaged with a previously generated bindings.rs file.

I do not think that we would be able to accept your changes as is.

However, I will do some investigation and see if some general workable solution to the problem you describe has been evolved by this time.

[richardstephens]

Here is a minimal Dockerfile that demonstrates the issue. (the Rust Alpine container applies RUSTFLAGS="-Ctarget-feature=+crt-static" by default)

FROM rust:1.96-alpine3.23

RUN apk add --no-cache build-base linux-headers clang-dev clang-static git

WORKDIR /build
RUN git clone https://github.com/stratis-storage/loopdev-3

WORKDIR /build/loopdev-3
# ENV RUSTFLAGS="-Ctarget-feature=-crt-static"
RUN cargo build

As written, this fails to build. Un-comment the ENV line and it builds, but the resulting binary will be linked dynamically with musl so will not run on a non-musl system.

It looks like you are saying that in your build it is never possible to run bindgen because you do not support dynamically loading libclang

I did not intend to say that it is impossible - there are alternatives but in my opinion they are worse overall. Bindgen has a static feature that I have seen some other crates implement. I haven't tested it but that should solve the problem here too. Most users would probably not want it, so it should be configured as an off-by-default feature. If you would prefer this approach I am happy to open a PR.

But that would require that all crates that you rely on that use bindgen-generated code follow the same approach as you are proposing for loopdev.

Yes and no - some use the static feature flag approach. Some (i.e. sqlite) provide a feature flag that builds and links the C .so file as part of the crate build. And in some cases, the crate already checks in its bindgen code but that is not sufficient to static-ly link because Alpine doesn't include a .so in their package for that library.

I do not think that we would be able to accept your changes as is.

I am definitely not asking you to accept the work as-is - it's incomplete. I still need to check in the code that generates the bindings.rs, and add a CI check. I filed the issue to ask if you thought the approach made sense or if you would prefer the static feature flag approach, or something else. (Or if you would prefer not to fix it at all, that's fine too, I can maintain a downstream fork)

we have done some musl support in devicemapper-rs and this notion of simply packaging a previously generated bindings.rs file was not bruited in the discussions then

I took a look and it appears to suffer from the same issue.

[mulkieran]

I am bringing this issue up with a few colleagues, looking for a best general solution, because we generally like to maintain consistent behavior and feature support across our various bindings Rust packages.

We are unlikely to want to go with the solution you described thus, " Some (i.e. sqlite) provide a feature flag that builds and links the C .so file as part of the crate build." I think dbus-rs also does that, and it is not something that it would be attractive for us to maintain.

[mulkieran]

@richardstephens Do you see any future to the idea of invoking the bindgen-cli in build.rs? That is awkward, because we would want to maintain support for the library calls, for our own purposes, but that should avoid the dlopen problem.