Is it safe to consume a C library built with older version of Xcode?

Question

Created Sep ’20

Replies 3

Boosts 0

Views 1.8k

Participants 3

We build and deploy a dynamic framework that contains objective-c code. It consumes a "core" static library that contains C/C++ code. But we only consume it through the C interfaces. We don't have any Objective-C++ that we use to consume any of the C++ interfaces. It's all Objective-C in our framework consuming and linking in a static library through pure C headers.

We are wondering if it is safe to consume the "core" static library if we build it with an older version of Xcode (LLVM). And if so, is it safe even for major version differences of compiler or minor only?

thanks

Answered by DTS Engineer in 630651022

If the library is one you control with an Xcode project, you should configure your build to depend on the static library target so that it's built with the right configuration at each build.

If the library is pre-compiled, the best practice is to recompile all libraries with each major compiler version (as a static library in an XCFramework to correctly handle simulator / device / Mac Catalyst differences). While the library might work as-is, recompiling routinely avoids any major problems as well as highlights any maintenance you need to do, such as replacing deprecated APIs. As an example by the way of history, Xcode 6, addressed an issue regarding the C++ ABI, but which required clients of the binary framework to make some considerations for the library's ABI. You can search the Xcode 6 release notes for "ABI" if you're curious about the details.

Boost

Answer 1

DTS Engineer OP

Apple

Sep ’20

Accepted Answer

If the library is one you control with an Xcode project, you should configure your build to depend on the static library target so that it's built with the right configuration at each build.

If the library is pre-compiled, the best practice is to recompile all libraries with each major compiler version (as a static library in an XCFramework to correctly handle simulator / device / Mac Catalyst differences). While the library might work as-is, recompiling routinely avoids any major problems as well as highlights any maintenance you need to do, such as replacing deprecated APIs. As an example by the way of history, Xcode 6, addressed an issue regarding the C++ ABI, but which required clients of the binary framework to make some considerations for the library's ABI. You can search the Xcode 6 release notes for "ABI" if you're curious about the details.

0

Answer 2

asrg OP

Sep ’20

@edford That is good to know. We've also specifically had issues when using bitcode. When building with different versions of Xcode, the linker has either crashed or errored out until we rebuilt one of the missed libraries with the same version of Xcode. The core static library is all prelinked together into a single static library before it is consumed through the Objective C code. Is this something that we'd may no longer see happen now that the bitcode implementation has had time to settle in or would it still be best to always rebuild and use the same version of Xcode?

0

Answer 3

DTS Engineer OP

Apple

Sep ’20

It depends on the error you're seeing. This might be a version mismatch — bitcode is forward compatible, not backward compatible. For example, if you built the library with Xcode 11.4, and the client of the library is using Xcode 11.1, the compiler in Xcode 11.1 won't be able to handle the library build with Xcode 11.4, and the compiler will produce an error message. If the client were to use a newer Xcode like 11.6, then there would be no error.

If you're seeing some other sort of error, I'll need more details to understand the issues. If you have a demonstration project for the error or lengthy logs showing the problem, then opening a TSI might better facilitate the conversation with large attachments.

0