Building c++ externals in Visual Studio, release
For the first time in many years I'm building my externals in VS and had several hours of work to get my c++ code to compile in release mode. In case it helps future coders here's what I found:
- The advanced/collect example (.vcxproj) is a good starting point but won't build in Release. Setting project property "C/C++/Code Generation/Runtime Library" to "Multi-threaded DLL (/MD)" clears a lot of linker errors, such as:
1>collect.obj : error LNK2001: unresolved external symbol "void __cdecl operator delete[](void *)" (??_V@YAXPEAX@Z)
1>collect.obj : error LNK2001: unresolved external symbol "void * __cdecl operator new(unsigned __int64)" (??2@YAPEAX_K@Z)
1>collect.obj : error LNK2001: unresolved external symbol "void __cdecl operator delete(void *)" (??3@YAXPEAX@Z)
1>collect.obj : error LNK2001: unresolved external symbol "void __cdecl operator delete(void *,unsigned __int64)" (??3@YAXPEAX_K@Z)- When adding new files to the project VS doesn't always get the right compiler set, i.e. compiles c code with c++ compiler or vice versa. The property "C/C++/Advanced/Compile As" can be set to "Compile as C" or "Compile as C++" for the whole project or each file individually. The vagueness of "Default" wasn't always helpful.
With those settings cleared up I've been able to port my Mac externals and build the .mxe versions with the full optimization of the Release configurations.
I couldn't find this information on the forums already, but if it is a duplicate I'm happy to have this thread closed.
Thanks for adding this info to the collective knowledge. I personally haven't used that version of Visual Studio in many years.
Regarding the choice of Multi-threaded DLL this may require that users of standalone apps built with Max install the Microsoft C Runtime libraries. Max ships with this dependency taken care of so it won't impact users of your external in Max itself. To avoid this dependency the externals can be built using static linking to the C runtime library.
Cheers!
A caution on using static linking. Static linking increases risks for users of your external and can make coding/maintenance/support harder for you. I moved away from static linking myself.
It was more important to get runtime bugfixes and runtime security fixes -compared- to the ease of installation. If you use static linking, you and your users never get fixes to runtime code that your external uses.
It was also important that my external can communicate across to other DLLs. When using a static runtime, there are situations when code compiled with static can *not* communicate with code using dynamic runtimes. In those situations (I ran into one), there is no workaround...you must compile to a dynamic runtime. My scenario had to do with shared locks/memory/mapping if I remember correctly.
The runtime Cycling distributes with Max 7 is old. If you're not careful, you will statically link to it. It is C Runtime 9.x which is a codebase now ten years old. It was distributed with VC 2008.
Windows has evolved. Just like *nix. The OS regularly updates itself to fix bugs and close security holes. A few years ago started the "Great C Runtime Refactoring" https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/
Due to this, the runtime is increasingly part of the OS. And as part of it, gets regular updates. By using dynamic linking, you and your users get all the benefits of security and functionality fixes.
I have many customers that use my externals for Kinect. Currently, I require my customers to manually install the runtime. I have very few support incidents due to runtime install problems. Likely because of above GCRR and that the runtime is often already installed. Still, if the install concerns you, there are free Windows Installer tools that can automate it like WiX and the native Windows Installer.
Thanks for the thorough and well thought out response, Dale. These trade-offs are never perfect. Having this info in the thread makes such decisions better informed and is appreciated!
Thanks for the feedback! I'll look into linking and see if I can support dynamic linking effectively as it seems like a better long term tradeoff (building in Win is not my favorite thing to do, and minimizing rebuilds would be ideal). Thanks for the detailed thoughts, Dale.