New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does not start on OSX High Sierra #294

Timmmm opened this Issue Sep 26, 2017 · 4 comments


None yet
3 participants

Timmmm commented Sep 26, 2017

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/*/
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/*/
 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/*/
       0x100d65000 -        0x100d88ffb +libpng.dylib (0) <E20FFBFB-7682-344D-8B29-F563F3F76603> /var/folders/*/
       0x100d96000 -        0x100da7ff7 +libz.dylib (61.20.1) <B3EBB42F-48E3-3287-9F0D-308E04D407AC> /var/folders/*/
       0x100dae000 -        0x100e2dfff +libfreetype.dylib (19.3) <DCED11A8-2810-347A-86B4-FCFB9D215FC2> /var/folders/*/
       0x107c1c000 -        0x107c6698f  dyld (519.2.1) <002B0442-3D59-3159-BA10-1C0A77859C6A> /usr/lib/dyld
    0x7fff4ad79000 -     0x7fff4ad79fff (1.11 - Accelerate 1.11) <04FC5A30-0382-3FEB-BE8B-E14E9FF4EBD5> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
    0x7fff4ad91000 -     0x7fff4b28ffc3 (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/

This comment has been minimized.

Timmmm commented Sep 26, 2017

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

$ otool -L 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 (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/
install_name_tool -change @executable_path/libz.dylib /usr/lib/libz.1.dylib solvespace

And now it runs with no problems.


This comment has been minimized.


whitequark commented Sep 27, 2017

Thanks for figuring it out!


This comment has been minimized.

wgaonar commented Jun 3, 2018

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


This comment has been minimized.


whitequark commented Jul 12, 2018

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

@whitequark whitequark closed this Jul 12, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment