hi all,
I have built an empty/default Rhino SDK C++ plugin and it builds+gets installed in Rhino successfully as expected.
When I am trying to build the same test Rhino plugin in a static build, it also builds succcesfully. The test.rhp is much bigger than it was when it was built dynamically.
However, when I try to install it in Rhino I get the error:
Unable to load test.rhp plug-in: initialization failed.
What’s the configuration I have to do to make it work?
My configuration in test properties pages so far are:
Configuration Type: Static library (.lib) in Configuration Properties/General
Use of MFC: Use MFC in a Static Library in Configuration Properties/Advanced
Runtime Library: Multi-threaded(/mt) in C/C++/Code Generation
Rhino C++ plug-ins are DLLs, not static libraries.
In general, you should stick with the compiler and linker settings generated by the Rhino plug-in wizard for Visual Studio. This include using the same MFC an C-Runtime libraries (/Md) used by Rhino.
Hi @dale,
thanks for your quick reply! Hence, if I understood well, it is impossible to build statically a Rhino C++ plugin with all of its dependencies included in the rhp file. Is this the design behind Rhino plugins or is there any workaround? If they are meant to be only DLLs, then I suppose I have to copy all external DLLs in the workspace. If the external DLLs are a lot I imagine that maintenance could end up being an issue.
Is it possible to create a static library with /MT Runtime Library parameter while the Rhino plugin is set with /MD?
If I set /MT for the Rhino plug in I get: error: Please use the /MD switch for _AFXDLL builds
/mt and /md affect how the c runtime is linked to your program; if you use /mt then the crt will be statically linked, and your library will have (among much more – the entire crt state) its own copy of functions like new & delete, allocating memory from your own private heap, while rhino and the rest of its loaded /md libraries will be using the heap of the required msvc++ redist libraries installed on the machine
you can see why this would be a problem, whether we are talking about a mismatch between rhino & your plugin, or between your plugin and another library it uses, or in any other such arrangement
and if by dlls, you refer to third party dlls other than those of the crt, compiling your plugin with /mt would do nothing to help you, since those dlls will already be /md, with accompanying static .lib files that contain no real code, and are rather just so-called “import” libraries that tell the linker where to find the functions you are trying to call in the dlls – you would still require the dlls at runtime, and /mt would do nothing to change this
however, I get the idea you may be creating these dlls yourself, from your own code:
if you are referring to making a library for your own code, because you want to keep that code separate from your rhino plugin dll project, then you can certainly compile your code into a static library (also using /md) and link it to your /md rhino plugin dll – this static library will not be an import library like one for a dll, and will rather contain all the .obj files produced from your compiled files, which will be linked into your rhino plugin, with no extra dll dependencies, and with everything in the system happily using /md
Thank you very much for your explanation, it made things much more clear about the /mt and /md parameters! Indeed, I am building some of my own static libraries which contain the compiled .obj files. My current problem is that my static library depends on other libraries like imgui, glad and glfw3 and I haven’t figured out how to import these dependencies into my rhino plugin project without copying their dlls in the rhp folder. Is there some advice/walkthrough of how to do it?
Thanks!
the only way to avoid deploying those dlls will be to clone the repos and build the code yourself, to a static library, instead of using the pre-built dll versions you downloaded
this is not easy, but it is possible – easier with some, more difficult with others, but generally possible (I currently do this with around 50 external dependencies, so I am not just speaking hypothetically)
some projects will have static build modes already in their build systems, and you will mainly need to figure how to set something like BUILD_STATIC=1 in cmake or such, while others will need more research & work
