fix: tinyobjloader ODR violation unmasked by tonight's CI-red fixes

Real windows-2022 + Clang ASan+UBSan CI evidence landed after tonight's
6 CI-red fixes: mc3togltf.exe now starts on Windows and the 3
load_policy tests pass, confirming those fixes work. But clearing the
mc3_json_document_budget timeout let the Linux sanitizer job's
standalone-component loop reach mc3togltf's own tests for the first
time ever, and ~67 of 75 crashed instantly with an AddressSanitizer
odr-violation on tinyobj::MaterialFileReader's typeinfo.

Root cause: mc3togltf/src/MeshBuilder.cpp defines
TINYOBJLOADER_IMPLEMENTATION and #includes tiny_obj_loader.h directly,
compiling its own copy of tinyobjloader into mc3togltf_lib -- while
mc3togltf_lib (and the root editor target) ALSO linked the
separately-compiled `tinyobjloader` CMake target, which builds as a
shared library for the same Manifold BUILD_SHARED_LIBS=ON default
already identified as the Windows DLL-staging bug. Two live
definitions of the same class/vtable in one process is genuine
undefined behavior, not an ASan nitpick -- it was always latent, just
never reached in CI before (the loop always died earlier at mc3's own
timeout).

Fixed by dropping the tinyobjloader *link* dependency everywhere
(mc3togltf_lib, both branches of the root editor target's
target_link_libraries, and the release-artifact DLL/shared-library
install loop) -- only the include directory is needed since
MeshBuilder.cpp already provides the sole implementation.

Verified: standalone mc3togltf rebuilt under Clang ASan+UBSan matching
CI's exact flags -- 75/78 pass (up from 8/78), remaining 3 are the
already-known Blender/numpy gap. Full root MeshCraft editor still
links/runs (--version works), and OBJ import specifically
(mc3togltf_obj_material_import/_obj_robustness/_large_obj_stress) still
passes end to end.

Author: robertvokac

CMakeLists.txt

@@ -467,10 +467,14 @@ if(NOT EMSCRIPTEN AND NOT ANDROID)
     endif()
 endif()
 
-# mc3togltf is linked against these shared third-party libraries in the
-# default desktop build.  Ship their runtime files in the same release
+# mc3togltf is linked against this shared third-party library in the
+# default desktop build.  Ship its runtime files in the same release
 # component so the CLI archive is usable outside the build tree.
-foreach(MESHCRAFT_CLI_RUNTIME_TARGET IN ITEMS manifold tinyobjloader)
+# tinyobjloader is deliberately NOT listed here: mc3togltf_lib only ever uses
+# it as a single-header library (see mc3togltf/CMakeLists.txt's
+# TINYOBJLOADER_IMPLEMENTATION note) and no longer links its separately
+# compiled target, so there is no runtime tinyobjloader artifact to ship.
+foreach(MESHCRAFT_CLI_RUNTIME_TARGET IN ITEMS manifold)
     if(TARGET ${MESHCRAFT_CLI_RUNTIME_TARGET})
         install(TARGETS ${MESHCRAFT_CLI_RUNTIME_TARGET}
                 ARCHIVE DESTINATION "${CMAKE_INSTALL_LIBDIR}" COMPONENT release
@@ -655,14 +659,13 @@ elseif(CMAKE_CXX_COMPILER_ID MATCHES "GNU|Clang" AND NOT WIN32 AND NOT ANDROID)
         mc3togltf_lib
         imgui
         manifold
-        tinyobjloader
         lua54
         sol2::sol2)
     if(SQLite3_FOUND)
         target_link_libraries(${_target} PRIVATE ${SQLite3_LIBRARIES})
     endif()
 else()
-    target_link_libraries(${_target} PRIVATE CNA ${_cna_backend_target} SHARP_RUNTIME Mc3 Mcb mc3togltf_lib imgui manifold tinyobjloader lua54 sol2::sol2)
+    target_link_libraries(${_target} PRIVATE CNA ${_cna_backend_target} SHARP_RUNTIME Mc3 Mcb mc3togltf_lib imgui manifold lua54 sol2::sol2)
     if(SQLite3_FOUND)
         target_link_libraries(${_target} PRIVATE ${SQLite3_LIBRARIES})
     endif()

NEXT.md

@@ -227,6 +227,51 @@ place. Progress, each its own commit:
   mechanism itself is standard CMake, not something this project invented.
   **All 6 of tonight's deferred CI-red regressions are now addressed.**
 
+**Real CI evidence landed after pushing the above.** Confirmed working on an
+actual `windows-2022` runner: `mc3togltf.exe` now starts (no more
+`STATUS_DLL_NOT_FOUND`) and `mc3_load_policy`/`mc3_json_load_policy`/
+`mcb_load_policy` all pass. But clearing those earlier blockers let both the
+Windows and Linux sanitizer jobs run further than ever before, surfacing 2
+new, previously-unreachable bugs (same "fixing one bug unmasks the next"
+pattern as this whole session):
+
+- **Linux Clang ASan+UBSan: ~67 of 75 `mc3togltf_*` tests crashed at process
+  startup** with an AddressSanitizer odr-violation on
+  `typeinfo name for tinyobj::MaterialFileReader` between
+  `mc3togltf/src/MeshBuilder.cpp` and `libtinyobjloader.so.2`. Root cause:
+  `MeshBuilder.cpp` defines `TINYOBJLOADER_IMPLEMENTATION` and `#include`s
+  the header directly (compiling its own copy into `mc3togltf_lib`), while
+  `mc3togltf_lib` ALSO linked the separately-compiled `tinyobjloader` CMake
+  target — which builds as a shared library for the same
+  Manifold-`BUILD_SHARED_LIBS`-default reason as the Windows DLL bug above.
+  Two live definitions of the same class/vtable in one process is genuine
+  undefined behavior, not just an ASan nitpick. This was always latent but
+  never reached in CI before tonight: the standalone-component loop always
+  died earlier at `mc3`'s `mc3_json_document_budget` timeout (CI-red #6,
+  now fixed), before ever building/running `mc3togltf`'s own tests.
+  Fixed by dropping the `tinyobjloader` *link* dependency everywhere
+  (`mc3togltf/CMakeLists.txt`'s `mc3togltf_lib`, and both branches of the
+  root `CMakeLists.txt`'s main editor target) — only the include directory
+  is needed since `MeshBuilder.cpp` already provides the one-and-only
+  implementation. Also dropped `tinyobjloader` from the root project's
+  release-artifact DLL/shared-library install loop, since nothing links it
+  at runtime anymore. Verified: rebuilt the standalone `mc3togltf` component
+  under Clang ASan+UBSan matching CI's exact flags (`build-sanitize/mc3togltf`)
+  — 75/78 pass (up from 8/78), the 3 failures are the already-known
+  Blender/`numpy` gap; the full root `MeshCraft` editor (`cmake-build-debug`)
+  still links and runs (`--version` works), and OBJ import specifically
+  (`mc3togltf_obj_material_import`/`_obj_robustness`/`_large_obj_stress`)
+  still passes, confirming tinyobjloader itself still works correctly
+  through its single remaining (header-only) code path.
+- **Windows: `mc3_roundtrip` still crashes, but for a different, new reason**
+  than tonight's earlier fix. `terminate() after throwing
+  MeshCraft::Mc3::AtomicFinalizeError`: `Mc3::writeFileAtomically()`'s
+  finalize `rename()` step fails with "Input/output error" for a path
+  containing non-ASCII characters (`mc3_rt_čeština_日本.mc3.xml`, the
+  STAB-0555/0556 UTF-8-filename case, reached via `roundtripAt()`). This is
+  a bug in the `SYS-W9-06` atomic-write primitive itself, unrelated to the
+  ifstream/`remove()` bug fixed above — investigating next.
+
 ## Known release blockers and decisions
 
 | Area | Live state |

mc3togltf/CMakeLists.txt

@@ -100,16 +100,15 @@ if(NOT tinyobjloader_POPULATED)
 endif()
 
 # Windows STATUS_DLL_NOT_FOUND (part of tonight's CI-red survey): Manifold's
-# own CMakeLists.txt defaults BUILD_SHARED_LIBS to ON, and tinyobjloader's
-# add_library() call has no explicit STATIC/SHARED, so it inherits that same
-# global cache value -- both build as DLLs on Windows. Linux/macOS need no
-# fix: CMake adds build-tree RPATH entries to every executable pointing at
-# its shared-library dependencies automatically, and Windows PE executables
-# have no equivalent mechanism (the loader only searches the exe's own
-# directory, CWD, System32, and PATH -- nothing under _deps/). Copy each
-# affected executable's transitive DLL dependencies next to it after linking;
-# $<TARGET_RUNTIME_DLLS:...> (CMake 3.21+, the minimum this project already
-# requires) resolves to nothing on non-Windows, so this is a no-op there.
+# own CMakeLists.txt defaults BUILD_SHARED_LIBS to ON, so it builds as a DLL
+# on Windows. Linux/macOS need no fix: CMake adds build-tree RPATH entries to
+# every executable pointing at its shared-library dependencies automatically,
+# and Windows PE executables have no equivalent mechanism (the loader only
+# searches the exe's own directory, CWD, System32, and PATH -- nothing under
+# _deps/). Copy each affected executable's transitive DLL dependencies next
+# to it after linking; $<TARGET_RUNTIME_DLLS:...> (CMake 3.21+, the minimum
+# this project already requires) resolves to nothing on non-Windows, so this
+# is a no-op there.
 function(mc3togltf_stage_runtime_dlls target)
     if(WIN32)
         add_custom_command(TARGET ${target} POST_BUILD
@@ -146,7 +145,17 @@ target_include_directories(mc3togltf_lib SYSTEM PUBLIC
     ${nanosvg_SOURCE_DIR}/src
 )
 
-target_link_libraries(mc3togltf_lib PUBLIC Mc3 tinyobjloader manifold)
+# tinyobjloader is used as a single-header library here (MeshBuilder.cpp
+# defines TINYOBJLOADER_IMPLEMENTATION and #includes it directly), so only
+# its include dir (added above) is needed -- deliberately NOT linking the
+# separately-compiled `tinyobjloader` CMake target too. That target also
+# compiles tiny_obj_loader.cc into its own library (shared, by inheriting
+# Manifold's BUILD_SHARED_LIBS=ON default), so linking both would give the
+# final binary two live definitions of the same class/vtable: a genuine ODR
+# violation, caught by AddressSanitizer's odr-violation detector (crashes
+# every mc3togltf sanitizer test at process startup, before any test code
+# even runs) and undefined behavior on any build, sanitized or not.
+target_link_libraries(mc3togltf_lib PUBLIC Mc3 manifold)
 
 if(MSVC)
     set(MESHCRAFT_STANDALONE_WARNING_FLAGS /W4)