Hey all,
So I have a C++ dll I wrote. It depends on pthreads, in particular, pthreadVC2.dll. It works perfectly fine in the editor. However, when I build it to a Windows executable, the game does not work, I get a DLLNotFoundException. It DOES work, however, if I put pthreadVC2.dll in the same folder as the executable.
Distributing this DLL which sits at the top level next to the executable seems kind of sloppy, so if there’s another way to resolve this problem, I’d love to hear it. I’ve tried placing this DLL in the plugins directory as well as a few other places, but I can’t seem to get it to stick anywhere but at the top level.
In my researching this problem, I’ve heard people say that placing the offending dll that my plugins are dependent on inside the Editor folder of the Unity installation directory. However…this particular dll (pthreadVC2) comes with Unity so it was already there, which is probably why I never had issues when running my code in the editor.
Any tips? If more information is required, I’d be happy to provide it. Thanks.
Unity 3.3.0f4 (Pro)
-Mark
There is no alternative way to resolve it at least not without making it totally painfull to work with it when you write the C++ side and debug it.
If it requires this unmanaged DLL it has to be there right next to the exe, it won’t find it otherwise. Thats due to the dll to dll dependency not being caried in the way that the second one has to be relative to the first dll, but relative to the application.
So the way to change it would be changing the relative path in relation to the dll to the place it will be in the final exe but thats not really practicable.
Question is: why do you have the rest as own DLLs instead of building just 1? is pthreadVC2 a precompiled library you use?
Thanks for the reply. I’m going to look into the relative path suggestion you mentioned.
If it helps clarify, my plugin is multithreaded, and it uses the pthread library to accomplish this. In my dll, I implicitly link to it (I connect it to a pthread.lib file). So I am just building 1 DLL, unless I’m misunderstanding your question. The pthread library I’m using is indeed a precompiled library, I could look into the availability of the source code/licensing to try to build the source directly into my dll, didn’t think of that before.
Oh, and it works on Macs fine when made into a bundle. The cocoa framework includes a pthread implementation, so I don’t have to include anything extra for pthreads, it just works with a #include.
I wouldn’t expect it to be done NOW of course, but my wishful thinking is that those DLLs which can be used when running the game in the Unity editor would still work when the game is built. But I’ll work around in the mean time.