Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Does not start on OSX High Sierra #294

Closed
Timmmm opened this issue Sep 26, 2017 · 7 comments
Closed

Does not start on OSX High Sierra #294

Timmmm opened this issue Sep 26, 2017 · 7 comments
Labels
duplicate

Comments

@Timmmm
Copy link
Contributor

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/*/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
Copy link
Contributor Author

Timmmm commented Sep 26, 2017

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
Copy link
Contributor

Thanks for figuring it out!

@Real-Gecko Real-Gecko mentioned this issue Oct 10, 2017
Closed
@wgaonar
Copy link

wgaonar commented Jun 3, 2018

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

@whitequark
Copy link
Contributor

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

@PhySysDavid
Copy link

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

@mePy2
Copy link

mePy2 commented Feb 17, 2019 •
edited
Loading

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
Copy link

ty commented Nov 27, 2019

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

Sorry, something went wrong.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
duplicate
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@ty @whitequark @Timmmm @wgaonar @mePy2 @PhySysDavid