Summary
openFrameworksCommon.props sets <CompileAs>CompileAsCpp</CompileAs> for all ClCompile
items, and projectGenerator emits no per-file override for addon .c sources. Any addon
shipping C code therefore compiles cleanly and then fails to link.
Reproduction
OF 0.12.1 (also 0.11.0, 0.11.2, 0.12.0), Windows 11, projectGenerator -p vs with ofxLua,
which vendors Lua as 34 .c files under libs/lua/.
projectGenerator.exe -oC:\of0121 -pvs -a"ofxLua" C:\of0121\apps\myApps\test
The generated project contains 35 .c files, none with a CompileAs override:
.c files in vcxproj : 35
with <CompileAs>CompileAsC : 0
They are compiled as C++ (per the props default), which C++-mangles their symbols. Meanwhile
ofxLua.cpp includes the Lua headers under extern "C" and references undecorated names, so:
34 source files compile with ZERO errors, then:
ofxLua.obj : error LNK2001: unresolved external symbol luaL_newstate
ofxLua.obj : error LNK2001: unresolved external symbol lua_close
ofBindings.obj : error LNK2001: unresolved external symbol luaL_loadstring
...
LNK1120: 55 unresolved externals
The "compiles clean, then 55 link errors" shape makes this quite hard to diagnose — nothing
points at the language mode.
Where it comes from
libs/openFrameworksCompiled/project/vs/openFrameworksCommon.props:
<ClCompile>
<CompileAs>CompileAsCpp</CompileAs>
</ClCompile>
Both the app project and openframeworksLib.vcxproj chain to that file, so the default applies
to addon sources too.
Workaround
A per-file override, which MSBuild honours over the ItemDefinitionGroup default:
<ClCompile Include="..\..\..\addons\ofxLua\libs\lua\lapi.c">
<CompileAs>CompileAsC</CompileAs>
</ClCompile>
Because PG rewrites the .vcxproj on every run, this has to be reapplied after each
regeneration — easy to forget, and it fails as 55 unrelated-looking link errors.
Note
The 0.11.1 changelog describes commit 9eabc1c (splitting PLATFORM_CFLAGS /
PLATFORM_CXXFLAGS) as addressing .c-compiled-as-C++. That fixes the Makefile path; the
VS path still emits zero CompileAsC, verified by regenerating on 0.11.2, 0.12.0 and 0.12.1.
Summary
openFrameworksCommon.propssets<CompileAs>CompileAsCpp</CompileAs>for allClCompileitems, and projectGenerator emits no per-file override for addon
.csources. Any addonshipping C code therefore compiles cleanly and then fails to link.
Reproduction
OF 0.12.1 (also 0.11.0, 0.11.2, 0.12.0), Windows 11,
projectGenerator -p vswithofxLua,which vendors Lua as 34
.cfiles underlibs/lua/.The generated project contains 35
.cfiles, none with aCompileAsoverride:They are compiled as C++ (per the props default), which C++-mangles their symbols. Meanwhile
ofxLua.cppincludes the Lua headers underextern "C"and references undecorated names, so:The "compiles clean, then 55 link errors" shape makes this quite hard to diagnose — nothing
points at the language mode.
Where it comes from
libs/openFrameworksCompiled/project/vs/openFrameworksCommon.props:Both the app project and
openframeworksLib.vcxprojchain to that file, so the default appliesto addon sources too.
Workaround
A per-file override, which MSBuild honours over the
ItemDefinitionGroupdefault:Because PG rewrites the
.vcxprojon every run, this has to be reapplied after eachregeneration — easy to forget, and it fails as 55 unrelated-looking link errors.
Note
The 0.11.1 changelog describes commit
9eabc1c(splittingPLATFORM_CFLAGS/PLATFORM_CXXFLAGS) as addressing.c-compiled-as-C++. That fixes the Makefile path; theVS path still emits zero
CompileAsC, verified by regenerating on 0.11.2, 0.12.0 and 0.12.1.