Closed brianpartridge closed 5 years ago
Looks like this is the root cause of #54 too
Specifically, it results in -lcrypto -lssl in the generated build settings for targets that should not be linking the pod.
Does it links without -lcrypto
-lssl
? It may be from the "Find Implicit Dependencies", however does it works withut implicit dependencies too?
The trouble occurs when you have a configuration like this:
target 'MyApp' do
use_frameworks!
pod 'OpenSSL-Univeral'
target 'MyAppTests' do
inherit! :search_paths
end
MyAppTests
gets dynamically linked into MyApp
when running tests. If MyAppTests
linked in libcrypto and libssl then there would be duplicate symbols at runtime. CocoaPods provides a mechanism to work around this with inherit! :search_paths
, so MyAppTests
can find the OpenSSL headers if it needs them, but it wont link against the libraries.
Internally CocoaPods builds up a list of libraries to link from 3 sources in the podspec(s) vendored_frameworks
, vendored_libraries
and libraries
. The first 2 it knows to filter out of nested targets using inherit! :search_paths
. However, it does not filter out the contents of libraries
because the content is assumed to by system dylibs. By adding crypto and ssl to the libraries
list, even though they aren't system dylibs they get added to the linker flags, which causes a failure when trying to link them.
This line should be removed: https://github.com/krzyzanowskim/OpenSSL/blob/328cdcbe2192f19f539181964e9f4a2f6655505d/OpenSSL-Universal.podspec#L41
The
libraries
command is for system libraries, not for vendored libraries. From the docs: "A list of system libraries that the user’s target (application) needs to link against."Specifically, it results in
-lcrypto -lssl
in the generated build settings for targets that should not be linking the pod. It's subtle, it only manifested as an issue for us when we had a test target nested in the app target in our Podfile.Removing this line makes everything work when I used a local fork of this podspec.