Compiling Seabolt on Arch Linux

As of v1.7.0-rc02 of Seabolt there seems to be an issue compiling on Arch Linux even after setting OPENSSL_ROOT_DIR.

Not sure if this is an issue with Arch Linux being a rolling release distro and Arch is using an incompatible version of OpenSSL.

If anyone has a greater insight to the issue I'd love to know.


Hi @MattJBrowning,

We're aware of a problem regarding the newly introduced static library output. On some systems, openssl requires libz to be able to statically compiled and we don't add it to the target link libraries.

You can manually add target_link_libraries(seabolt-static PUBLIC z) line to the src/seabolt/src/CMakeLists.txt file until we fix the issue.

If this doesn't resolve the problem you're facing, could you please provide us with full output of the error?


1 Like

Thanks for the response @ali_ince,

Adding that line didn't seem to change the output. Here is the error that it spits out in the terminal.

This is prompted when running ./ and I do have OPENSSL_ROOT_DIR set.

-- 1.7.0-rc03
-- Building seabolt with TLS support
-- Using OPENSSL for TLS
-- Discovered OpenSSL shared libraries: /usr/lib/openssl-1.0/;/usr/lib/openssl-1.0/
CMake Error at /usr/share/cmake-3.12/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
  Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the
  system variable OPENSSL_ROOT_DIR (missing: OPENSSL_CRYPTO_LIBRARY) (found
  version "1.0.2p")
Call Stack (most recent call first):
  /usr/share/cmake-3.12/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake-3.12/Modules/FindOpenSSL.cmake:412 (find_package_handle_standard_args)
  cmake/Internals.cmake:59 (find_package)
  src/seabolt/src/CMakeLists.txt:105 (find_openssl_both)
  src/seabolt/CMakeLists.txt:5 (include)
  src/CMakeLists.txt:14 (include)
  CMakeLists.txt:105 (include)


1.7.0-rc03 adds static library output and uses that built static library while linking seabolt-test and seabolt-cli projects - which requires openssl static libraries to be present on the system. Most systems provide it by default using openssl-devel like packages but it seems that Arch Linux doesn't ship static libraries by default.

I think the right direction is to find out how to install those openssl static libraries on your system.


1 Like

Ended up getting the seabolt release from Github and installing it. Will most likely see about making a AUR repo for Seabolt at some point in the future so Arch users can install it easier.


Could you be more precise please, how you solve the problem?

Still can not install on arch, with the same problem.
There is no install release on github for arch-linux.


1 Like

Sorry for the slow response, had to go through the process again to jog my memory. Before we switched away from neo4j we ended up switching from the release method to source for a reason I can't remember.

The issue is because arch doesn't build static libraries anymore, so you have do download the PKGBUILD file and add in options=('staticlibs') to get seabolt to compile properly.

I use yay over pacman at the moment so I can just do yay -G openssl, the other route would be to go to the openssl package and download it from the mirror if you were not using yay.

Once you've downloaded the PKGBUILD file, you need to edit it and add in the options=('staticlibs'). I ended up putting it under the depends=('perl') but I don't think it matters too much. The PKGBUILD file options will end up looking like this

# use a pacman compatible version scheme
pkgdesc='The Open Source toolkit for Secure Sockets Layer and Transport Layer Security'

After you get that in, save it and go to the direction where the PKGBUILD is saved and run makepkg -si. That should run the PKGBUILD script and reinstall openssl but this time statically link the libraries so Seabolt can use them.

After it installs, the directions that are included in the seabolt install readme should work. Basically cloning it and running ./make_release.

Hopefully that all made sense, if it didn't, feel free to ask further.

Thank you very much.

Do I understand you right, that you switch neo4j db for something else?
And what exactly, if so.

1 Like

You'd be correct in understanding that we switched from neo4j. I still personally think Neo4j is awesome and a great overall database.

At the beginning we used the community driver written in native Go which shortly after the official driver being release, the author no longer had time to maintain it, we switched over a good chunk of our server over to the official driver which used seabolt.

At the time we switched to the alpha when it was released we had 2 employees including myself, so it wasn't too hard to communicate how to get everything up and running whenever there was an update for the driver or seabolt, but once we started hiring on more developers it became more difficult to get everyone on the same version, depending on the OS there seemed to be different issues, which I understand I think at this point it was in beta so it was bound to have issues.

But we essentially reached a point where it felt delicate. We were using two different libraries to get back some quality of life features, if I recall we were using mapstructure to turn out structs to a map[string]interface{}, and a library called structs to take the map[string]interface{} and covert it into a struct. And at times, since we're all Go developers we felt a little helpless when there was an issue that usually seemed to point in the realm of C so it felt like an up hill battle.

Seemed like most of our developers has a issue with Seabolt so we had a meeting and looked at our options, use sql and find a good wrapper, use mongodb, which at this point recently went into beta if I recall for their official driver, and dgraph.

After writing test apps we ended up using MongoDB because it seemed to have great support for Go and their $graphLookup command did what graph queries we needed.

I just asked around the office and everything seems to be happy with the decision to switch to Mongo. Though to note, most everyone liked working with Cypher and the Neo4j Browser, it just seemed that the driver was lacking, at times didn't feel like Go.

I feel like I've just bashed on Neo4j a bit, and I don't want to convey that, I think it's a great technology, the Neo4j Browser made it awesome to test out queries, and the Cypher language was great to work with, it just didn't work with our workflow and there was a better alternative that worked with our structure that has a really good native Go driver.

I still have hope that one day neo4j will implement the bolt protocol to Go and ditch seabolt. I think that would be a massive improvement, then add on various quality of life features that many other database drivers/wrappers have to allow for easy encoding/decoding to structs. And if that happens we'll most likely be looking at Neo4j again at that time.

Hi All,

For the arch linux users, I've crafted a Dockerfile available at A Dockerfile that enables seabolt compilation on arch linux · GitHub which rebuilds openssl with static libraries and incrementally builds seabolt, installs go and builds the sample blog post code we have provided at The All New Neo4j Drivers Are Out — Now Including Go! | by Ali Ince | Neo4j Developer Blog | Medium linked with static libraries and copies the output to a vanilla arch linux base image.

Basic steps;

  1. Save A Dockerfile that enables seabolt compilation on arch linux · GitHub into a file named as Dockerfile.
  2. Go to that directory and invoke docker image build -t neo4j-go-driver-blog-post . This will build up the image with the final go executable.
  3. When you invoke docker container run --name go-driver-blog-post neo4j-go-driver-blog-post it will write usage text on the console. You can append required command line arguments so that it can connect to a neo4j database and execute the query you've specified.

I believe this will be a good start to get things going.