That's strange. It looks like you have installed SQLCipher but not OpenSSL even though that's a dependency of SQLCipher. Have you installed SQLCipher via your package manager or have you compiled it yourself? And do you have the libssl1.0.0 package installed? And what about the libssl-dev package?

You could also try editing the CMakeLists.txt file in our source code, going to line 381 (the target_link_libraries bit) and change it to this:

target_link_libraries(${PROJECT_NAME}
    qhexedit
    qcustomplot
    ${LPTHREAD}
    ${QT_LIBS}
    ${WIN32_STATIC_LINK}
    ${LIBSQLITE}
    ${ADDITIONAL_LIBS}
    ssl
    crypto
)

Not sure if that helps though.

I do have OpenSSL 1.0.2g-1ubuntu4.13 installed, a slightly newer version than the build is insisting on.
The system doesn't allow me to install 1.0.0 alongside, I made an attempt.

I'll try your target link hack, cheers.

I managed to build with the CMakeLists.txt hack.
Now upon start I get

./sqlitebrowser: /*****/anaconda3/lib/libcrypto.so.1.0.0: no version information available (required by /usr/lib/x86_64-linux-gnu/libsqlcipher.so.0)

but then it loads.

In About... why is my version labelled SQLCipher Version 3.8.6? What is my SQLite version?
Thanks in advance.

To add encrypted databases support, SQLCipher comes with its own modified version of SQLite. You can't build sqlitebrowser with both SQLCipher and SQLite. It is either this or that.

SQLCipher comes with whatever version of SQLite they decide to add. I think they wait a little bit before updating their SQLite version. So it is usually not the latest.

To find out your SQLite version, try to run SELECT sqlite_version(); in Execute SQL tab.

Edit: It seems like they have modified sqlite_version(), it is returning SQLCipher version and not SQLite.

I understand, thank you.
Indeed once I built it with SQLCipher disabled the SQLite version got revealed, 3.11.0.

I know this is slightly off topic to this ticket, but can you tell me if it is possible to build into the tool a different SQLite version? Is that configurable? (I am aware that certain UI elements may not work as expected as result).

In theory, the building process will use which ever version of the SQLite development headers it finds first.

So, if you install a custom version of SQLite somewhere (eg /opt/custom_stuff/sqlite) you should be able to edit the CMakeLists.txt file to use that path when it goes looking. It might take a bit of mucking around to get it 100%, but it should be do-able. 😄

Out of curiosity, what's the end goal you're wanting to achieve?

Just thinking that depending on what you're attempting we might have suggestions on better ways to get it done. No guarantees of course. 😉

Thank you @justinclift .

My main objective is to be able to align the Browser to whatever version I am using in development. For dev this is very often the (near) latest SQLite version, right now in Python I am using 3.24.0.
Since the syntax is changing often in SQLite, I'd like to have that consistency between the Browser and my sqlite3 dev environment.

Of course one option is to downgrade dev to the Browser's built in SQLite version, but I'd rather have it the other way around. :-)

Yep, that makes sense.

For your dev stuff, that sounds like you have an install of SQLite 3.24.x someone on your system already (manual install?). That makes me think you should be able to point the CMakeLists.txt file at that, which would then build DB4S using the same SQLite as your dev stuff.

In Python I am using virtual environments, and the sqlite3 Python package (my case 3.24.0) is installed from binaries. I found however the 3.24.0 header files on my file system and pointed CMakeLists.txt's INCLUDE to it. Once I rebuilt however, it didn't get picked up.

I suspect the header redirection is not sufficient and the (static?) libraries are still being picked up from my system (old version).

I might take some time updating the SQLite library compiled from source and see if I nail it.
Thanks anyway for your help.

PS: ssl and crypto is still needed in my CMakeLists.txt, otherwise the binary doesn't link. Not sure that needs to be looked at?

Hmmm, from memory the ssl and crypto bits are only used when compiling SQLCipher.

One thing worth trying, is going through the CMakeLists.txt file and outright nuking all of the things that refer to SQLCipher. Make sure there's no way SQLCipher could be getting picked up accidentally, and that should solve that ssl/crypto bit. Make sure you backup your CMakeLists.txt first of course, just in case. 😄

@karim We asked the SQLCipher devs a while ago to add something which gives us the SQLite version. Not sure if they did though.

@tilusnet Here is what you can do: download and compile SQLite in whatever version you want it to be included. Then open the CMakeLists.txt file again and edit to point to the directory of your SQLite version. For that you could try to add it around line 322 by changing it from this:

if(EXTRAPATH)
	find_library(LIBSQLITE ${LIBSQLITE_NAME} HINTS /usr/local/lib /usr/local/opt/sqlite/lib)
	set(ADDITIONAL_INCLUDE_PATHS /usr/local/include /usr/local/opt/sqlite/include)
else(EXTRAPATH)
	find_library(LIBSQLITE ${LIBSQLITE_NAME})
endif(EXTRAPATH)

to this:

if(EXTRAPATH)
	find_library(LIBSQLITE ${LIBSQLITE_NAME} HINTS /usr/local/lib /usr/local/opt/sqlite/lib)
	set(ADDITIONAL_INCLUDE_PATHS /usr/local/include /usr/local/opt/sqlite/include)
else(EXTRAPATH)
	find_library(LIBSQLITE ${LIBSQLITE_NAME} HINT /path/to/your/compiled/sqlite/lib)
	set(ADDITIONAL_INCLUDE_PATHS /path/to/the/include/file/of/your/sqlite/copy)
endif(EXTRAPATH)

Maybe somebody want to add a proper configuration option out of this and put it into a PR? 😄

We asked the SQLCipher devs a while ago to add something which gives us the SQLite version.

Hmm, I don't think it's happened yet. @developernotes @sjlombardo ?

Hi @justinclift

Catching up on this ticket. There are a couple of different options, depending on whether you are referring to compile time vs. runtime.

Compile time

• SQLCipher version number is stored in a header file here
• SQLite version number is stored in the VERSION file here.

Runtime

• SQLCipher version available via executing: PRAGMA cipher_version;
• SQLCipher crypto provider name available via: PRAGMA cipher_provider;
• SQLCipher crypto provider version information via: PRAGMA cipher_provider_version;
• SQLite version available via executing: SELECT sqlite_version();

Does that address the information you are looking for?

Thanks @developernotes, that looks perfect. We should be able to update our About dialog with the exactly correct info now. 😄

Oh... actually... it seems like SELECT sqlite_version() returns the SQLCipher version, and not the version of SQLite it was based on. @karim, that's what you're seeing yeah?

Hi @justinclift

SELECT sqlite_version(); will return the version of the upstream SQLite version that has been integrated within SQLCipher, not the SQLCipher version which is separate (i.e., PRAGMA cipher_version). Are you seeing something different?

I'm sorry, I was wrong. @developernotes is right, SELECT sqlite_version(); does indeed give SQLite version. I was confused by the version info in the About dialog as it is actually showing SQLite version and not SQLCipher. Also, the fact that both versions are very close (3.x) to each other. 😃

Like @developernotes said, to get SQLCipher you should use PRAGMA cipher_version; instead.

We should change the info in the About dialog to reflect that.

Cool. Sorry for the mix up @developernotes. 😄

@justinclift no worries at all, happy to help!

It's not so easy unfortunately 😦 We can't use the PRAGMAs in the About dialog because you can open the About dialog without opening a database first, but you can't execute a PRAGMA without a database connection. So we're left with the compile time options. And neither the VERSION nor the crypto.h files are available for including. They seem to be only for internal use in SQLCipher and not in their public API which we could use. So the only thing we could do at the moment is changing the About dialog to say something like "SQLCipher based on SQLite version x.y.z". Or are there any other ideas?

I think compile time option is the most straightforward approach. Too bad it isn't working.

So the only thing we could do at the moment is changing the About dialog to say something like "SQLCipher based on SQLite version x.y.z".

Sounds good. 👍

Or are there any other ideas?

In-memory database? 😄

I have just changed the version text in the About dialog like discussed. Should be less confusing now 😄

@karim You're right 👍 An in-memory database would indeed work. It's probably not worth the effort though 😉 Or should we do that?

Hmmm, if the effort isn't large we should probably do that. 😄

Ok, done 😄 It shows now "SQLCIpher Version a.b.c (based on SQLite x.y.z)".

Took a quick look at this on OSX using the overnight build. Looks good to me. 😄