runtime: give ten cross-language globals C linkage in main.cpp (MSVC)

[TechnicallyComputers]

Follow-up to #245 (merged), covering the second problem @TheRealBiggs reported in #244:

There are also issues in main.cpp for game projects due to linkage differences with external variables. There are a few variables declared inside functions in main.cpp that needs to have C linkage. Moving them out of said functions and into an extern "C" block is enough.

Confirmed, and #245 did not address it — that PR was merged from a snapshot taken before this commit was pushed to the branch.

The problem

MSVC mangles namespace-scope variables; the Itanium ABI does not. So a C++ reference to a C-defined global links fine on GCC/Clang and fails on MSVC with an unresolved external.

main.cpp:180 already carries the file-scope extern "C" block from the earlier MSVC pass (PR #16 / df4cc5c), and its comment describes exactly this failure mode. Ten globals added since then never made it into the block:

defined in	symbols
memory.c	i_stat, i_mask, g_guest_store_count, g_vblank_ack_count
interrupts.c	g_vblank_raise_count, g_vblank_deliver_count
dirty_ram_interp.c	g_dirty_ram_blocks_run, g_dirty_pump_count
overlay_loader.c	g_call_unit_depth
psx_bios_backend.c	g_psx_dispatch_depth

Each is reached only through a block-scope extern inside a function. With no namespace-scope declaration in view, that block-scope declaration gives the entity C++ linkage — the failure. Adding them to the existing block fixes it without touching a single use site: the block-scope redeclarations inherit C linkage, exactly as the block's own comment already describes for the symbols that were there.

+13 lines, one file.

Which ten was measured, not eyeballed

Whether a given block-scope extern is a problem depends on whether some included header already declares it inside extern "C" — reading the file doesn't tell you. So every distinct block-scope extern variable in main.cpp (32 on current master) was probed by appending extern "C++" { extern T sym; } to a copy compiled with the target's real command line: a conflicting-linkage diagnostic means the symbol already has C linkage, silence means it doesn't.

• Before: 11 report C++ linkage
• After: 1

The remaining one is g_audio_unmute_resync, and it is not a bug — it's defined in main.cpp itself (main.cpp:1937, file scope) and referenced nowhere outside it, so C++ linkage is correct and consistent for it. Flagging it here so a reviewer re-running the probe doesn't think it was missed.

The audit was re-run against current master (which moved twice since #245 merged, 88f07bc9 touching main.cpp) — same ten, no new ones.

main.cpp is the only C++ TU in the runtime with this pattern. beetle_libretro.cpp's extern PS_GPU GPU / extern PS_CDC *PSX_CDC are genuine Beetle C++ symbols, correctly left alone, and psx-beetle isn't built under MSVC anyway.

Verification

• main.cpp.o is byte-identical to its unpatched-master build (540,360 bytes both sides) — a strict no-op on GCC/Clang, as expected for declarations
• Clean-build runtime suite: 49/50. The single failure is gte_register_access_test, pre-existing and unrelated — it links gte.cpp + pgxp.cpp but references gpu_ws_precise_nclip_enabled, defined in gpu.c, which isn't in that target's source list (runtime/CMakeLists.txt:101-105). It fails identically without this patch.

As with #245, I can't run cl.exe here — this is the standard extern "C" remedy and a no-op on the toolchains I can test, but a Windows build is the real confirmation.

Still outstanding from #244: nothing in CI compiles runtime/src with cl.exe. cli-release.yml has a windows-latest job, but it builds the CLI with the portable toolchain. That's why both the GNU-only constructs and these ten globals landed unnoticed, and why the next batch will too. A windows-latest MSVC configure+build job is the durable fix.

🤖 Generated with Claude Code

https://claude.ai/code/session_014YD7rrVK63Kncki6prB65S

[TheRealBiggs]

One more thing I forgot to mention. In main.cpp, the first 2 lines of main() will cause the game to fail to run after compiling with MSVC. This is because 0 is passed as the last argument, which is valid under GCC but not MSVC. MSVC requires a size to be passed when using _IOLBF. Changing the 0 to BUFSIZ fixes this and allows the game to run correctly.

[TechnicallyComputers]

do you have a PR you could submit for that?