Fixes for Windows mswin & sqlcipher

[MSP-Greg]

Changing the vcpkg input from "sqlcipher" to "sqlite3 sqlcipher" seems to allow compile & test to pass? Not.sure.

Also, ci log for 'bundle exec rake test' shows:

info: sqlite3-ruby version: 1.5.0.rc1/1.5.0.rc1
info: sqlite3 version: 3.39.1/3.37.2
info: sqlcipher?: true
info: threadsafe?: true

Not sure what 'sqlite3 version: 3.39.1/3.37.2' is about?

Lastly, CI is ran on Windows 'mingw', which is a Ruby head build, 'ucrt' is also available... Didn't change.

[flavorjones]

Hey, @MSP-Greg - thank you for putting this together!

I think the output "3.39.1/3.37.2" is telling us that this isn't working as expected -- I think it's compiling against sqlite3 and dynamically loading sqlcipher (or vice-versa). This is pointing at a lack of both compile-time and run-time assertions that we're pulling in the expected flavor of db library, a shortcoming that dates back to the original PR, #232.

I'm going to add a commit onto this PR that will introduce some checking and I think that will confirm my suspicions by failing CI.

[MSP-Greg]

@flavorjones

Need.more.coffee.

Thank you!

Last night I looked here to double check whether it was running CI against mswin. I'm working on some custom Ruby builds, and wanted to see about extension gems. This morning I'm looking at the code...

I think the output "3.39.1/3.37.2" is telling us that this isn't working as expected

So that's runtime vs compile, correct? Question - if one builds with sqlcipher, can one use it just like 'normal' sqlite3? Or, is it mutually exclusive?

Regardless, I've got vcpkg locally, anything I can check about the sqlcipher install?

[MSP-Greg]

Installed vcpkg sqlcipher locally. Two files sqlcipher/sqlite3.h and sqlcipher/sqlite3ext.h. Haven't installed vcpkg sqlite3 yet.

EDIT:

I've got two vcpkg installs, one using VS 2019 & OpenSSL 1.1.1, and one with VS 2022 & OpenSSL 3.0.x

Installed sqllite3 to one and sqlcipher to the other:

1. pc file exists for sqlite3, no file for sqlcipher.
2. include files for sqlite3 are at root, include files for sqlcipher are in a sqlcipher folder.

Hacked a few files and sqlcipher installed correctly and showed info: sqlite3 version: 3.37.2/3.37.2. Tests passed. Not quite sure how to make the code work with all platforms?

[flavorjones]

I rebased onto master and added checks to extconf.rb and the test suite. Let's see what that tells us before I speculate on the vcpkg packages.

[MSP-Greg]

I came up with a possible solution, not sure about naming, etc. Seems like all CI passes. I rebased a few hours ago, and added a commit. Might be a bit hacky...

Test suites:
https://github.com/MSP-Greg/sqlite3-ruby/actions/runs/2827064397
https://github.com/MSP-Greg/sqlite3-ruby/actions/runs/2827065516

sqlcipher log:
https://github.com/MSP-Greg/sqlite3-ruby/runs/7751455763?check_suite_focus=true#step:6:59

Seems like the main issue is that vcpkg sqlcipher is the only platform with the two header files in an sqlcipher folder?

[flavorjones]

Your solution seems reasonable to me, though I'm realizing now there are a few problems that are interacting here:

• the vcpkg header path issue (which your commit fixes!)
• macos seems to have a problem with compiled version vs loaded version as well, which fails the test I just introduced in this PR, see https://github.com/sparklemotion/sqlite3-ruby/runs/7751685748?check_suite_focus=true#step:7:10 for an example
• the library seen at extconf time is not sqlcipher as expected on mswin 2022, see https://github.com/sparklemotion/sqlite3-ruby/runs/7751684731?check_suite_focus=true for an example

I'm going to add your commit to this PR to see what happens.

[MSP-Greg]

I'm going to add your commit to this PR to see what happens.

Sorry, forgot. The vcpkg input needs to be vcpkg: "sqlcipher", then it should work...

[flavorjones]

Right, thanks. Fixed!

[MSP-Greg]

1. libname is called a few times, should that value be saved? Maybe lib_name, @lib_name, or something?

2. extconf.rb - wondering about the statement elsif find_header("#{libname}/sqlite3.h"). maybe should be:
   elsif @lib_name == 'sqlcipher' && find_header("sqlcipher/sqlite3.h")?

Trying to tighten what runs it, as the only problem is mswin & sqlcipher?

[flavorjones]

🤔 I'm going to remove my attempt in the extconf to determine whether the libraries is "really sqlcipher", because the sqlcipher library doesn't appear to present that information in a stable, predictable way.

That will get mswin green, I think. I'm still worried about macos versioning being strange, but I can handle that in a different PR.

[flavorjones]

@MSP-Greg I'm not too worried about making this code perfect -- sqlcipher is an edge case that I don't think many people opt into, and if they do they're responsible for bringing their own (and using the config flags if necessary).

If you'd like to clean it up, I'd be happy to take it, but I'm a bit under water today and won't get to it.

[flavorjones]

I think this can be merged! @MSP-Greg thanks again for digging in on this. Are you OK with the changeset as-is?

[MSP-Greg]

Are you OK with the changeset as-is?

Yes. Maybe later we can look at reducing the calls to some methods. Thanks for the quick review, etc...

JFYI, SQLCipher has a new release (4.5.2, uses SQLite 3.39.2), opened a PR in vcpkg to update it. Haven't checked MSYS2 yet.