Hi folks,
Spent a few days attempting to get the iOS Linking order configured as explained in this post so that SQLCipher is used in a pod dependency instead of SQLite. Sadly no success…
I have a repository demonstrating the issue here: GitHub - Chuckv01/adobe-sqlcipher-issue-reproduction: Reproduction of the SQLCipher / Adobe Mobile SDK Issue
Could someone tell me where I am going wrong with this? Any assistance would be greatly appreciated!
Hey @sjlombardo - would really appreciate your feedback on this.
Crazy theory here… and I’m not entirely sure… but it seems like if SQLite3 is being referenced from a 3rd party pod dependency written in swift (like this) the linker workaround you published way back in 2016 does not work.
Another way to put it is the linker order modification is only effective when the other pod is implemented in Objective-C? Am I way off here?
@mmoore I see you also have past experience with this issue - do you have any thoughts on this?
Seems like if SQLite3 is being referenced from a 3rd party pod dependency written in swift (like this ) the linker workaround published back in 2016 does not work.
Hi @Chuckv01
Thanks for your interest in SQLCipher and for posting to the discussion forum.
This import of the SQLite3 module in the AEPServices framework SQLiteWrapper class is what’s causing the issue.
Yes, the workaround posted is really only relevant for Pods which explicitly declare a dependency in the sqlite3 library which would cause -lsqlite3 to be in the other linker flags of the consuming project. When that occurs, you can adjust the other linker flags to put -framework SQLCipher first in the other linker flags list to ensure that it’s linked first (prior to vanilla SQLite).
We’re planning on making an adjustment in the next version of SQLCipher which should resolve these types of conflicts where a Swift framework imports SQLite3. In the meant time, you can manually adjust your consuming project using these steps:
_SQLITE3_H_=1 _FTS5_H=1 _SQLITE3RTREE_H_=1As mentioned in the Advisory post you linked, you should include a Runtime SQLCipher check to ensure that SQLCipher is properly used (PRAGMA cipher_version query).
Let us know if that resolves the redefinition errors for you and allows you to utilize SQLCipher + AEP pods in conjunction in your consuming project.
@mmoore Brilliant. I can confirm that the preprocessor macros did fix the issue. Diff of the change here. Thank you!
Glad that worked for you. It looks like you may have deleted the previous preprocessor macro definitions in your diff. You’ll want to leave any previous ones in place (i.e. DEBUG=1 for the debug variant and $(inherited)) and add the additional ones I mentioned in my previous post to that list.
@mmoore Good eyes - had the same thought shortly after I pushed - updated diff here
