You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Remove arm64e slice; return dyn linking for CocoaPods (#18)
* Automatically enable Apple Silicon support
Since Xcode 12.2 (stable) is out, Apple Silicon support can be enabled
automatically there. Check the version of the command-line tools and
set APPLE_SILICON_SUPPORT value automatically if possible.
After a while, once Xcode 12.0.1 and earlier are not longer supported
and widely used, this variable can be removed completely. Right now
it won't be really necessary to set it explicitly, unless you want
something strange.
* Revert "Use static frameworks for CocoaPods (#13)"
This reverts commit d21e3b7.
We can't just migrate CLOpenSSL to static frameworks as that requires
all upstream dependencies to migrate to static frameworks too, and
that breaks builds left, right, and center.
Instead, we have figured out what has been breaking dynamic linkage
with CocoaPods, and now we're coming back to using dynamic linkage.
If static versions of CLOpenSSL are published, they will be published
in a separate podspec.
* Drop arm64e to work around CocoaPods issues
arm64e builds are included to test the pointer authentication feature of
iOS devices. We have to include it in binary CLOpenSSL builds so that
upstream users of CLOpenSSL might enable it themselves for testing.
However, inclusion of this architecture slice causes issues with
CocoaPods handling of vendored binary frameworks. arm64e builds include
a certain linker command -- LC_DYLD_CHAINED_FIXUPS (0x80000034) -- which
confuses CocoaPods' detector of dynamic binaries, making it believe that
the vendored framework in a static one, not dynamic. This in turn causes
issues when using CLOpenSSL as CocoaPods refuses to link "static" binary
without "static_framework = true".
This is a know issue in CocoaPods, stemming from the missing features in
Homebrew's Mach-O parser [1][2].
[1]: Homebrew/brew#7857
[2]: Homebrew/ruby-macho#261
There is nothing we can do about it right now, other than disable
"arm64e" builds for the time being. This does not affect deployment to
App Store, but will break dependencies of CLOpenSSL which expect this
architecture to be present. The dependencies will have to disable arm64e
in their projects, if they have it explicitly enabled. (Considering that
CocoaPods packaging of CLOpenSSL was never in good shape, the actual
impact of this change should be minimal.)
* Set install name during linkage
Instead of using "install_name_tool" to fix the LC_ID_DYLIB value of the
dylib, pass the "-install_name" parameter to the linker directly. This
doesn't change anything in the resulting binary but looks a bit cleaner.
* Use ABI-correct install name on macOS
On macOS -- contrary to iOS, watchOS, and tvOS -- it is customary for
frameworks to provide additional internal structure which helps with
binary compatibility. For example, on iOS/watchOS/tvOS a framework
typically has flat structure:
openssl.framework
├── Headers
├── Info.plist
└── openssl
while on macOS it's a bit more involved:
frameworks/MacOSX/openssl.framework
├── Headers -> Versions/Current/Headers
├── Resources -> Versions/Current/Resources
├── Versions
│ ├── A
│ └── Current -> A
└── openssl -> Versions/Current/openssl
Note that the top-level files are actually symlinks to the
"Versions/Current" which in turn is a symlink to the "A" version,
which actually contains the framework content:
openssl.framework/Versions/A
├── Headers
├── Resources
│ └── Info.plist
└── openssl
Currently, the 'install name' of all "openssl" binaries is set to
"@rpath/openssl.framework/openssl", which makes the linked binaries
remember and use this path when loading OpenSSL. On macOS this will
involve two additional symlink resolutions. Another thing here is that
if we will need to introduce a different version of OpenSSL framework
on macOS, existing applications will still look up the current one,
instead of using the A version that they should.
Update the install name computation to use
@rpath/openssl.framework/openssl
for iOS, watchOS, tvOS while using more explicit
@rpath/openssl.framework/Versions/A/openssl
for macOS.
This is how Apple's system frameworks do it. Though they have a pressing
issue of supporting multiple possible ABIs and it's not that important
in our case, you never know when this turns out to be necessary or
whether some weird tool might choke on the symlinks.
0 commit comments