Ok I dug into it abit more on Friday. But never managed to reproduce the issue. The way rocksdbjni works (or atleast in the way we are using it) is it tries to load the system rocksdb library before it tries to load the library from the jar. But the strange thing is that you are getting a error from when it tries to load the .so file from the jar. (you can see that it is the from jar loading code in the stacktrace) That says a symbol is undefined from a library that should be statically compiled (jemalloc) into the jar .so file. Now I noticed that that library (jemalloc) is not statically compiled into the aur/rocksdb library. So I had a theory that maybe it tries to load a incompatible version of jemalloc when trying to load the system rocksdb and failing for some other reason. And then the jar .so file fails becouse the process has a incompatible jemalloc library version loaded. Have you tried just removing or moving the system rocksdb version and then tried crux?

There is a call in the rocksdbjni to load the library explicitly from the jar. We should probably consider making that the default and add some flag for if you want to use the system version of rocksdb instead.

The whole affair feels pretty wobbly

I'm sure I'm missing something, but building rocksdb is a pain.

I had to downgrade my JDK because their build system uses depreciated 'javah' to build the jni headers. I didn't dig into how to hack their stuff to use newer 'javac' variant.

so have you tried running crux without having a rocksdb installation at all on your system?

the next issue was TBB library. It just gets that wrong.

I haven't backtracked to that point lately, but it seems that is how we got here in the first place. I didn't have a rocks installed when I started this

the progression was 1) no rocks installed; 2) use the AUR version; 3) build my own; 4) build my own with TBB disabled

Maybe I'm the freak, but this seems like a dreadful UX episode, mostly because getting rocks into the system is pretty painful

yea it should not be necessary. It seems you are the only one so far to have problems with this. But maybe there are some others who haven't told us. But almost all JUXT is using arch as there system so it seems like this is rare.

let me know if there is anything I can do to help.

@hoppy we certainly appreciate your patience and perseverance! It's possible that LMDB might ultimately be the less complex/problematic option for the average user... I will make sure we periodically reassess which KV store we suggest as the default for Crux

Just to be clear, I'm not being cranky - I expect some bumps with new stuff. My main sentiment here is that I'm a fan of what you guys are doing, and would like to see it succeed hugely - and I'm just trying to point out/help with rough edges if I can. I think debugging undefined symbols in JNI and building rocks from source is probably more than can be realistically expected from somebody just "check'n things out"

To me, this issue lies in the rocks wheelhouse - their approach is brittle. But since you guys depend on it, you get to take the slug when it doesn't work, and I'm not liking that.