[ci] static-link libstdc++/libgcc into MATLAB MEX, leave Octave dynamic

MATLAB R2024a ships a bundled libstdc++.so.6 that's older than the
ubuntu-22.04 / windows-latest runner toolchains. A dynamically-linked
MEX from those runners fails to load with:

    Invalid MEX-file ... siamex.mexa64: libstdc++.so.6: version
    `GLIBCXX_3.4.29' not found

Fix: pass -static-libstdc++ -static-libgcc (Linux GCC) and /MT (MSVC)
to the siamize_mex link line so the MEX brings its own C++ runtime.
This is gated on SIAMIZE_STATIC_LINK (default ON, same flag the CLI
binary already uses) so users can opt out if they need to.

Important: this is MATLAB-only. The Octave MEX must stay dynamically
linked against libstdc++. Statically embedding a second libstdc++
inside a MEX loaded by an Octave process that already has one
dynamically loaded causes ABI conflicts (std::cout, type_info,
exception state) and SIGABRT on first siamex() call. Verified locally:
adding -static-libstdc++ to mkoctfile LDFLAGS made octave-cli core
dump on siamex() entry; reverting restored normal operation and the
30/30 siamize.m unit tests still pass.

MATLAB doesn't hit the same problem in practice because its bundled
libstdc++ is genuinely too old -- the static MEX has no "real" stdc++
to fight with, only a stub that lacks the needed GLIBCXX symbols.

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

Author: fangq

CMakeLists.txt

@@ -307,6 +307,24 @@ if(SIAMIZE_BUILD_MATLAB_MEX)
         if(OpenMP_CXX_FOUND)
             target_link_libraries(siamize_mex OpenMP::OpenMP_CXX)
         endif()
+        # Statically link the C++ runtime into the MEX. MATLAB ships its
+        # own libstdc++.so.6 that's typically older than the host
+        # toolchain's, so a dynamic MEX raises "GLIBCXX_x.y.z not found"
+        # at MEX-load time. Statically linking libstdc++ + libgcc into
+        # siamex.mexa64 (and using /MT on MSVC) sidesteps the version
+        # negotiation entirely.
+        if(SIAMIZE_STATIC_LINK)
+            if(CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
+                target_link_options(siamize_mex PRIVATE -static-libstdc++ -static-libgcc)
+            elseif(MSVC)
+                target_compile_options(siamize_mex PRIVATE
+                    $<$<CONFIG:Release>:/MT>
+                    $<$<CONFIG:Debug>:/MTd>
+                    $<$<CONFIG:RelWithDebInfo>:/MT>
+                    $<$<CONFIG:MinSizeRel>:/MT>
+                )
+            endif()
+        endif()
         if(MSVC)
             target_compile_definitions(siamize_mex PRIVATE _CRT_SECURE_NO_WARNINGS NOMINMAX)
             target_compile_options(siamize_mex PRIVATE /wd4068 /wd4244 /wd4267)
@@ -365,6 +383,15 @@ if(SIAMIZE_BUILD_OCTAVE_MEX)
         # mkoctfile honors LDFLAGS env for link-stage flags; -L/-l args
         # on the command line get dropped silently.
         set(_oct_ld "-L${ORT_LIB_DIR} -lonnxruntime -Wl,-rpath,${ORT_LIB_DIR}")
+        # Octave loads its MEX into a process that already has a
+        # dynamically-loaded libstdc++. Statically embedding a second
+        # copy of libstdc++ inside the MEX causes ABI conflicts at
+        # load time (std::cout, type_info, exception handling) and
+        # SIGABRT during siamex() entry. So we always link libstdc++
+        # dynamically for the Octave MEX even with SIAMIZE_STATIC_LINK=ON.
+        # (The MATLAB MEX is different -- MATLAB ships an older bundled
+        #  libstdc++.so.6 that lacks recent GLIBCXX_x.y.z symbols, so
+        #  there static-linking is the only thing that loads.)
         add_custom_command(
             OUTPUT ${_oct_out}
             COMMAND ${CMAKE_COMMAND} -E env