![]() If I remember correctly, the bug in libxml2 seemed to be in code embedded in NSXMLDocument. □ But you are correct about it being subtle. It was actually libxml2 that burned me one of those times. In recent years Apple has been much more careful about what’s in the macOS SDK, and any remaining libraries in the SDK, except where deprecated, should be considered supported API.Īpple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = "eskimo" + "1" + Hey, we finally managed to remove the kernel’s MAC framework headers, and thus resolve the issue described in QA1574. This is exactly what happened with OpenSSL. usr/include/ without properly considering the long-term binary compatibility impact of that decision. Most of the problems here stem from the distant past, in an era before the advent of formal SDKs, where folks used the libraries as they appeared in /usr/include/ and For example, it makes no sense at all to ship with your own copy of libxml2. While there are some exceptions - more on this below - there are tonnes of such libraries in the macOS SDK that are fully supported. In general, you should feel free to use libraries (regardless of whether they originated with open source) whose headers and stub libraries appear in the macOS SDK. Apple builds these libraries for its own use only. ![]() But that really isn't reliable, as you have discovered. It is tempting to just link to the included open-source libraries that are included with macOS. That way, I know it always works and always has a stable interface. ![]() But if I have some 3rd party library or code that wants to link directly to an underlying dynamic library, I will build and include that library in my app and make a number of other changes to the project to ensure I include and link against my library. Now, if I need an Apple framework, I'll link to the framework. I have been burned numerous times when linking directly to libraries. ![]() Apple expects developers to only link against its published APIs. When I look at with "strings", there is a comment about "Clients should not load the unversioned libcrypto dylib as it does not have a stalbe ABI". But on Catalina, /usr/lib/libcrypto.dylib is some sort of small stub or wrapper library. On Mojave, /usr/lib/libcrypto.dylib is a symbolic link to /usr/lib/libcrypto.35.dylib. ![]() You can build libcrypto from source and include that in your product.Īpple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = "eskimo" + "1" + don't think you are using the deprecated library. IMO, most open source libraries would benefit from having a crypto abstraction layer, because crypto APIs vary wildly across platforms and it’s generally best to use the platform-specific API. You can tweak that library to use an Apple API directly. If you’re not using libcrypto directly, but instead are using some other library (like OpenSSL) that depends on libcrypto, you have two choices: If you post details about what you need, I can point you in the right direction. If you’re using libcrypto in your own code for basic cryptographic operations, rewrite that code to use one of Apple’s crypto APIs. Watch WWDC 2011 Session 212 Next-Generation Cryptographic Services for a full explanation as to why.Īs to how you should proceed, that depends on your goals: Those libraries were deprecated back in the 10.7 days. Are you trying to use the OpenSSL libraries built in to macOS? If so, that’s not something we support. ![]()
0 Comments
Leave a Reply. |