If you look at the Makefile it merely checks the existence of librocksdb.a for deciding whether or not to run make in the submodule.
Thanks. I’ve updated the submodule and set the C++ standard to c++17. Seems to work fine.
For packs in general, if the pack_install/1 fails for some reason, go to the pack directory (typically ~/.local/share/swi-prolog/pack/<Pack>), run
source buildenv.sh
make
Instead of plain make you can do all the usual stuff to get naughty foreign code built. The buildenv.sh script is created by the pack_install/1 and defines the environment variables that make it possible to find SWI-Prolog components and setup the pack for the current architecture.
The choice for a static library compiled with -fPIC is quite deliberate as it makes the result easier to share (just a single shared object) while this is not a generic build anyway.
I know. Supporting some more is probably useful, When I wrote the rocksdb interface it was mostly to compare it against BerkeleyDB for a specific project. It scales a lot better from what I recall. BerkeleyDB has other nice properties though, such as allowing multiple processes to access the same database concurrently.