step E.minus-1: cpp_smoke renamed to .c and compiled as plain C

c++_shared crashed, c++_static crashed, no stdlib crashed. The remaining
variable isolated to cc::Build::new().cpp(true) itself is the C++
compile-mode invocation of clang++. Rename cpp_smoke.cpp → cpp_smoke.c
and drop .cpp(true), leaving a plain-C cc::Build that compiles the
exact same bytes (minus the 'extern "C"' linkage spec which is C++-
only syntax).

This is structurally identical to Step A (hello.c), which worked. If
THIS build launches, the diff between 'works' and 'crashes' is purely
the .cpp(true) mode — something clang++ does differently at compile
or link time when producing object files for a Tauri Android cdylib.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

desktop/src-tauri/build.rs

@@ -37,26 +37,24 @@ fn build_android_native() {
         .file("cpp/getauxval_fix.c")
         .compile("getauxval_fix");
 
-    // ─── Step E.0: no C++ stdlib linkage at all ────────────────────────────
+    // ─── Step E.minus-1: cpp_smoke.cpp → cpp_smoke.c, compile as plain C ──
-    // c++_shared crashed. c++_static also crashed (same byte stack, new
+    // E.0 (cpp(true), no stdlib, empty extern-C function) still crashed.
-    // offsets because the .so layout shifted). So it's NOT the NEEDED
+    // libc++ linkage ruled out in all forms. Remaining variable: is it the
-    // entry — it's something that happens whenever libc++ code lands in
+    // .cpp(true) compile mode itself — cc-rs invoking clang++ instead of
-    // our .so, regardless of linkage.
+    // clang, or emitting language-specific flags?
     //
-    // cpp_smoke.cpp is just `extern "C" int wzp_cpp_hello(){return 42;}`
+    // The content of cpp_smoke is already zero-C++ (just an extern "C"
-    // — it uses zero C++ features, so we can drop cpp_link_stdlib
+    // function returning 42). Rename the file to .c and drop .cpp(true)
-    // entirely and the compile still succeeds. No libc++ code gets
+    // so cc-rs uses the plain C compile path — exactly like hello.c in
-    // dragged in at all. If the app launches, the trigger is the libc++
+    // Step A, which worked. If THIS crashes, cc::Build is being accused
-    // code itself (probably its .init_array static constructors). If it
+    // wrongly and the crash is triggered by literally _adding any
-    // still crashes, the trigger is just `cc::Build::new().cpp(true)`
+    // additional static archive_ to the link (in which case Step A
-    // switching rustc's linker driver from clang to clang++ and the
+    // should also have crashed and clearly didn't). If this launches,
-    // different default library pull-ins that causes.
+    // the trigger is the cpp(true) → clang++ pipeline, and we need to
-    println!("cargo:rerun-if-changed=cpp/cpp_smoke.cpp");
+    // find out exactly what clang++ differs on for Android cdylibs.
+    println!("cargo:rerun-if-changed=cpp/cpp_smoke.c");
     cc::Build::new()
-        .cpp(true)
+        .file("cpp/cpp_smoke.c")
-        .std("c++17")
-        .cpp_link_stdlib(None::<&str>)
-        .file("cpp/cpp_smoke.cpp")
         .compile("wzp_cpp_smoke");
 
     // Copy libc++_shared.so next to libwzp_desktop_lib.so in the Tauri

desktop/src-tauri/cpp/cpp_smoke.c

@@ -0,0 +1,9 @@
+// cpp_smoke.c — Step E.minus-1: same content as the crashing .cpp file
+// but as plain C. No extern "C" linkage spec (that's C++-only syntax;
+// in C every function has C linkage by default). If this crashes we
+// know cc::Build is being wrongly accused — the trigger must be more
+// general than C++ mode.
+
+int wzp_cpp_hello(void) {
+    return 42;
+}

desktop/src-tauri/cpp/cpp_smoke.cpp

@@ -1,14 +0,0 @@
-// cpp_smoke.cpp — Step E.1: the absolute minimum C++ file.
-// No #include, no STL, no atomics, no thread, no mutex. Just one function.
-// Still compiled as .cpp(true) with cpp_link_stdlib("c++_shared"), so the
-// only delta vs the non-crashing baseline is:
-//   1. cc::Build using cpp(true) (vs plain C in hello.c)
-//   2. cargo:rustc-link-lib=c++_shared emitted by cc-rs (adds NEEDED
-//      entry for libc++_shared.so in the final .so)
-//
-// If this crashes, we've conclusively proven the trigger is one of those
-// two things — not any C++ code behavior.
-
-extern "C" int wzp_cpp_hello(void) {
-    return 42;
-}