Codesign assumes folder structure, fails.
Codesign assumes folder structure, fails.
- Subject: Codesign assumes folder structure, fails.
- From: Graham Cox <email@hidden>
- Date: Tue, 26 Jul 2016 11:15:27 +1000
Hi all,
I’m getting an error from codesign when it tries to sign a third-party embedded framework.
The error is:
/Users/grahamcox/Library/Developer/Xcode/DerivedData/Drawkit-hlbdxcwqkoiqzlesbkfsrobctzke/Build/Products/Debug/Ortelius 2.app/Contents/Frameworks/GEOS.framework/Versions/A: No such file or directory
Command /usr/bin/codesign failed with exit code 1
The problem is that GEOS.framework/Versions/A doesn’t exist. That’s true - the alias ‘Current’ points to a folder called ‘3’ within Versions which contains the executable. ‘A’ doesn’t exist. (i.e. the path is GEOS.framework/Versions/3, and this is where GEOS.framework/Versions/Current points to)
Isn’t this a serious bad assumtion on the part of codesign? Surely the bundle folder structure for executables has always allowed the ‘current’ version to be changed, and ‘A’ is merely the conventional name for version 1, followed by ‘B’, etc? In this case it seems to be using ‘3’ in a sequence which may once have held ‘1’, ‘2’…
This is a 3rd party framework, I have not built it myself, and I’d rather not have to if I can help it. Renaming the folders is easy enough, but nevertheless I would expect codesign to understand the long-standing versioning schema within a bundle.
Bug or reasonable assumption?
—Graham
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden