Android NDK: rebuild with c++_shared to avoid double libc++ when mixing prebuilts

[fanxiaoyi520]

Problem

When integrating a prebuilt libyaml-cpp.so into an Android app/native module that already uses the NDK shared C++ runtime (libc++_shared.so / ANDROID_STL=c++_shared), it is easy to end up with two C++ runtimes in one process ("double libc++").

Symptoms are typically load/link failures or hard-to-debug crashes around STL types crossing .so boundaries—not YAML parsing logic itself.

Cause

STL linkage mismatch between:

• the prebuilt yaml-cpp (often built with a different STL / static vs shared), and
• the app / other native libs that expect a single shared libc++_shared.

Workaround that worked for us

Rebuild yaml-cpp from source with the same shared STL as the host app, then replace the mismatched prebuilt.

Verified with tag yaml-cpp-0.6.3 (also tried newer trees; 0.6.3 matched our ABI needs):

cmake -S . -B build-android \
  -DCMAKE_TOOLCHAIN_FILE=$NDK/build/cmake/android.toolchain.cmake \
  -DANDROID_ABI=arm64-v8a \
  -DANDROID_PLATFORM=android-30 \
  -DANDROID_STL=c++_shared \
  -DYAML_BUILD_SHARED_LIBS=ON \
  -DCMAKE_BUILD_TYPE=Release \
  -DCMAKE_CXX_FLAGS="-fvisibility=hidden -fvisibility-inlines-hidden"

cmake --build build-android --config Release

Notes:

1. Keep one libc++_shared.so in the final APK (prefer the NDK/app copy; do not ship a second conflicting copy).
2. include/yaml-cpp/dll.h already maps YAML_CPP_API to __attribute__((visibility("default"))) on non-MSVC when building the shared library. That matters if you compile with -fvisibility=hidden so exported symbols stay visible across .so boundaries.
3. This report is a generic rebuild recipe only—no proprietary binaries attached.

Question for maintainers

Would you accept a short doc PR (e.g. docs/android-ndk.md) capturing the ANDROID_STL=c++_shared shared-library rebuild notes above? Happy to open one if useful.