It seems recent changes in IL2CPP or the way iOS projects are compiled broke our plugin.
Our native plugin has a dependency on libpng. Before the arm64 support we didn’t have any problem but with Unity 4.6 and 5.0 came the issues.
At first we realized our plugin was calling Unity’s libpng (with a different patch version number, should work according to libpng’s headers but apparently didn’t) at runtime instead of ours. We fixed that by changing the linking order in the build phases.
This no longer works, unfortunately.
I’m guessing it has to do with the linking order again and some internal IL2CPP project generation, so I’d like to know how I can make this work again.
We very much need our plugin to open and read PNG images, surely there must be a solution for us to do so again.
Hi, thanks for chiming in!
I forgot to be more specific, sorry about that.
So, it depends on the linking order set in the build phases in XCode.
When our static library statically linked against libpng is above everything else (this is what used to work for early arm64 builds), loading a png texture results in a crash at runtime in a call to png_read_info because of a SIGABRT in png_read_info. Presumably because png_sig_cmp fails, so it calls png_error which triggers the SIGABRT.
Since I can break in png_read_info when built in debug but not in png_sig_cmp, or png_error (I can only see the disassembly), I’m suspectig some mixup in the libpng symbols…
When it’s left in the order generated by Unity it just fails loading (png_create_read_struct returns a null pointer, breaking into that function only exposes the disassembly).
I think the problems come from static linking of 2 different versions of the same library, which causes all sorts of mayhem.
I guess I could update our version to match that of Unity, but I don’t know which one it is.
Ok, I fixed the problem by upgrading our libpng to 1.6.18 and generating prefixed symbols (prefixing is available from 1.6 onwards).
Now our code effectively calls our own libpng.
