* 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.
Maybe they changed `DERParseSequenceContent` after making libDER closed-source, and therefore this would be an issue with us using the last released libDER sources.
This fixes certificate parsing and it was just a simple reversion to the old function call, which is why I think it was a typo in their updated code.
This was just a quick search-and-replace to get the project compiling again, but we'll need to rename some libraries and generated files to complete the architecture abstraction.
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
I had to change up quite a few things in other libraries/frameworks in terms of how they're built/linked; specifically, I had to change up Foundation, CFNetwork, and CoreTLS.
Basically, Apple makes them all depend on each other, so I had to make some of them circular (and the Security framework, too).
I had some issues with this at first because making Foundation a circular library caused the linker to segfault trying to link the 64-bit firstpass (weird, I know).
So instead, I decided to make CFNetwork circular with no siblings (which is perfectly okay), just to make it run a firstpass with no dependencies, then link Foundation to that.
Then, Security links to Foundation normally and everybody's happy.
I also had to build `libcoretls_cfhelpers`, which depends on Security, but Security also depends on it, so I think you can guess what I had to do.
(In case you can't guess: I had to make coretls_cfhelpers a circular library, as well as Security, too).
Also `libsecurity_keychain/lib/CCallbackMgr.cp` is not misspelled; it came with the `.cp` extension, but I had to tell the compiler that it's a C++ file (not sure why the non-standard extension, but whatever).
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.
The issue is that the exported symbols list from Apple is
preprocessed. For whatever reason, it isn't being properly
preprocessed. The solution was to join the #included
ones together manually and get rid of the #if, etc.
The result of this is SEC_MANUAL.exp.
darlinghq/darling#445
