* Restore missing darling specific changes from previous release
* Use <CarbonCore/MacErrors.h> instead.
* Fixed building for i386
* Adjusted location of where some files are now stored at.
We'll build more stuff later, but for now, the stuff that was currently building is now building again (except `secd`; that one has been tangled up by more "secret" libraries since the update)
To build the rest, we'll need to enable Octagon and TrustedPeers, and I'm not sure what effect that'll have. To be honest, I'm not even sure what they do
This is only the *build* of the Security framework. It does not link yet, and I also have not tried building the various executables yet.
This one required lots of edits in various places throughout the Darling codebase. It seems Apple has really changed things up from 10.13 to 10.15.
A great example of the huge difference is that libDER is no longer included with Security! I had to import it from the last version it was released and modify it slightly to fit the updated code.
Yet another example of Apple being bipolar towards open-source. I wonder what kind of secrets they could be hiding in a library made for working with an *open standard*, smh.
Also, since 10.15 included the drop of 32-bit support, Apple has now made use of many more "modern" Objective-C runtime features, such as automatic ivar synthesis.
Since we want to keep 32-bit app support in Darling but also support newer 64-bit apps and frameworks, I've put the sources using the new features into x86_64-only object libraries.
That way, we only build them for 64-bit and they're available in the 64-bit part of the final "fat" framework. This is fine because those brand new sources aren't used by any old 32-bit code (and 32-bit code can't be updated to use it, either).
Also, I'd like to point out that Apple's code uses such a mess of includes that it's ridiculous (and this is for all their projects, not just Security). Some sources require more includes than the ones listed in Xcode.