| 4 Aug 2025 |
 kjeremy | I'm ending up with something like this:
ros-humble-zenoh-cpp-vendor-aarch64-unknown-linux-gnu> cargo:warning=aarch64-unknown-linux-gnu-gcc: error: unrecognized command line option '-m64'
ros-humble-zenoh-cpp-vendor-aarch64-unknown-linux-gnu>
ros-humble-zenoh-cpp-vendor-aarch64-unknown-linux-gnu> --- stderr
ros-humble-zenoh-cpp-vendor-aarch64-unknown-linux-gnu>
ros-humble-zenoh-cpp-vendor-aarch64-unknown-linux-gnu>
ros-humble-zenoh-cpp-vendor-aarch64-unknown-linux-gnu> error occurred: Command "aarch64-unknown-linux-gnu-gcc" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "-m64" "-I" "include" "-I" "/build/rmw_zenoh-release-release-humble-zenoh_cpp_vendor-0.1.1-1/build/zenoh_c_vendor-prefix/src/zenoh_c_vendor-build/release/target/release/build/ring-224694a13d0c6d7a/out" "-Wall" "-Wextra" "-fvisibility=hidden" "-std=c1x" "-Wall" "-Wbad-function-cast" "-Wcast-align" "-Wcast-qual" "-Wconversion" "-Wmissing-field-initializers" "-Wmissing-include-dirs" "-Wnested-externs" "-Wredundant-decls" "-Wshadow" "-Wsign-compare" "-Wsign-conversion" "-Wstrict-prototypes" "-Wundef" "-Wuninitialized" "-g3" "-DNDEBUG" "-o" "/build/rmw_zenoh-release-release-humble-zenoh_cpp_vendor-0.1.1-1/build/zenoh_c_vendor-prefix/src/zenoh_c_vendor-build/release/target/release/build/ring-224694a13d0c6d7a/out/fad98b632b8ce3cc-curve25519.o" "-c" "crypto/curve25519/curve25519.c" with args aarch64-unknown-linux-gnu-gcc did not execute successfully (status code exit status: 1).
| 16:00:20 |
 dramforever | so no -m64 will not possibly work for arm | 16:31:13 |
| dramforever | it sounds like ring is doing something wrong | 16:32:14 |
| kjeremy | I know that -m64 is definitely wrong. All the environment variables LOOK correct | 16:33:43 |
| dramforever | i ... i think this is cc-rs? | 16:36:57 |
| dramforever | what's the version of ring used here? it should say it earlier in the log | 16:40:26 |
| dramforever | actually maybe it will be more helpful if you just tell me the "cc" version in Cargo.lock that it uses | 16:49:14 |
| kjeremy | ring 0.17.8, cc 1.1.20 | 16:53:41 |
| dramforever | i just noticed this | 17:16:51 |
| dramforever | i don't think this is right | 17:17:05 |
| dramforever | rustPlatform.cargoSetupHook should be correct | 17:17:24 |
 Alyssa Ross | No? Usually the hook goes in nativeBuildInputs, and when they weren't doing that it used rustc built for aarch64 | 17:17:54 |
| dramforever | rustPlatform is like stdenv, i think | 17:18:39 |
| dramforever | rustPlatform.rust.rustc == buildPackages.rustc | 17:18:42 |
 emily | it's correct in nativeBuildInputs | 17:19:16 |
| emily | perhaps it is not going in nativeBuildInputs | 17:19:20 |
| emily | the hooks go in nativeBuildInputs though right? | 17:19:42 |
| dramforever | it should definitely be in nativeBuildInputs | 17:19:43 |
| emily | so rustPlatform.cargoSetupHook cannot be buildPackages.* w/o splicing | 17:19:50 |
| emily | otherwise nativeBuildInputs would splice it up "one too high" | 17:19:56 |
| emily | maybe? | 17:20:03 |
| emily | wait does that stuff even splice | 17:20:05 |
| emily | I hate splicing I hate splicing I hate splicing I hate splicing I hate splicing I hate splicing I hate splicing | 17:20:08 |
| dramforever | rustPlatform.cargoSetupHook is not spliced | 17:20:17 |
| dramforever | it's like stdenv.cc, right? | 17:20:49 |
| dramforever | * it's like stdenv.cc, right? | 17:20:53 |
| dramforever | that one goes in nativeBuildInputs, and is not spliced | 17:21:04 |
| dramforever | that's... that's not what i'm confused about though, what i'm confused about is why on earth is it building ring for vendor? | 17:21:56 |
| dramforever | oh nevermind i think the package literally is just called zenoh-cpp-vendor | 17:22:38 |
| Alyssa Ross | In reply to @dramforever:matrix.org
rustPlatform.cargoSetupHook is not spliced I thought we fixed the splicing | 17:23:45 |
