jitter, msp used on all min-api projects yet no jitter,msp code written

[diablodale]

Building Windows min-api project with MSVC2019, no jitter/msp code, and does not link jitlib.lib MaxAudio.lib results in build fail with multiple unresolved external symbols errors. e.g.,

[build] min.hello-world.cpp.obj : error LNK2001: unresolved external symbol buffer_edit_begin

This suggests there is jitter and msp code/structures always being used in the min-api. This likely leads to additional resource usage at runtime when the MXE is loaded.

Setup

• MSVS 2019
• Working cmake build system for an x64 DLL (aka mxe64)
• Disable the linking of jitter and msp libraries in your cmake setup
• min.hello-world https://github.com/Cycling74/min-devkit/tree/master/source/projects/min.hello-world

Repo

1. Build

Result

[build] min.hello-world.cpp.obj : error LNK2001: unresolved external symbol buffer_edit_begin
[build] min.hello-world.cpp.obj : error LNK2001: unresolved external symbol buffer_unlocksamples
[build] min.hello-world.cpp.obj : error LNK2001: unresolved external symbol buffer_locksamples
[build] min.hello-world.cpp.obj : error LNK2001: unresolved external symbol buffer_ref_getobject
[build] min.hello-world.cpp.obj : error LNK2001: unresolved external symbol jit_class_addattr
[build] min.hello-world.cpp.obj : error LNK2001: unresolved external symbol buffer_getinfo
[build] min.hello-world.cpp.obj : error LNK2001: unresolved external symbol buffer_edit_end
[build] min.hello-world.mxe64 : fatal error LNK1120: 7 unresolved externals

Expected

No errors and a successfully built min.hello-world.mxe64

Notes

Enabling the link of jitlib.lib removes only one error, that for jit_class_addattr.
Enabling also the link of MaxAudio.lib removes the remaining 6 errors for buffer_***