tursodatabase / tursodatabase/libsql
libsql-ffi: broken builds under Nix on macOS
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 17.2k
- Forks
- 531
- Avg merge
- 1h 12m
- Merged PRs (30d)
- 1
Description
Hi everyone,
I think I have just run into a regression introduced in #2103. copy_with_cp was specifically modified in #1911 to support sandboxes with read only sources like Nix. As mentioned in #1911 the fix was needed even in macOS, because inside a Nix build the GNU cp is used not the BSD cp. Since #2103 stopped passing --no-preserve=mode,ownership on macOS, GNU cp running in Nix sandbox on macOS now preserves the read only mode of the vendored sources, and the build script's second copy of bindgen.rs into OUT_DIR fails:
> error: failed to run custom build command for `libsql-ffi v0.9.19`
>
> Caused by:
> process didn't exit successfully: `/nix/var/nix/builds/nix-73971-3647907535/source/target/release/build/libsql-ffi-f32cd2e5cc844f3c/build-script-build` (exit status: 101)
> --- stdout
> cargo:rustc-link-lib=framework=Security
> cargo:rerun-if-changed=bundled/src/sqlite3.c
> cargo:lib_dir=/nix/var/nix/builds/nix-73971-3647907535/source/target/release/build/libsql-ffi-cab26cdcde7adda8/out
>
> --- stderr
> cp: cannot create regular file '/nix/var/nix/builds/nix-73971-3647907535/source/target/release/build/libsql-ffi-cab26cdcde7adda8/out/bindgen.rs': Permission denied
>
> thread 'main' (3643659) panicked at /nix/store/zy31wgm2qx0sdf22rywv7fcn46aajm3b-vendor-cargo-deps/c19b7c6f923b580ac259164a89f2577984ad5ab09ee9d583b888f934adbbe8d0/libsql-ffi-0.9.19/build.rs:196:64:
> called `Result::unwrap()` on an `Err` value: Os { code: 13, kind: PermissionDenied, message: "Permission denied" }
> note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Since we shouldn't just remove the macOS cfg block, because if we do unsandoxed macOS users will start getting the illegal option warning again. I propose that we add a -f flag to the cp invocation which is supported by the GNU and the BSD cp command. When the destination can't be overwritten, cp will remove the old file and write a new one.
I have tested this by patching the crate in my project and the Nix build on macOS succeeds, other platforms are unaffected.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in libsql-ffi's build.rs, especially the copy_with_cp implementation and the second copy of bindgen.rs into OUT_DIR described in the report. Reproduce or inspect the Nix-on-macOS build, then verify that the copy succeeds there without reintroducing the macOS warning or affecting other platforms.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- build-system
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 86/100