I am currently trying out several options on how to build all the stuff and the gcAPI.lib thing is one of the issues these endeavors should explore
I will also probably try a completely different runtime setup for all of the D3D9Client related builds, as I noticed that the "recommended" setup by the Orbiter-BETA provided prop-sheets use
MultiThreadedDLL for
release builds and
MultiThreadedDebugDLL for
debug builds[1].
As far as I know, for a complete coverage we would need to provide a lib for all possible combinations:
Release/Debug <=> Multithreaded/Singethreaded <=> Statis/Dymanic
...and possibly some more I've missed.
The general goal however is: Provide one library for all release module DLLs that need gcAPI support, while during development the Modue-developer still can do so by getting the source-code.
Complicating the tasks is that I like to keep the ability to build D3D9Client with several versions of Visual Studio (2008, 2015, 2017, 2019), all preferably as debug and release builds.
Adding the two main branches (trunk for BETA, 2016 for Orbiter-2016) sometimes makes this more complicated then it looks :lol:
Nevertheless, I'm glad that you could make a debug-build for your purpose.
[1] See
Orbitersdk\VS2015\PropertyPages\orbiter.props &
Orbitersdk\VS2015\PropertyPages\orbiter_debug.props