symphorien / nix-du

Visualise which gc-roots to delete to free some space in your nix store
GNU Lesser General Public License v3.0
371 stars 5 forks source link

fails to build on armhf, i386 and ppc64el #9

Closed thkoch2001 closed 12 months ago

thkoch2001 commented 2 years ago

The debian package of nix uses nix-du as a test object. However nix-du fails to build on some architectures. See for example the build log of the nix package for the i386 architecture: log.gz.

The relevant part of the build log is:

thread 'bindings::bindgen_test_layout_path_t' panicked at 'assertion failed: `(left == right)`
  left: `16`,
 right: `24`: Size of: path_t', src/bindings.rs:17:5

There are also warnings that might be worth looking at:

warning: dereferencing a null pointer
  --> src/bindings.rs:28:19
   |
28 |         unsafe { &(*(::std::ptr::null::<path_t>())).path as *const _ as usize },
   |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this code causes undefined behavior when executed
   |
   = note: `#[warn(deref_nullptr)]` on by default

warning: dereferencing a null pointer
  --> src/bindings.rs:38:19
   |
38 |         unsafe { &(*(::std::ptr::null::<path_t>())).size as *const _ as usize },
   |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this code causes undefined behavior when executed

warning: dereferencing a null pointer
  --> src/bindings.rs:48:19
   |
48 |         unsafe { &(*(::std::ptr::null::<path_t>())).is_root as *const _ as usize },
   |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this code causes undefined behavior when executed

I've no idea about rust, but since the src/bindings.rs file is autogenerated, maybe the build of your package should regenerate this file for each build instead of having it committed to Git?

Feel free to ignore this issue if you're not interested in the above architectures. I'll just disable this test in the nix package for the above architectures for the moment.

symphorien commented 2 years ago

Thanks for the report. I can reproduce on i386, which is good.

The warnings are harmless and due to bindgen (https://github.com/rust-lang/rust-bindgen/issues/1651 iirc).

Originally I used bindgen as a crate, but pointing it to the location of libclang, the libc and the c++ stdlib was quite complex. That's why I committed the bindings. I was not aware it would fail on 32bits.

You should be able to eschew the build error by regenerating the bindings with ./generate-bindings.sh but the script is broken currently (I don't rerun it so often) and bindgen from nixpkgs is broken as well. I will attempt to fix bindgen in nixpkgs first to fix the script. Then if that really solves the issue, maybe I can call this script systematically in build.rs.

symphorien commented 2 years ago

@thkoch2001 I fixed ./generate-bindings.sh on master. Can you check that running this script fixes compilation? (it works on i386 but I didn't test on arm). If you take rust-bindgen from nixpkgs (via shell.nix) you need to take it from nixpkgs-unstable.

symphorien commented 2 years ago

fixed in #11, can you test ?

thkoch2001 commented 2 years ago

Unfortunately I now see another problem already on 64 bit platforms:

  running: "/nix/store/pja9g36cy32z3d51942jqk91a6l2d5nv-gcc-wrapper-10.3.0/bin/c++" "-O2" "-ffunction-sections" "-fdata-sections" "-fPIC" "-m64" "-Wall" "-Wextra" "-std=c++17" "-DNIXVER=204" "-o" "/tmp/nix-build-nix-du-0.4.1.drv-0/source/target/x86_64-unknown-linux-gnu/release/build/nix-du-c9e691f13c378539/out/wrapper.o" "-c" "wrapper.cpp"
  cargo:warning=wrapper.cpp: In lambda function:
  cargo:warning=wrapper.cpp:22:33: error: 'class nix::Store' has no member named 'findRoots'
  cargo:warning=   22 | #define findroots(store) store->findRoots(false)
  cargo:warning=      |                                 ^~~~~~~~~
  cargo:warning=wrapper.cpp:22:33: note: in definition of macro 'findroots'
  cargo:warning=   22 | #define findroots(store) store->findRoots(false)
  cargo:warning=      |                                 ^~~~~~~~~
  exit status: 1

https://ci.debian.net/data/autopkgtest/testing/amd64/n/nix/19962336/log.gz

Thank you for your quick help here. But I'll just use the "hello" package of nix for this basic test. I don't think it was a good idea to test basic functioning of the nix package in CI with any non-trivial package.

symphorien commented 2 years ago

that looks really like #10, which is fixed on master. Which nix version is it, and which commit are you testing?