BUG: macOS bundle creation is broken

[fzwoch]

Currently macOS bundle creation does not work correctly.

The reason is that sub-dependencies of libsndfile are relatively located with @loader_path which are not obvious to find.

[dsvensson]

For reference:

$ otool -L ezQuake.app/Contents/MacOS/ezquake-darwin-x86_64 
ezQuake.app/Contents/MacOS/ezquake-darwin-x86_64:
    @executable_path/../Frameworks/libSDL2-2.0.0.dylib (compatibility version 2801.0.0, current version 2801.3.0)
    /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
    @executable_path/../Frameworks/libpcre.1.dylib (compatibility version 4.0.0, current version 4.13.0)
    /usr/lib/libexpat.1.dylib (compatibility version 7.0.0, current version 8.0.0)
    @executable_path/../Frameworks/libpng16.16.dylib (compatibility version 57.0.0, current version 57.0.0)
    @executable_path/../Frameworks/libjpeg.8.3.2.dylib (compatibility version 8.0.0, current version 8.3.2)
    /usr/lib/libcurl.4.dylib (compatibility version 7.0.0, current version 9.0.0)
    @executable_path/../Frameworks/libjansson.4.dylib (compatibility version 19.0.0, current version 19.0.0)
    @executable_path/../Frameworks/libminizip.1.dylib (compatibility version 2.0.0, current version 2.0.0)
    @executable_path/../Frameworks/libspeex.1.dylib (compatibility version 7.0.0, current version 7.2.0)
    @executable_path/../Frameworks/libspeexdsp.1.dylib (compatibility version 7.0.0, current version 7.2.0)
    @executable_path/../Frameworks/libfreetype.6.dylib (compatibility version 27.0.0, current version 27.1.0)
    @executable_path/../Frameworks/libsndfile.1.0.37.dylib (compatibility version 2.0.0, current version 2.37.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.0.0)
    /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1953.255.0)
    /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
    /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
    /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 1228.0.0)
    /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1953.255.0)
    /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)

$ otool -L ezQuake.app/Contents/Frameworks/libsndfile.1.0.37.dylib 
ezQuake.app/Contents/Frameworks/libsndfile.1.0.37.dylib:
    /usr/local/opt/libsndfile/lib/libsndfile.1.dylib (compatibility version 2.0.0, current version 2.37.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.100.5)
    @loader_path/../../../../opt/libogg/lib/libogg.0.dylib (compatibility version 0.0.0, current version 0.8.5)
    @loader_path/../../../../opt/libvorbis/lib/libvorbisenc.2.dylib (compatibility version 3.0.0, current version 3.12.0)
    @loader_path/../../../../opt/flac/lib/libFLAC.12.dylib (compatibility version 14.0.0, current version 14.0.0)
    @loader_path/../../../../opt/opus/lib/libopus.0.dylib (compatibility version 10.0.0, current version 10.0.0)
    @loader_path/../../../../opt/mpg123/lib/libmpg123.0.dylib (compatibility version 48.0.0, current version 48.0.0)
    @loader_path/../../../../opt/lame/lib/libmp3lame.0.dylib (compatibility version 1.0.0, current version 1.0.0)
    @loader_path/../../../../opt/libvorbis/lib/libvorbis.0.dylib (compatibility version 5.0.0, current version 5.9.0)

To be able to modify @executable_path there has to be enough room in the correct Mach-O header for the updated path to fit, as controlled by the -headerpad_max_install_names linker flag. But looking at the example strings here, it looks like the lengh of a string that would be relative to the .app would be shorter in all cases. Perhaps it's enough to just patch libsndfile dylib's paths to point to @executable_path/../Frameworks/... the same way as the executable is patched, and and ofc update the bundler to recurse to dylib dependencies.

To simplify .app in the future, it would probably be easiest to statically link via vcpkg which should be as easy on macOS as on Linux.