No callback after sqlite3_key when using CocoaPods


#9

Which inspector are you referring to, @gerald?

In Xcode, if you type ⌘ 8 the Report navigator should display the most recent Build and Debug logs. Select the build log and look for the Link step for the application target. If there are duplicate symbol issues warnings will appear there where mine is currently showing green (success) for an app I’m working on:

You might also see such warnings under and dependency targets, which would show nearer the top of the Build log.


#10

I was referring to the Xcode issue navigator (⌘4) and the report navigator (⌘8), both do not warn me about any duplicate symbols. Moreover, the link step seems to succeed for me as well.
I do get a lot of warnings about ambiguous expansions and more, but that shouldn’t obstruct the call to sqlite3_key…right?

I’ve added 2 screenshots; 1 with a subset of all the warnings and 1 with the link success (I’ve merged the screenshots in 1 image since I’m unable to upload more then 1 image).


#11

@gerald It’s been a while since I was looking into the issue previously, but IIRC, the problem is that a third party pod would be linked with the system SQLite. Your application could be using SQLCipher proper, and would not have duplicate symbol warnings. However, the end state of the build would result in the deadlock. Can you go through every pod you are using and make sure there are no declared dependencies on sqlite?


#12

@sjlombardo; I will do that, thanks for the suggestion.

I’m on a vacation now, so will get back to the topic in ~1 month.


#13

Hi @sjlombardo,

How do I know for sure if a pod is using SQLit or not?
The pods I’m using right now are:

  • ‘UrbanAirship-iOS-SDK’
  • ‘Google/Analytics’
  • ‘TBXML’

and of course:

  • ‘SQLCipher’

But I assume, excluding ‘SQLCihper’ none of these should use sqlite, right?


#14

@gerald you basically need to look at all the dependencies in each source podspec. In this case, you can see that sqlite3 is a library dependency for both UrbanAirship-iOS-SDK and GoogleAnalytics, :

https://github.com/CocoaPods/Specs/blob/master/Specs/UrbanAirship-iOS-SDK/7.2.2/UrbanAirship-iOS-SDK.podspec.json

https://github.com/CocoaPods/Specs/blob/master/Specs/GoogleAnalytics/3.14.0/GoogleAnalytics.podspec.json

These will cause the system sqlite3 to be linked, causing the problem. You should try to remove UrbanAirship and GoogleAnalytics temporarily to verify the problem is resolved if they are not included.


#15

Hi, sjlombardo and gerald! I have same problem with SQLCipher + YandexMobileMetrica . Without dependency ‘YandexMobileMetrica’ everything works well.

How can I resolve this conflict?


#16

@nullproduction Unfortunately there is not an easy fix in this case. I believe you might need to create local podspecs for any pods that declare a dependency like that, and then modify them to remove the sqlite dependency.


#17

@sjlombardo
(Sorry for the late reply)

Removing GoogleAnalytics and Urban Airship is sadly quite a hassle for me (they’re both quite strongly interwoven in my app), but based on @nullproduction’s answer; I think it would work if I removed the pods.

Still, you said there is no easy fix; modifying the pods locally is quite troublesome. Moreover, removing sqlite3 makes UrbanAirship unusable (the pod won’t build).

Right now I’ve (sort of) given up on creating my own private pod, I just can’t seem to get it to work. But sadly I now get this problem with Xcode 8 and iOS 10 as well. So back to square one…


#18

@gerald Thanks for getting back to me. We’ve been looking into this further. Can you please provide the following information:

  1. From your XCode Target Build Settings, what is the resolved value for your Other Linker Flags setting
  2. What version of CocoaPods you are running (pod --version)
  3. What version of the SQLCipher pod are you using (i.e. from Podfile)
  4. What order did you install the pods? i.e. was Urban Airship installed before SQLCipher, or visa versa?

#19

I’ve no actual build anymore with the setup in my OP. Since I couldn’t get the pod to work, I reverted back to manually adding the library. But I’ll try to answer the questions:

  1. The resolved Other Linker Flags right now is:

    $(inherited) -ObjC -l"GoogleAnalytics" -l"c++" -l"sqlite3" -l"stdc++" -l"z" -framework "AdSupport" -framework "AddressBook" -framework "AirshipKit" -framework "AssetsLibrary" -framework "CoreData" -framework "CoreFoundation" -framework "CoreGraphics" -framework "CoreLocation" -framework "CoreMotion" -framework "FirebaseAnalytics" -framework "FirebaseInstanceID" -framework "GGLAnalytics" -framework "GGLCore" -framework "GoogleInterchangeUtilities" -framework "GoogleSymbolUtilities" -framework "GoogleUtilities" -framework "MessageUI" -framework "SSZipArchive" -framework "SafariServices" -framework "StoreKit" -framework "SystemConfiguration" -framework "TBXML"

Hence the missing SQLCipher pod because I reverted my setup, but with that one added the resolved flags would probably include something with SQLCipher as well (i.e. -framework "SQLCipher").

  1. CocoaPods version 1.0.1
  2. I’m not using it right now, but I was using the most recent version (meaning I didn’t specify a specific version in my Podfile)
  3. SQLCipher was installed last

Hope this can help you and others somewhat.


#20

Hello @gerald

Can you provide some details about how you are manually adding the sqlcipher library to make this work?

We’re trying to track down inconsistencies with how sqlite3 is linked when using SQLCipher via pod as well. If you happen to add back the SQLCipher pod in the future, can you capture the resolved Other Linker Flags and update this post?


#21

Hello @gerald, @nullproduction - if you’re still available to test a configuration, could you please try the following:

  1. Open up the project Build Settings (i.e. the global project settings, not the target)
  2. Locate the Other Linker Flags settings and add the value -framework SQLCipher
  3. Navigate down to the Target Build Settings, and verify that the resolved target-level Other Linker Flags shows the -framework SQLCipher first.
  4. Clean the Project, and rebuild

Please let us know the resulting behavior.


#22

Hello @sjlombardo .
Thank you for the response.
I tried it, and it works fine!
Can you add flag “-framework SQLCipher” in podspec(cocapods)?


#23

Hello @nullproduction The podspec is already resulting in the inclusion of -framework SQLCipher, however, because of your other dependencies the standard sqlite3 library is being linked first. The manual project level change forces SQLCipher up front. To be frank, this isn’t really a supported scenario, and using this approach is a risk. There could be other undefined behavior. Here is a link to some guidance we just published about SQLCipher with XCode 8 and iOS 10, for reference.


#24

Thanks for the suggestion, I’ll try it ASAP (need to re-configure my project). Afterwards I’ll get back to you with the results.

Also @nullproduction; good to hear it’s working with you, gives me hope!


#25

@sjlombardo

It’s working! :tada:

I put SQLCipher first up in the list of pods, but forgot to add the -framework SQLCipher flag before my first run of the project. Funny enough it worked right away. Afterwards I checked my build settings, only to discover that it was already added by Cocoapods :confused:.
I did do an update of Cocoapods (to version 1.1.0 rc.2) beforehand, don’t know if it has anything to do with it though. But whatever the case may be, I’m glad it’s working now.

Thanks for helping @sjlombardo (and everyone else)! I hope others with the same problem find this thread and the solution.


#26

And…I’m back again, seems the problem is back. Everything worked fine until I was finally ready for a release of my app.
I tested my app on an iPhone 5 (and 5s) with iOS 8.4, and it seems to hang on the exact same spot.

But…

Now the app actually crashes with the error:

dyld`dyld_fatal_error:
->  0x1fe9a08c <+0>: trap   
    0x1fe9a090 <+4>: nop    

Any insights?

Edit:

I’ve read the new post about Xcode 8 and iOS 10 and verified that -framework SQLCipher is first up in the list


#27

@gerald I don’t have any other specific suggestions. If you can reproduce this in a standalone reference application we might be able to take another look.


#28

@sjlombardo Ah sorry, I forgot to edit my last reply.

I’ve fixed the problem, it was again the fact that -framework SQLCipher wasn’t first up in the list (as you’ve said in your iOS 10 * Xcode 8 post).

For the sake of others who might have the same problem; please check the CocoaPods-generated xcconfig files. It seems that, even though you specify SQLCipher as the first pod, it won’t be the first flag in the OTHER_LD_FLAGS setting of the generated xcconfig file. This is especially the case if you use multiple schemes (as I do).

And again, please don’t go through the same headache-loops as me; be sure to double check the generated xcconfig files!

@sjlombardo, thanks for taking the time to help me every time.


SQLCipher and iOS 12