Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Unity Linux Plugin depending on third party library DllNotFoundException

Discussion in 'Linux' started by alwaysunny, Apr 20, 2017.

  1. alwaysunny

    alwaysunny

    Joined:
    Apr 20, 2017
    Posts:
    1
    Hi,

    I am working on a Unity project that needs a c++ plugin depending on OpenCV. The plugin itself was compiled as a .so shared library and it can be loaded by Unity. The plugin depends on OpenCV and I put the necessary opencv library (libopencv_highgui.so) onto the Assests/Plugins/x86_64 folder. However, when the plugin is loaded, it seems it cannot locate the opencv library.

    • Couldn't open Assets/Plugins/x86_64/RenderingPlugin.so, error: Assets/Plugins/x86_64/RenderingPlugin.so: undefined symbol: _ZN2cv12VideoCapturersERNS_3MatE

    I checked Assests/Plugins/x86_64/libopencv_highgui.so and the _ZN2cv12VideoCapturersERNS_3MatE entry exists in it.

    • -> % nm opencv_highgui.so | grep _ZN2cv12VideoCapturers
    • 0000000000018a90 T _ZN2cv12VideoCapturersERNS_3MatE
    I also tried to put the opencv library in the editor folder, but still didn't work.

    I tried my project on windows and put the opencv's dll file in the plugins folder and it works well. Is it a linux Unity's bug or I didn't complied the library correctly?

    Many thanks!
     
  2. faviann

    faviann

    Joined:
    Sep 9, 2015
    Posts:
    8
    Ever find an answer to your question? We're seeing a similar bug on Linux too.
    We're on 5.6.1
     
  3. Tak

    Tak

    Joined:
    Mar 8, 2010
    Posts:
    1,001
    Linux is a bit different than some other platforms in that the directory a library is loaded from isn't automatically part of the library search path. So if you have libMyPlugin.so and libThingMyPluginNeeds.so in the same directory, you won't be able to dynamically load MyPlugin unless the directory where ThingMyPluginNeeds lives has been added to the library loader path (usually via the LD_LIBRARY_PATH environment variable).

    We've tried to ameliorate this in recent Unity releases (5.6+ iirc) by attempting to preload libraries from the Plugins folder, so that any plugin dependencies can be loaded, as long as their dependencies are loadable. (You should get output like Preloaded 'ScreenSelector.so'.)

    For plugins you build yourself, you can also resolve this by setting a runtime path for your plugin when you link it.
    For example, when using gcc, you can add -Wl,-rpath='$ORIGIN' to your link line. This will make the loader look for linked libraries in the same directory where your library lives.

    To diagnose loader issues, you can run ldd libMyPlugin.so to see where its dependencies will be loaded from by default.
    You can also run Unity or your player with MONO_LOG_LEVEL=debug MONO_LOG_MASK=dll set in your environment, so that Unity will log diagnostic information about what's happening with respect to native plugin loading.


    Hope this helps,
    Levi
     
    Sisso and faviann like this.
  4. sseritan

    sseritan

    Joined:
    Apr 22, 2016
    Posts:
    2
    I was dealing with a similar issue on Linux Unity 5.6.3 (gcc 5.4.0, XUbuntu 16.04). I have a plugin (libhaptic.so) that wraps a shared library libHD.so that lives in /usr/lib. When I compiled my .so with g++ -L/usr/lib -lHD -shared -fPIC -o libhaptic.so, ldd did not show libHD.so as a dependency of libhaptic.so. However, when I switched the order to g++ -shared -fPIC -o libhaptic.so -L/usr/lib -lHD, ldd DID show libHD.so as a dependency, and including just my libhaptic.so in Assets/Plugins was enough to make it work. I feel like order shouldn't have mattered but it did for me.

    Not sure if I was just being dumb earlier and don't understand compilers/linkers as well as I should, but hopefully this could help someone.