So I’ve been debugging this over the last day, but I still haven’t been able to find the problem. Stepping through the PluginManager / ModuleManager code, more specifically, the most interesting parts happen around ModuleManager.cpp:347; this is where the engine eventually does LoadLibrary, which in turn is what is supposed to instigate the execution of the static parts of my dll (more specifically the generated .inl files that perform UOBJECT registrations). For some reason though, my dll:s .generated.inl is not called into. The DLL itself seems to load fine (The handle is valid after LoadLibrary) but no symbols have been loaded (I can’t put breakpoints in my .inl file).
When studying the Hydra plugin in more detail however, I came across something curious, in this plugins build file, it seems like he first tried to go the statically linked lib route, but then changed his mind, commented out the lib reference and settled on loading the sixense dll dynamically at moduleinit. Does UE4 have some problem with statically linked 3rd party libs in plugins perhaps?
I was about to try and try this new route; to load the DLL myself and then get all function pointers I need to try and see if it would work for me too, but unlike the sixense libs, the lib I’m working with has tens of functions, and replacing everything will take some time, so I thought I’d post here first and see if anyone has any wisdom to share, or some light to shed on the situation.
To elaborate a bit; what I mean by “Does UE4 have some problem with statically linked 3rd party libs in plugins perhaps” is something in the lines of, since the lib is probably only a wrapper that calls into the dll anyways, and it would then have to look in the working directory of the project, which happens to be in the engine’s bin folder, I was up to this point just placing my client dll in that bin directory. But it occurred to me now that maybe UE doesn’t like plugin dll’s residing in the main bin directory (as it should, I just couldn’t find another workaround at that point). It did work when I did that though, but maybe when it is loading the plugin dll from my plugin’s bin folder, it needs the same reference again? I tried copying the dll to this location too, but it did not seem to work, so maybe there is some double load problem here. Anyways, my best lead atm is that UE4 has some problems with wrapper libraries such as this and that the solution might be to ignore the lib and load the dll manually in runtime.