MSVC shared-library build fails to link: pio.c calls popen/pclose but the CRT exports _popen/_pclose

[lenzo-ka]

Summary

src/util/pio.c calls the POSIX-spelled popen() in fopen_comp(), but the Microsoft C runtime exports these functions as _popen/_pclose. An MSVC shared-library (DLL) build of the library therefore fails to link.

Detail

The close side already accounts for this: fclose_comp() calls _pclose under #if defined(_WIN32) (src/util/pio.c:190). The open side does not — fopen_comp() calls bare popen(command, mode) at src/util/pio.c:140 and :163.

CHECK_SYMBOL_EXISTS(popen stdio.h HAVE_POPEN) (CMakeLists.txt:33) makes HAVE_POPEN defined on MSVC, so the pipe code is compiled. But the CRT import library exports only _popen/_pclose, so linking a DLL fails on the POSIX spelling:

pio.obj : error LNK2019: unresolved external symbol popen referenced in function fopen_comp
pocketsphinx.dll : fatal error LNK1120: 1 unresolved externals

Version

v5.1.1 (511126b492dcb267cf30d49d631946d7b61a9530); still present on main.

Isolated reproduction

Linking a minimal DLL whose only external references are popen/pclose reproduces it under MSVC (cl 14.51):

cl /nologo /LD pio_min.c
pio_min.obj : error LNK2019: unresolved external symbol popen referenced in function open_pipe
pio_min.obj : error LNK2019: unresolved external symbol pclose referenced in function close_pipe
pio_min.dll : fatal error LNK1120: 2 unresolved externals

Mapping popen/pclose to _popen/_pclose on Win32 links cleanly.

Suggested fix

Guard the pipe spellings for Win32 in pio.c — _popen/_pclose on Win32, popen/pclose elsewhere — matching the existing _pclose guard, so both pipe calls use the spelling the CRT exports.