fmdb
fmdb copied to clipboard
Can't build on Xcode 9.0
Hi !
I can't build FMDB with this pod file line : pod 'FMDB/SQLCipher' with FMDB v. 2.7.2 & SQLCipher v. 3.4.1
The error I get in class FMDatabase.m is :
Implicit declaration of function 'sqlite3_rekey' is invalid in C99
I waited for new version (I was in v. 2.6) and still have the same problem.
FYI, it works with Xcode 8.3.3.
Thanks
This issue can be resolved by modifying the import statement for sqlite3.h in the FMDatabase.m at line 8 from the following
#import <SQLCipher/sqlite3.h>
to this
#import <sqlite3.h>
@andrewcl change #import <sqlite3.h>
to#import <SQLCipher/sqlite3.h>
works for me. Thanks.
If you are using a static library for SQLCipher, there will be no <SQLCipher/sqlite3.h>
. In this case you can declare the missing functions by adding the following to FMDatabase.m
:
#if defined(SQLITE_HAS_CODEC)
SQLITE_API int sqlite3_key(sqlite3 *db, const void *pKey, int nKey);
SQLITE_API int sqlite3_rekey(sqlite3 *db, const void *pKey, int nKey);
#endif
Or you can use this fork temporarily until the issue is fixed:
pod 'FMDB', :git => '[email protected]:BayanLabs/fmdb.git', :commit => 'eea8a334'
@ccgus is there an outlook on #594 merging and making it into a release to resolve this issue? Or an outlook or plan for some alternative fix?
These problems sound a lot like what is described in this advisory on using SQLCipher in Xcode 9: https://discuss.zetetic.net/t/important-advisory-sqlcipher-with-xcode-9-and-new-sdks/
It may be the case that by following the guidance there no adjustment to FMDB is necessary (e.g. #import <sqlite3.h>
may work fine), depending on your individual circumstances and how you link against SQLCipher. For instance, if you are using CocoaPods and use_frameworks!
you'll want to use a post install hook to make the generated sqlite3.h
visible (see link). Hope that helps!
I don't think adding specific ifdefs to FMDB for SQLCipher is a good idea. You can define SQLITE_HAS_CODEC, and the sqlite headers will have sqlite3_key and sqlite3_rekey enabled.
We already have SQLITE_HAS_CODEC
defined and we get precisely the error mentioned in that advisory. In fact, that's the error preventing us from pushing up the latest version to Cocoapods.
Hi @robertmryan The error likely has nothing to do with SQLITE_HAS_CODEC. Rather, when use_frameworks! is enabled it Cocoapods is not properly creating header links under Pods/Headers. This prevents Xcode from referencing the proper sqlite3.h file. You can verify this behavior by examining the Pods directory after installation. The advisory that @billymeltdown linked has a workaround using a post_install hook to correctly link the headers. We are open to other ideas/solutions. Ultimately if the right header can be found by Xcode everything works just fine, so this isn't really a problem with SQLCipher per se. Let us know what you think.
@sjlombardo - Yep, I wasn’t clear. That was my point, namely, as I read that advisory, SQLITE_HAS_CODEC
(which we’re already doing) is necessary, but not sufficient. We will likely have to do some variation of the path adjustments outlined in that advisory, too. I’ll play around with it.
@billymeltdown thanks for the input, we tried the post install hook but the problem is that we can't deploy new versions of our library (which depends on FMDB and SQLCipher) using pod trunk push
, because the linting process looks at the podspec, not the podfile.
When we run pod spec lint
:
- ERROR | [iOS] [CDTDatastore/SQLCipher] xcodebuild: Returned an unsuccessful exit code. You can use `--verbose` for more information.
...
- ERROR | [iOS] [CDTDatastore/SQLCipher] xcodebuild: FMDB/src/fmdb/FMDatabase.m:375:14: error: implicit declaration of function 'sqlite3_rekey' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
...
- ERROR | [iOS] [CDTDatastore/SQLCipher] xcodebuild: FMDB/src/fmdb/FMDatabase.m:401:14: error: implicit declaration of function 'sqlite3_key' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
...
Analyzed 1 podspec.
[!] The spec did not pass validation, due to 3 errors.
I also tried using prepare_command
to make the symlink in the podspec but didn't have much success. More importantly this option seems break local linting as switching it on seems to force pod spec lint
to download the spec from github, which doesn't work with our release process.
To me the symlink "fix" seems like a bit of a hack but at the moment I'd accept any decent solution which allows us to publish a new spec.
Hi @tomblench thanks for the clarification, that is definitely unfortunate and problematic. Have you considered raising an issue to the Cocoapods team? There was a previous issue raised about this behavior before which garnered many comments, but was ultimately auto-closed without an update (https://github.com/CocoaPods/CocoaPods/issues/4605). I just can't think of any way that we could "fix" this in the SQLCipher pod itself. The header is being properly generated and packaged, it's just not placed where Xcode can find it by Cocoapods.
@sjlombardo thanks for your input, I have raised https://github.com/CocoaPods/CocoaPods/issues/7232 which shows a minimal podspec demonstrating the issue.
(https://github.com/ccgus/fmdb/commit/18152d3ea819d5a65a682ad9f3b22dbbb3c2423e) was merged in which I'm hopeful will resolve this issue
@Boobby69 @andrewcl
Does the latest adjustment merged in work out of the box for you guys now?
@tomblench
Does this allow your lib that depends on FMDB/SQLCipher to pass pod spec lint?