New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build fails on Linux (Ubuntu) #1474

Open
tilusnet opened this Issue Jul 14, 2018 · 26 comments

Comments

Projects
None yet
5 participants
@tilusnet
Copy link

tilusnet commented Jul 14, 2018

Details for the issue

What did you do?

Building sqlitebrowser from source.

What did you expect to see?

Build successful.

What did you see instead?

. . .
[100%] Linking CXX executable sqlitebrowser
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libsqlcipher.so: undefined reference to `EVP_CIPHER_block_size@OPENSSL_1.0.0'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libsqlcipher.so: undefined reference to `EVP_CipherUpdate@OPENSSL_1.0.0'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libsqlcipher.so: undefined reference to `EVP_CIPHER_iv_length@OPENSSL_1.0.0'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libsqlcipher.so: undefined reference to `OBJ_nid2sn@OPENSSL_1.0.0'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libsqlcipher.so: undefined reference to `EVP_CIPHER_nid@OPENSSL_1.0.0'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libsqlcipher.so: undefined reference to `EVP_CipherInit@OPENSSL_1.0.0'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libsqlcipher.so: undefined reference to `EVP_CIPHER_key_length@OPENSSL_1.0.0'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libsqlcipher.so: undefined reference to `RAND_add@OPENSSL_1.0.0'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libsqlcipher.so: undefined reference to `HMAC_Final@OPENSSL_1.0.0'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libsqlcipher.so: undefined reference to `EVP_get_cipherbyname@OPENSSL_1.0.0'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libsqlcipher.so: undefined reference to `EVP_sha1@OPENSSL_1.0.0'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libsqlcipher.so: undefined reference to `PKCS5_PBKDF2_HMAC_SHA1@OPENSSL_1.0.0'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libsqlcipher.so: undefined reference to `RAND_bytes@OPENSSL_1.0.0'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libsqlcipher.so: undefined reference to `HMAC_CTX_cleanup@OPENSSL_1.0.0'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libsqlcipher.so: undefined reference to `HMAC_Update@OPENSSL_1.0.0'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libsqlcipher.so: undefined reference to `HMAC_Init_ex@OPENSSL_1.0.0'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libsqlcipher.so: undefined reference to `EVP_cleanup@OPENSSL_1.0.0'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libsqlcipher.so: undefined reference to `EVP_CIPHER_CTX_cleanup@OPENSSL_1.0.0'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libsqlcipher.so: undefined reference to `EVP_CipherFinal@OPENSSL_1.0.0'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libsqlcipher.so: undefined reference to `EVP_CIPHER_CTX_set_padding@OPENSSL_1.0.0'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libsqlcipher.so: undefined reference to `OPENSSL_add_all_algorithms_noconf@OPENSSL_1.0.0'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libsqlcipher.so: undefined reference to `EVP_MD_size@OPENSSL_1.0.0'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libsqlcipher.so: undefined reference to `HMAC_CTX_init@OPENSSL_1.0.0'
collect2: error: ld returned 1 exit status
CMakeFiles/sqlitebrowser.dir/build.make:1570: recipe for target 'sqlitebrowser' failed
make[2]: *** [sqlitebrowser] Error 1
CMakeFiles/Makefile2:71: recipe for target 'CMakeFiles/sqlitebrowser.dir/all' failed
make[1]: *** [CMakeFiles/sqlitebrowser.dir/all] Error 2
Makefile:149: recipe for target 'all' failed
make: *** [all] Error 2

Useful extra information

The info below often helps, please fill it out if you're able to. :)

What operating system are you using?

  • Windows: ( version: ___ )
  • Linux: ( Ubuntu 16.04 )
  • Mac OS: ( version: ___ )
  • Other: ___

What is your DB4S version?

  • 3.10.1
  • 3.10.0
  • 3.9.1
  • Other: source, latest (14 Jul 2018, 13:50 BST)

Did you also

@MKleusberg

This comment has been minimized.

Copy link
Member

MKleusberg commented Jul 14, 2018

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.

@tilusnet

This comment has been minimized.

Copy link
Author

tilusnet commented Jul 14, 2018

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.

@tilusnet

This comment has been minimized.

Copy link
Author

tilusnet commented Jul 14, 2018

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.

@karim

This comment has been minimized.

Copy link
Member

karim commented Jul 15, 2018

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.

@tilusnet

This comment has been minimized.

Copy link
Author

tilusnet commented Jul 15, 2018

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).

@justinclift

This comment has been minimized.

Copy link
Member

justinclift commented Jul 15, 2018

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. 😄

@justinclift

This comment has been minimized.

Copy link
Member

justinclift commented Jul 15, 2018

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. 😉

@tilusnet

This comment has been minimized.

Copy link
Author

tilusnet commented Jul 15, 2018

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. :-)

@justinclift

This comment has been minimized.

Copy link
Member

justinclift commented Jul 15, 2018

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.

@tilusnet

This comment has been minimized.

Copy link
Author

tilusnet commented Jul 15, 2018

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?

@justinclift

This comment has been minimized.

Copy link
Member

justinclift commented Jul 15, 2018

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. 😄

@MKleusberg

This comment has been minimized.

Copy link
Member

MKleusberg commented Jul 15, 2018

@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? 😄

@justinclift

This comment has been minimized.

Copy link
Member

justinclift commented Jul 15, 2018

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 ?

@developernotes

This comment has been minimized.

Copy link

developernotes commented Jul 16, 2018

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?

@justinclift

This comment has been minimized.

Copy link
Member

justinclift commented Jul 16, 2018

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

@justinclift

This comment has been minimized.

Copy link
Member

justinclift commented Jul 16, 2018

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?

@developernotes

This comment has been minimized.

Copy link

developernotes commented Jul 16, 2018

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?

@karim

This comment has been minimized.

Copy link
Member

karim commented Jul 16, 2018

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. 😃

cipher

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

cipher2

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

@justinclift

This comment has been minimized.

Copy link
Member

justinclift commented Jul 16, 2018

Cool. Sorry for the mix up @developernotes. 😄

@developernotes

This comment has been minimized.

Copy link

developernotes commented Jul 16, 2018

@justinclift no worries at all, happy to help!

@MKleusberg

This comment has been minimized.

Copy link
Member

MKleusberg commented Aug 10, 2018

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?

@karim

This comment has been minimized.

Copy link
Member

karim commented Aug 10, 2018

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? 😄

MKleusberg added a commit that referenced this issue Aug 10, 2018

Avoid confusion in the About dialog about the SQLCipher version
SQLCipher reports in its SQLITE_VERSION macro the version of the
underlying SQLite version. Because we cannot easily get any other
version from SQLCipher and because the reported version is not identical
to the SQLCipher version we need to rephrase the wording in the dialog a
bit to keep the two versions separated.

See issue #1474.
@MKleusberg

This comment has been minimized.

Copy link
Member

MKleusberg commented Aug 10, 2018

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?

@justinclift

This comment has been minimized.

Copy link
Member

justinclift commented Aug 10, 2018

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

MKleusberg added a commit that referenced this issue Aug 10, 2018

@MKleusberg

This comment has been minimized.

Copy link
Member

MKleusberg commented Aug 10, 2018

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

@justinclift

This comment has been minimized.

Copy link
Member

justinclift commented Aug 11, 2018

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

screen shot 2018-08-11 at 14 25 51

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment