max-pure feature is not pure (pulls in libsqlite3-sys)
#1681
Comments
This adds more checks to the `pure-rust-build` CI job to reveal what dependencies of `max-pure` are building C code. The new checks are failing. They relate to GitoxideLabs#1681 and should pass once that bug is fixed. The main goal is to produce information helpful for GitoxideLabs#1681. As currently written, the new steps do not fail the job, because the failing steps have `continue-on-error: true`. This is so that regressions (that would fail the preexisting steps) remain readily detected. This should ideally be temporary; the new steps, if kept, should eventually be strengthened so they can fail the job. Currently this includes both regular and build dependencies. There are two new checks: 1. Search the `max-pure` dependency tree for packages that require a C or C++ compiler, or that are in practice only likely to be used to build C or C++ code. If any are found, display the whole tree, with matching lines highlighted, and fail the step. 2. After all steps that need it to be in working order, break GCC in the container by removing the `cc1` binary, then attempt a clean `max-pure` build, to reveal the first failure, if any, and let it fail the step. The `gcc` command itself is needed, because `rustc` calls the linker through it, even when no non-Rust code is compiled as part of the build. As discussed in GitoxideLabs#1664 comments, installing GCC in a way that is not broken but omits the ability to compile even C code, while it may be possible, is not commonly done and may require long running build steps or a new Docker image. Fortunately, the `gcc` command is just a "compiler driver"; the C compiler in GCC is `cc1`, and this can be removed without breaking most uses of GCC that don't involve actual compilation. This likewise removes `cc1plus` if found, even though it may not be present since we already verified that `g++` is not installed. (The deletion of `cc1` is the important part.) Since the job now cleans and starts a build that fails due to the absence of `cc1`, this removes the `rust-cache` step. (Caching would probably still confer some benefit, since it caches dependencies. Even after running `cargo clean` between the builds, most of these should be reacquired when building with `cc1`. However, to make the whole thing easier to reason about, the step is removed. It can be re-added if the job runs too slowly.) This considers any `-sys` crate to be a dependency that needs to build C. This is in principle not always the case, since they may use existing shared library binaries, though there may still be stub code that has to be built in C. The relevance of the new steps varies depending on precisely how one conceptualizes "pure" in `max-pure`, which is another reason for them to start out as `continue-on-error`. The `-sys` crates this finds in the `max-pure` dependency tree are: - `libsqlite3-sys` via `rusqlite`. This was reported in GitoxideLabs#1681 and strongly seems to be unintended for `max-pure`. - `linux-raw-sys` via `rustix` and `xattr`. It's less clear whether this should be considered impure, since its purpose is to interact with an operating system facility, and it may be comparable to the use of `libc` (on Unix-like systems). However, this does seem like it would not be able to build without a C compiler. The dependency tree also has an occurrence of the `cc` crate without a related `-sys` dependency, as required by `ring`. The `ring` crate contains a C test program that is built when building `ring`. That is currently the first build error shown in the output of the "Do max-pure build without being able to compile C or C++" step.
Byron
added
acknowledged
|
Thanks for bringing this to my attention. It's true that gitoxide/.github/workflows/ci.yml Lines 33 to 41 in 2fc93f7 Note that As of now, it's not possible to make any Rust build without a C compiler as it invokes the linker through it. Thanks to that, C-dependencies can always sneak in and build as long as they don't invoke more than Even though this particular issue can be solved by turning off Maybe the CI run could be tuned to replace |
|
There's nightly flag for using rustup distributed lld, honestly I wish something like zig-cc is provided via rustup. |
|
That should be possible to integrate on CI and would solve the problem. Thanks for suggesting! |
|
I've opened #1682 to make the The approach I've proposed there is intended as a way of getting immediate greater insight into how and why |
|
Thanks a lot for your help! I have set this issue to I could also imagine an intermediate step which involves setting up a |
|
Not that I personally needed it to be absolutely pure Rust - removing |
|
Great to hear. Then I'd say I keep the |
This adds another step to `pure-rust-build` that fails -- and fails the job -- when there are any dependencies named `*-sys` other than `linux-raw-sys`, which is known about. (This is independent of the use of C in `ring` -- discussed in GitoxideLabs#1681, GitoxideLabs#1682, and GitoxideLabs#1684 -- because `ring` is not, and does not use, a `*-sys` dependency.) This should fail prior to 3506afb (GitoxideLabs#1684) and pass afterwards.
This adds another step to `pure-rust-build` that fails -- and fails the job -- when there are any dependencies named `*-sys` other than `linux-raw-sys`, which is known about. (This is independent of the use of C in `ring` -- discussed in GitoxideLabs#1681, GitoxideLabs#1682, and GitoxideLabs#1684 -- because `ring` is not, and does not use, a `*-sys` dependency.) This should fail prior to 3506afb (GitoxideLabs#1684) and pass afterwards.
This adds another step to `pure-rust-build` that fails -- and fails the job -- when there are any dependencies named `*-sys` other than `linux-raw-sys`, which is known about. (This is independent of the use of C in `ring` -- discussed in GitoxideLabs#1681, GitoxideLabs#1682, and GitoxideLabs#1684 -- because `ring` is not, and does not use, a `*-sys` dependency.) This should fail prior to 3506afb (GitoxideLabs#1684) and pass afterwards.
Current behavior 😯
Expected behavior 🤔
max-purefeature should be actually pure (ideally, CI should ensure it works without a C compiler available at all)Git behavior
No response
Steps to reproduce 🕹
No response
The text was updated successfully, but these errors were encountered: