Solvespace: Does not start on OSX High Sierra

[Timmmm]

With SolveSpace 2.3 on OSX 10.13, it unfortunately doesn't run. It seems to be a library path issue, something to do with libpng. Here's the crash log:

rocess:               solvespace [2311]
Path:                  /Volumes/VOLUME/*/solvespace.app/Contents/MacOS/solvespace
Identifier:            solvespace
Version:               2.3 (2.3)
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           solvespace [2311]
User ID:               501

Date/Time:             2017-09-26 15:21:38.953 +0100
OS Version:            Mac OS X 10.13 (17A365)
Report Version:        12
Bridge OS Version:     3.0 (14Y618b)
Anonymous UUID:        EACDAC31-981D-DF13-7B36-DE7BE4874695

Sleep/Wake UUID:       AA611A9C-5128-4FBD-97AA-298A0ADA851D

Time Awake Since Boot: 1700 seconds

System Integrity Protection: disabled

Notes:                 Translocated Process

Crashed Thread:        0

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    DYLD, [0x4] Symbol missing

Application Specific Information:
dyld: launch, loading dependent libraries

Dyld Error Message:
  Symbol not found: _inflateValidate
  Referenced from: /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
  Expected in: /Volumes/VOLUME/*/solvespace.app/Contents/MacOS/libz.dylib
 in /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib

Binary Images:
       0x100803000 -        0x100c39fff +solvespace (2.3 - 2.3) <225A132B-F702-34BF-8509-81A4175E4DE0> /var/folders/*/solvespace.app/Contents/MacOS/solvespace
       0x100d65000 -        0x100d88ffb +libpng.dylib (0) <E20FFBFB-7682-344D-8B29-F563F3F76603> /var/folders/*/solvespace.app/Contents/MacOS/libpng.dylib
       0x100d96000 -        0x100da7ff7 +libz.dylib (61.20.1) <B3EBB42F-48E3-3287-9F0D-308E04D407AC> /var/folders/*/solvespace.app/Contents/MacOS/libz.dylib
       0x100dae000 -        0x100e2dfff +libfreetype.dylib (19.3) <DCED11A8-2810-347A-86B4-FCFB9D215FC2> /var/folders/*/solvespace.app/Contents/MacOS/libfreetype.dylib
       0x107c1c000 -        0x107c6698f  dyld (519.2.1) <002B0442-3D59-3159-BA10-1C0A77859C6A> /usr/lib/dyld
    0x7fff4ad79000 -     0x7fff4ad79fff  com.apple.Accelerate (1.11 - Accelerate 1.11) <04FC5A30-0382-3FEB-BE8B-E14E9FF4EBD5> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
    0x7fff4ad91000 -     0x7fff4b28ffc3  com.apple.vImage (8.1 - ???) <310976EE-E12D-39D7-8F58-6EE924E08576> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage
    0x7fff4b290000 -     0x7fff4b3eafcb  libBLAS.dylib (1211) <10BFDBE2-C8FB-39E3-A204-BC6420663E57> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
    0x7fff4b3eb000 -     0x7fff4b418fef  libBNNS.dylib (32) <9CA15DC6-004A-32FD-BFCA-F5D488012C43> /System/Library/Frameworks/
<snip>

[Timmmm]

Ok investigating further, the libraries that solvespace depends on seem reasonable:

$ otool -L solvespace 
solvespace:
    /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
    @executable_path/libpng.dylib (compatibility version 42.0.0, current version 42.0.0)
    @executable_path/libz.dylib (compatibility version 1.0.0, current version 1.2.5)
    @executable_path/libfreetype.dylib (compatibility version 19.0.0, current version 19.3.0)
    /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1404.46.0)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
    /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 48.0.0)
    /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1258.1.0)
    /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1258.0.0)
    /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)

And the included libz.dylib does indeed not export _inflateValidate:

$ nm libz.dylib | grep _inflate
0000000000004fcd T _inflate
0000000000003c93 T _inflateBack
0000000000004cf8 T _inflateBackEnd
0000000000003bac T _inflateBackInit_
0000000000006f8f T _inflateCopy
0000000000006c59 T _inflateEnd
0000000000006d93 T _inflateGetHeader
0000000000004e7e T _inflateInit2_
0000000000004f53 T _inflateInit_
0000000000007124 T _inflateMark
0000000000004f6c T _inflatePrime
0000000000004d34 T _inflateReset
0000000000004ded T _inflateReset2
0000000000006caf T _inflateSetDictionary
0000000000006dbf T _inflateSync
0000000000006f63 T _inflateSyncPoint
00000000000070fc T _inflateUndermine

However we can see that ImageIO's libpng tries to load the system libz:

$ otool -L /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
/System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib:
    /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib (compatibility version 1.0.0, current version 1.0.0)
    /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)

Note the system libz is 1.2.11 (the newest available), and solvespace's is 1.2.5 (very old! from 2012). Looking at the zlib source, inflateValidate() was exposed in 1.2.9, which was the first update after a 3-year gap so this isn't mentioned in the changelog.

So it seems what is happening is: solvespace's libz.dylib gets loaded first. Then the system doesn't try to load /usr/lib/libz.1.dylib because it has already loaded zlib and as far as I know linkers aren't too bright when it comes to library versioning.

The simplest solution is to probably to link with the system zlib. I hacked around it as follows:

cd /Applications/solvespace.app/Contents/MacOS
install_name_tool -change @executable_path/libz.dylib /usr/lib/libz.1.dylib solvespace

And now it runs with no problems.

[whitequark]

Thanks for figuring it out!

[wgaonar]

Thanks for this point. Now SolveSpace is working with Hig Sierra 10.13.4

[whitequark]

Duplicate of #310, and fixed there, in a different way.

[PhySysDavid]

Easiest fix ever - functions under Mac OSX 10.14.1 (Mojave) - thanks.

[mePy2]

confirm It works on macOS 10.14.2 too. Thank you very much!
I think it is convenient to make this change in the app bundle directly.

[ty]

I just encountered the same issue in a brew cask on OS X Catalina/10.15.1 -- I removed /System/Volumes/Data/Applications/solvespace.app/Contents/MacOS/libz.dylib and solvespace launches without issue