#461 Undefined Neon symbols building for Apple Silicon

[Ryan Carsten Schmidt]

Building irrlicht 1.8.5 on a Mac with an Apple Silicon (arm64) processor fails:

Undefined symbols for architecture arm64:
  "_png_do_expand_palette_rgb8_neon", referenced from:
      _png_do_read_transformations in pngrtran.o
  "_png_do_expand_palette_rgba8_neon", referenced from:
      _png_do_read_transformations in pngrtran.o
  "_png_init_filter_functions_neon", referenced from:
      _png_read_filter_row in pngrutil.o
  "_png_riffle_palette_neon", referenced from:
      _png_do_read_transformations in pngrtran.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

This was previously reported in bug #452 but it was only fixed in trunk (1.9) not the 1.8 branch.

The solution presented there (setting GCC_PREPROCESSOR_DEFINITIONS to PNG_ARM_NEON_OPT=0) works, but I would only consider that a workaround, not a final solution. Apple Silicon processors do support Neon and it would probably be better to use it since you'd think it would be faster. pngpriv.h only sets PNG_ARM_NEON_OPT to be greater than 0 when it detects that Neon is supported. The problem is that your bundled copy of libpng doesn't include the files in the arm directory that actually implement those functions.

This is another example of the type of problem that could be avoided if it were easy for me to use my existing copy of libpng.

[Michael Zeilfelder]

Sorry, I need an exact patch for this. That project file has changed too much in trunk compared to Irrlicht 1.8. For example in 1.8 we dont have GCC_PREPROCESSOR_DEFINITIONS at all it seems. So I don't know where exactly those changes https://sourceforge.net/p/irrlicht/code/6192/ have to be placed (I'm not familiar at all with xcode, all I do is reading patches to see if they seem to make sense and then hope that people complain again when something fails).

I described already in the other bug-report how you can use your own libraries. Zero chance that I'll be reworking the build-system that much any time soon (working on another task, holiday nearly over, todo list anyway full of tasks on which I rather spend my spare-time). Some things just won't happen unless Irrlicht gets new maintainers which are willing to work on this. All I'm maybe going to to is making it a bit simpler in Irrlicht 1.9, the way I mention already in the other report.

[Ryan Carsten Schmidt]

Sure, here's the patch.

[Michael Zeilfelder]

Thank you! It's applied in branches/releases/1.8 r6519: https://sourceforge.net/p/irrlicht/code/6519

I wonder if adding that arm sub-folder would be enough. Files would have to be added to all project files and Makefile etc, or maybe even only on xcode. Or maybe only some arm target in the xcode project if that exists? But that could be done. When updating pnglib last time I just tried to keep it the same way as it was before (which was without those sub-folders). My guess back then was that they probably only would be used when running the configure tool on the target system first. And we try to have some kinda platform independent solution in Irrlicht which runs without any extra configure steps.

I can't test, but if you want to give this a shot you can try copying the arm folder from vendor/libpng_1637 in the Irrlicht svn (or just copy over that git folder, sounds like the same version). Then add all files to the project and compile once on an arm system and once without on OSX without arm with the same project file (and obviously removing the above disabling of neon). If that all works out I can add that folder and modifed project file.

Thought likely not that much of a difference, I also understand if you avoid that work as long as things work ;-) And would also be a bit tricky with next update in trunk with the changed project file there which would again need another patch or it'll be lost in 1.9 again. Or alternatively this could be done only in svn trunk.. ignoring 1.8.

For now I close this bug as I hope it works.

[Ryan Carsten Schmidt]

Yes I imagine that in addition to adding the arm directory and its files, you'd have to tell your various build systems to build those files, and possibly only on ARM systems; I'm not sure.

This isn't a Mac-specific issue. Bug #443 was reported on an ARM system running Linux. There's also an edition of Windows for ARM processors that may be affected.

I probably won't work on this myself since I don't use irrlicht and don't have an ARM system. My motivation as a MacPorts developer is to fix build failures on macOS, and we've fixed this one.