Runtime crash on macOS 10.13 (High Sierra) with this dyld message: "Incompatible library version: Application requires version 300.0.0 or later, but CoreData provides version 1.0.0"
Project configured for 10.12 deployment, and loading seems to work in 10.14 or later - and worked properly built with Xcode prior to 12.5. How do I accommodate 10.12 deliveries? Include the CoreData framework? How's that handled in this case (where included isn't needed for current systems)?
It should be possible to build a CoreData project with a modern version of Xcode and back deploy it to an old version of macOS. I recommend that you create a new Core Data test app from the macOS > App template and see if ti has the same problem. That’ll tell you whether this is a general issue or something specific to your project setup.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Thanks for the info. I did just that and it worked. So I guess it is something specific to my project. As far as I understood this is some kind of linkage error where the app doesn't find the provided CoreData libraries. So I'm asking myself how does macOS try to find the system provided libraries like CoreData? Might this be indicative of an error with the "System Framework Search Paths" (which is empty in my case)?
So I'm asking myself how does macOS try to find the system provided libraries like CoreData?
That is a complex question in general, but in this case it’s pretty straightforward. When your app links with a framework, the system adds a load command to the app that tells the dynamic linker where to find that framework and what version numbers are acceptable. You can use otool to dump that info. In the case of my trivial test app, I see this:
% otool -L Test685780.app/Contents/MacOS/Test685780
Test685780.app/Contents/MacOS/Test685780:
…
/System/Library/Frameworks/CoreData.framework/Versions/A/CoreData (compatibility version 1.0.0, current version 1048.0.0)
…
So, what does this show for your test app? And for your real app?
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Hi, thanks for answering!
I'm already using otool, because I found an old post by you explaining a little bit about otool for a different question. I used it and I think I could pinpoint the problem. In my case I have two statements referring to the CoreData Framework:
/System/Library/Frameworks/CoreData.framework/Versions/A/CoreData (compatibility version 1.0.0, current version 1048.0.0)
Which seems to be the correct entry.
But at the very end I have an additional line:
/System/Library/Frameworks/CoreData.framework/CoreData (compatibility version 300.0.0, current version 1775.118.101)
Which I suppose is the problem. I have also checked the same for an old build that I did (which was still working on 10.13) and the output is basically the same but without the probably problematic last line.
Right now I'm in the process of figuring out where this last line comes from.
Thank you, again! I will post if I figure out the where this line comes from.
Interesting. I'm super curious to find out what you uncover.
same. '1775.118.101' has never been and will never be a a Core Data version number.
Some updates:
I have a new clue which I can not investigate right away, but I searched for the version number which according to the comment was and will never be used by the CoreData framework and found the following output on another web page:
/System/Library/Frameworks/Foundation.framework/Foundation (compatibility version: 300.0.0, current version: 1775.118.101)
which corresponds completely regarding the version number. So I'm now assuming that this might be indicative of a problem with the Foundation Framework for some reason being called "CoreData". For me it looks like it takes the version number of the Foundation Framework but adds it as a dependency called "CoreData". And it might also be that this has something to do with the use of cocoapods, which I use in my project.
When I have time again I will investigate this finding further.
Hi there,
so I guess I figured it out...
After understanding more about the build process I figured that there must be some library that exposes itself something like this:
Load command 4
cmd LC_ID_DYLIB
cmdsize 48
name /System/Library/Frameworks/CoreData.framework/CoreData (offset 24)
time stamp 2 Thu Jan 1 01:00:02 197
current version 1775.118.101
compatibility version 300.0.0
After writing some scripts to find and check all the libraries on my system I couldn't find any libraries that advertised itself fitting the above.
What I instead found was the following library:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation.tbd
The library advertised itself like this:
install-name: '/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation'
current-version: 1775.118.101
compatibility-version: 300
which actually looked fine.
But when I inspected it further one thing caught my eye. There were entries that looked like this:
symbols: [ '$ld$previous$/System/Library/Frameworks/CoreData.framework/CoreData$$1$10.9$999$_NSDetailedErrorsKey$',
So there was a reference to "CoreData.framework" which I was looking for because of the previous findings.
The only references in this file to "CoreData.framework" were to this single NSDetailedErrorsKeys symbol.
After fiddling around with the build process and getting some more clues, I looked at my code and it actually used NSDetailedErrorsKey in one place.
When I removed the reference in my code and built the app again I could verify (with otool -L) that indeed, the none-existing reference to
/System/Library/Frameworks/CoreData.framework/CoreData (compatibility version 300.0.0, current version 1775.118.101)
was gone in the built library. And so were the problems getting the app to work on macOS 10.13.
I'm still not sure why this error occurs, but I'm pretty confident that it has to do with the
symbols: [ '$ld$previous$/System/Library/Frameworks/CoreData.framework/CoreData$$1$10.9$999$_NSDetailedErrorsKey$',
entries inside of the
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation.tbd
file. My thought is that if I use NSDetailedErrorsKey that it finds it mentioned in this file and creates this hybrid of a version number from the Foundation framework but by the name of the CoreData framework
which results in this linking that is never going to resolve on "normal" systems.
Looking at the file
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreData.framework/Versions/A/CoreData.tbd
I can confirm that the NSDetailedErrorsKey is also defined as a symbol here (which to me seems to be the correct place since it is a CoreData symbol).
So my guess would be that it is an error that the entries are also present in the Foundation.tbd file. I might file a radar about this issue, if nobody can explain why that is happening.
Another option of preventing this issue from occurring might be to change the order of the included frameworks and/or the search paths so that maybe the system would find the correct CoreData.tbd file first, which also might get rid of this problem.
That’s some good spelunking!
My thought is that if I use
NSDetailedErrorsKeythat it finds it mentioned in this file and creates this hybrid of a version number from the Foundation framework but by the name of the CoreData framework which results in this linking that is never going to resolve on "normal" systems.
Yeah, that’s super weird, and based on the info you provided I was able to reproduce the problem in a new project that I created here in my office. I’ve filed my own bug about this (r. 84254696).
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Good to hear, did you need to mess with the framework search path order to make this misbehave the same way? So I guess your radar is enough or should I also create one?
did you need to mess with the framework search path order to make this misbehave the same way?
No. The trick was:
Reference NSDetailedErrorsKey in my code
Turn off auto link
Link with Foundation but not CoreData
So I guess your radar is enough or should I also create one?
My bug should be sufficient but if you create your own bug and ask it to be dup’d to mine then you’ll be notified when it get fixes.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
-
—
flexxx
Add a CommentHi, is there any news on this. I have the same problem in a private library which throws the same error on macOS 10.13. What I found so far is, that for a lot of people adding the "CoreData" framework as a library to the target in question fixed the problem.
But for me the problem persists. I just upgraded to Xcode 13.0 and the problem continues to exists there. I have also cocoa pods in use which might change some of the build settings and maybe it has something to do with that also?
Anyone has more details on why this error is happening?