- Home /
plugin dependencies
I am on Mac and I made a Cocoa bundle that I want to use as a plugin. If the bundle contains only simple stuff this works. However if I make a bundle, that links to an external Framework I get a Runtime DllNotFoundException, which I expected, because Unity can't finde the dependencies. The question now is what do I have to do to make Unity find the missing dll/shared libraries? If I install the Framework in my ~/Library/Frameworks directory everything works fine, but I would rather not have to install external Frameworks on a users machine. Is there a way to include the needed dll's in the build?
Answer by jonas-echterhoff · Jan 04, 2010 at 10:33 AM
This depends on the way the libraries you are using are built. If they are static libraries, you could just add them to the project, so they will be included in your plugin. If they are bundles or dylibs, they have a search path hard coded into the binary by the linker. This is usually Library/Frameworks, as you said.
If you have source access to the library, you can make a custom build, where you set up the search path relative to the executable, so you can include the dlls in the build. If you don't have source access, your only option would be to manually load the functions from the library (which is more work). I can explain how to do either, but then it would be good to know which case applies to your problem.
Ok, I have some code that does face detection and some other computer vision stuff, which I want to use as a plugin in Unity. This code depends on the OpenCV.Framework, but otherwise I have full access to the source code and build settings.
The relevant part is having access to the OpenCV.Framework - as that appears to be the problem, you want that to go to a local directory, and not to /Library/Frameworks. But since the source for OpenCV is available, I presume you could just get that and build your own. In that case, what you should do, is either to build it as a static library, or, in the linker settings for that framework, set "Installation Directory" to "@executable_path/../Frameworks", to make it load the framework from YourApp.app/Contents/Frameworks ins$$anonymous$$d of Library/Frameworks.
$$anonymous$$aybe there is something else going on. I took a look at the bash script, that builds the OpenCV.framework and it uses export FRA$$anonymous$$EWOR$$anonymous$$_INSTALL_PATH="@executable_path/../Frameworks", so I guess it's already set up correctly. I'll try to recreate this by writing my own simple framework and see what happens.
Oops, after trying all kinds of build settings I found out that I just forgot to add a "copy files" build phase to my own bundle, which copies the OpenCV.framework to the bundles Frameworks folder. Thx for your help with this!
Hm, I fooled myself, having the framework in my library. If I remove it from Library/Frameworks it still doesn't work. Could we go through the process step by step, using a simple example? $$anonymous$$y example setup would be writing a Framework containing only one function Call$$anonymous$$e() which returns 1.0f. Then I create a bundle that links to my framework and uses the Call$$anonymous$$e() function. The bundle also contains only one function Call$$anonymous$$eFirst() which calls Call$$anonymous$$e() and returns its return value.
Answer by StephanK · Jan 05, 2010 at 04:16 PM
I finally figured it out. If you are on OSX10.5 or later you can build the framework with the installation path set to "@rpath". In your plugin bundle you can now specify where to look for the framework using the Linking option Runpath Search Paths. If you include the framework in your bundle (with copy files build phase -> frameworks) you can find it at "@loader_path/../Frameworks".
However there seems to be a problem with aliases during the build process in unity. If you include the framework in your plugin bundle you will get unity build errors when it tries to copy the aliases contained in the framework. ("Headers", "Current" etc.) If you delete those aliases manually from the bundle everything works fine. Maybe that's a Unity bug?