- Home /
How to make Unity find .dylib files?
Ok, I have 6 .dylib files built from OpenCV source code. These have respective .dll versions when deploying on Windows, which is already working without much effort.
However, I can't seem to understand how to make Unity find my .dylib files on OSX. The .NET wrapper fails with DllNotFoundException because it can't find the native OSX files, I guess.
The docs talk about .bundle files built with XCode. I have tried this, and even though I add the .dylib files as external frameworks, I seem to always end up with semi-empty .bundle files not containing the .dylib files that I added to the project. I read something about using install_name_tool to modify the bundles, but it's really confusing and I'm not quite sure about the interdependencies among these .dylib files. Do you really have to do this manually?
What's the simplest possible way to make Unity find the .dylib files? Can someone please shine some light on this seemingly super-obscure subject?
Is there not a tool to simply build a bundle with .dylib files that Unity will function with? Why is it so complex on OSX, when on Windows you just dump the dll files in the Plugins directory?
Also, I have tried to use configuration xml files as instructed by: http://www.mono-project.com/Interop_with_Native_Libraries
..without much success. Anyone know if $$anonymous$$ono config files like these work in Unity?
I'm still watching this question. I've tried building a bundle with Xcode, with a project generated from C$$anonymous$$ake. But all I get is and empty .bundle file, even though I added the dylibs as dependencies. Any help appreciated - I'm very inexperienced with OSX development.
Additionally, you can simply drop your dylib in the root of your project folder and it will load properly.
@armirebrahimi_unity True, but this only works in the editor. You have to manually add the dylib to a build yourself or create a post build script to add it to the package.
Answer by Magnus Wolffelt · Aug 04, 2010 at 02:27 PM
Ok I think I've worked out a solution. This might save some people a LOT of time and headaches:
Renaming a .dylib file to .bundle makes Unity find and load it, and it works! Weird? Yes.
Well, according to a post I found, on modern OSX, dylib and bundle are in practice interchangable, as they nowadays support mostly the same features (loading and unloading with dlopen() and dlclose()):
- The modern dlopen implementation on the Mac (it wasn't there at all in 10.0) seems capable of loading both "bundles" (the file version I think) and regular Mac shared libraries. In 10.4, dlclose() couldn't unload a dynamic library but could unload a bundle; in 10.5, it can unload both. So it's unclear how relevant the distinction between "loadable objects" and "shared libraries" is any more, at least if you're targeting 10.5 or 10.6 as your minimum required OS version.
http://www.mail-archive.com/bug-guile@gnu.org/msg04999.html
Sooo... the limitation seems to be a Unity one in that it simply does not consider .dylib files for loading - only .bundle files, but when it does load .bundle files which happen to be dylib files, OSX just swallows it.. It could also be that this only works in Unity 3.0 - haven't tried in older versions.
Happy coding! Feel free to comment!
Actually, something sketchy is going on here. I've fiddled a lot with the install_name_tool to set paths. The most useful one so far appears to be @rpath. But it's working randomly. If it works, and I restart Unity, it can simply stop working. No idea why it's so random.
I gave up on this and just installed the dylibs into /usr/lib ...
..after putting @rpath/ on all the cross-references using install_name_tool.
$$anonymous$$ajor thanks for mentioning this.
This worked pretty well for me in the editor. However, it caused the exporter to just choke with an error:
Error building Player: IOException: Cannot create Temp/StagingArea/UnityPlayer.app/Contents/Plugins/mylib.bundle/mylib.bundle because a file with the same name already exists.
the solution was, when doing the export, to move the library out of the plugins folder, and then to manually copy it into the Contents/Plugins/ directory in the application bundle myself once it had been built. $$anonymous$$ay try to automate :)
@$$anonymous$$agnus - The "sketchy" random behavior of plugins in OSX is a bug in Unity. It only re-imports your plugin when you choose Reimport All (or probably when you open and close Unity). This was pointed out by nay here: http://answers.unity3d.com/questions/548360/opengl-causing-dllnotfoundexception-on-osx.html
Answer by jonas-echterhoff · Jul 29, 2010 at 09:22 AM
AFAIK, there is no way to convert dylibs to bundles, and you are correct that Unity will need bundles to load native C++ code on Mac OS X. You need to have the XCode project used to generate the dylib files, and reconfigure that to output bundles.
Does each .dylib file need to be in its own bundle? Or can I put all 6 of my dylib files in one bundle, and Unity will find them with DllImport?
That should not matter, if you have one bundle built from all the original source files used to build the 6 dylib files, thus containing all the needed code, then that should work fine.
This won't work I think, because the .NET wrapper does DllImport with very specific library names, such as cxcore210 and cv210. I don't really have control over the wrapper code, for all practical purposes.
Answer by tedlin01 · Jun 02, 2013 at 09:11 PM
I wrote a tutorial for this at my blog. Hope it helps :)
Answer by tristanjl · Oct 23, 2013 at 05:05 AM
Following up on Magnus Wolffelt's IOException issue, we had the same issue occurring and added a UnityEditor.Callbacks.PostProcessScene script that, on !EditorApplication.isPlayingOrWillChangePlaymode, moves the bundle outside of the plugins directory and a UnityEditor.Callbacks.PostProcessBuild that moves it back to that directory and copies it into the app. It works well enough for us, could be better though.
Answer by hogwash · Jul 03, 2018 at 12:44 PM
Here's how you can convert a dylib to a bundle:
lipo -create build-release/src/nvtt/libnvtt_x86.dylib build-release/src/nvtt/libnvtt_x86_64.dylib -output nvtt
mkdir -p ../../../UnityProject/Assets/Scripts/Editor/TextureImport/nvtt.bundle/Contents/MacOS/
cp nvtt ../../../UnityProject/Assets/Scripts/Editor/TextureImport/nvtt.bundle/Contents/MacOS/
Alternatively if you just want to ship 64-bit then skip the lipo step and copy the dylib (without extension) to the Contents/MacOS folder