-
Notifications
You must be signed in to change notification settings - Fork 224
CommonCrypto modulemap doesn't work with Swift framework #102
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@srozner Can you please share with me the error you are seeing and some steps to reproduce? |
Hopefully not too long :) but this is my understanding of old CryptoSwift use and the issue with CommonCrypto modulemap use. OLD Project "MySDK" included JSONWebToken pod in Podfile, which also included CryptoSwift as a dependency. target 'MySDK' do So when building our app "MyApp", I directly include the "MySDK" framework built locally and must also include the JSONWebToken pod in Podfile (can't be embedded in MySDK as a Swift framework). This again adds CryptoSwift as a pod dependency. target 'MyApp' do In this case, CryptoSwift is dynamically linked to MySDK "Framework" and then actually included/embedded in MyApp with the pods (building an app and not a framework). NEW For "MySDK" the Podfile is the same. Instead of including and dynamically linking to the CryptoSwift framework, the CommonCrypto modulemap seems to directly embed a mapping into MySDK framework. Everything compile fine here. For "MyApp" the Podfile is again the same. I must still include JSONWebToken for the app to include this framework dynamically linked to MySDK framework. Unfortunately the CommonCrypto modulemap in JSONWebToken seems to try directly embedding a mapping into MyApp again. The modulemap embedded in MySDK framework and MyApp, via including pod JSONWebToken in both project, causes a "Redefinition of module 'CommonCrypto'" when building MyApp. ====================
|
Okay, so the problem is when you use JSONWebToken alongside another dependency which also contains a module map for CommonCrypto? Then at compile time they are not built isolated and thus you are hitting a duplicate module map for CommonCrypto error. Do I understand correctly? I'm having a little bit of a difficulty the part about CryptoSwift, I'm looking at the CryptoSwift package that you mention and I am not seeing any dependencies in it nor a module map file in the pod spec (https://github.com/krzyzanowskim/CryptoSwift/blob/master/CryptoSwift.podspec). Perhaps you are using a different version or this is unrelated to the problem? |
I think you understand it correctly. My issue is I am including JSONWebToken through an intermediate Swift Framework of my own MySDK. So anyone using my framework (MySDK) would encounter this, as when I build MyApp which links to MySDK. JSONWebToken switched from using CryptoSwift (which was built as a Swift Framework pod and dynamically linked) to using Apple's CommonCrypto (included as an embedded module mapping) in v2.2.0 I believe. It appears CryptoSwift does not compile in Xcode 9 due to obsolete numeric type use. CryptoSwift worked as it was dynamically linked in MySDK and MyApp, whereas the CommonCrypto module as defined is embedded in the intermediate MySDK and tries to again be embedded in MyApp. I mentioned the previous use of CryptoSwift as it was working due to it inclusion as a separate, dynamically linked Swift Framework. Believe me, it took a while to wrap my head around this. It is the fact I am using JSONWebToken in my own "intermediary" Swift Framework that causes this. Project 1: MySDK (Swift Framework)
Project 2: MyApp (actual app)
Including the JSONWebToken pod in an intermediary Swift Framework (MySDK), which then requires an app to include both the intermediate (MySDK) and the JSONWebToken pod to build, causes the trouble. I'll answer anything you need to get your head wrapped around this problem. |
I really, really appreciate how quick you have responded. I look forward to your eventual response, and feel free to ask for more info. |
FOLLOW UP: attempts to fix the method CommonCrypto is included have seemed futile. If you use nested dynamic framework pods using a CommonCrypto (or other?) module map, you will end up with a duplicate module map link error with no easy fix. My case is: APP with Dynamic Framework Pods
ISSUE: The error stems from the JSONWebToken Dynamic library in the SDK exposing the CommonCrypto module map, and the JSONWebToken in the APP also exposing a duplicate module map. The conflict fails to resolve and aborts the link. WORK AROUND: My fix was to compile my SDK with Static Library Pods, but remain building my SDK as a Dynamic Framework and using Dynamic Framework Pods in the APP. THIS REQUIRES LATER COCOAPODS AND MAYBE XCODE 9 TO BUILD STATIC SWIFT LIBRARIES. JSONWebTokens is built as a Static Library and appears NOT to expose the CommonCrypto module map. My SDK is still build as a Dynamic Framework to include resources. None of my SDK pods have resources and work fine as Static Libraries. My APP builds its pods as Dynamic Frameworks and includes my SDK as such. ODDITY: The APP builds JSONWebTokens as a Dynamic Framework! All the APP pods are built this way. The SDK does NOT embed the JSONWebTokens Static Library (painful to even try), so the APP must still build it. The APP's JSONWebTokens Dynamic Framework pods DOES satisfy the link dependency of the SDK's JSONWebTokens Static Library. The APP is embedding the dynamic framework, so it makes sense the linker can resolve. It just feels dirty, but this is the only way I have been able to get a nested framework use of a CommonCrypto module map to work. APP with Dynamic Framework Pods
|
Just an FYI that in Xcode 10 beta the JSONWebToken pod now fails to build with this error. You can reproduce by creating an empty project in Xcode 10 beta, adding the JSONWebToken pod, and building.
|
and do you have a solution for this in Xcode 10 beta? |
@egv deleting the directory |
@mpvosseller thanks! Just figured that out myself half an hour ago. Now I will check if breaks build in Xcode 9.4 |
I would guess Apple has "finally" exposed CommonCrypto to Swift natively. It was only Obj-C in Xcode 9, which required that module you deleted. That wrapper module caused my issue, which a huge number of people were caught out on (Stack Overflow has numerous threads). If Apple now exposes CommonCrypto to Swift natively, it makes sense that the CommonCrypto wrapper would cause a duplicate mapping. Removing the CommonCrypto folder would then fix both the Xcode 10 build and my own issue. |
(avoids collision with system framework exposed in iOS 12) re kylef#102
I've been trying to resolve this by using CCommonCrypto name instead of just CommonCrypto (which clashes with Apple's name in iOS 12). Similar to what's done in Arcane But I can't seem to get it to work properly. :( |
I’ve made a fork of this repo and published a release with several changes, including a fix in Package.swift for this issue. Importantly it requires Swift 4.1, but it should be a useful fix for people who need Xcode 10 support now without breaking Xcode 9.3/9.4 support. (Just be sure to run If you want to fork the repo and make the fix yourself, you can see my fix in this commit. Edit: I should clarify that this may not fix the topic of this GitHub issue, but it fixes what others have been going through in the comments. |
- remove CommonCrypto file(s) from the file system - added new aggregate target which conditionally builds CommonCrypto - link to that target in all 4 of our targets Per: https://stackoverflow.com/a/42852743/108859 re kylef#102
Now just need to figure out the incantation for the podspec file |
- no additional target - run script before Compile Sources re kylef#102
@kylef, I'm not sure what's the idea with your master branch, as it seems you removed the project and podspec. In case anyone needs to use this as CocoaPod, take a look at my podspec branch. This compiles just fine in both iOS 11 and iOS 12, standalone and as pod. |
Hi @radianttap - this might be an incredibly stupid question, but how to I use your fork with my Podfile? I'm familiar with adding sources to the Podfile (e.g. Apologies if I'm missing something really obvious here, and thanks for your hard work! |
@SamMcNeilly Like this:
|
You can also remove CommonCrypto directory from Pods by adding this at the end of your Podfile:
You should uninstall JSONWebToken pod at first and then install again with this script in your Podfile. |
THERE IS AN EASY FIX!! **See https://stackoverflow.com/questions/25248598/importing-commoncrypto-in-a-swift-framework section: Xcode 10 now ships with a CommonCrypto module map making this workaround unnecessary.** |
I am using JSONWebToken within my own Swift framework. This does not work with the standard modulemap CommonCrypto solution. I found this link that pulls together and describes the issues with including CommonCrypto, particularly within a Swift Framework.
http://ioscake.com/importing-commoncrypto-in-a-swift-framework.html
The easiest solution may be to include this approach specifically targeted at Cocoapods:
Or it may be used as a basis for a solution you trust.
The text was updated successfully, but these errors were encountered: