Incremental bisection within Step E. E.4 (atomic + mutex + thread) still
crashed at __init_tcb. Drop mutex and thread, keep only std::atomic.
Build.rs still emits cargo:rustc-link-lib=c++_shared via
cpp_link_stdlib('c++_shared'), so the NEEDED entry for libc++_shared.so
in the final .so stays identical. Goal: if this crashes, the issue is
purely the dynamic link against libc++_shared (not thread/mutex code).
If it passes, the issue is actually std::thread or std::mutex use.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
20 lines
667 B
C++
20 lines
667 B
C++
// cpp_smoke.cpp — Step E.2 minimal stub: std::atomic only, no thread/mutex.
|
|
//
|
|
// Linked via cpp_link_stdlib("c++_shared") so the resulting .so still carries
|
|
// a NEEDED entry for libc++_shared.so exactly like the Oboe build would.
|
|
//
|
|
// Same extern "C" export as E.4 so the linker CAN pull the symbol in if it
|
|
// chooses to, but since Rust never calls it, it'll typically be dead-stripped.
|
|
// The diagnostic value is in the build.rs link directives this compile
|
|
// produces, not in the file's actual code being linked.
|
|
|
|
#include <atomic>
|
|
|
|
namespace {
|
|
std::atomic<int> g_counter{0};
|
|
}
|
|
|
|
extern "C" int wzp_cpp_smoke(void) {
|
|
return g_counter.fetch_add(1);
|
|
}
|