It seems on OSX, DLLImport isn’t behaving correctly:
[DllImport(“libA”, EntryPoint = “Foo”)]
private static extern void FooA();
[DllImport(“libB”, EntryPoint = “Foo”)]
private static extern void FooB();
On Windows and Linux, this will FooA() will call Foo from libA and FooB will call Foo from LibB().
On OSX, both FooA() and FooB() are calling Foo from libA.
If I were to guess, Linux and Windows is loading the libraries with RTLD_LOCAL and OSX is loading the library with RTLD_GLOBAL.
It could be that the defaults for dlopen are opposite for these flags on Linux and OSX.
https://linux.die.net/man/3/dlopen
http://www.polarhome.com/service/man/?qf=dlopen&af=0&tf=2&of=Darwin
danduong:
It seems on OSX, DLLImport isn’t behaving correctly:
[DllImport(“libA”, EntryPoint = “Foo”)]
private static extern void FooA();
[DllImport(“libB”, EntryPoint = “Foo”)]
private static extern void FooB();
On Windows and Linux, this will FooA() will call Foo from libA and FooB will call Foo from LibB().
On OSX, both FooA() and FooB() are calling Foo from libA.
If I were to guess, Linux and Windows is loading the libraries with RTLD_LOCAL and OSX is loading the library with RTLD_GLOBAL.
It could be that the defaults for dlopen are opposite for these flags on Linux and OSX.
https://linux.die.net/man/3/dlopen
http://www.polarhome.com/service/man/?qf=dlopen&af=0&tf=2&of=Darwin
You would be correct that we do use RTLD_GLOBAL for macOS, can you please file a bug for this just so we see it and track it.
Ah I found it in Unity Hub. I’m currently running 2018.4. Will your fix be patched on this version?