foundationdb java client native library missing

[dpetran]

Describe the bug

Attempting to connect to a running foundationdb cluster with the java client library produces a java.lang.UnsatisfiedLinkError while trying to initialize the com.apple.foundationdb.FDB class.

Steps To Reproduce

Steps to reproduce the behavior:

1. configure and start the foundationdb service

   foundationdb = {
     enable = true;
     package = pkgs.fdbPackages.foundationdb71;
   };

2. verify that the cluster is running with fdbcli

   
   fdb> status

Using cluster file `/etc/foundationdb/fdb.cluster'.

Configuration: Redundancy mode - single Storage engine - ssd-2 Coordinators - 1 Usable Regions - 1

Cluster: FoundationDB processes - 1 Zones - 1 Machines - 1 Memory availability - 8.0 GB per process on machine with least available Fault Tolerance - 0 machines Server time - 07/09/23 21:45:07

Data: Replication health - Healthy Moving data - 0.000 GB Sum of key-value sizes - 0 MB Disk space used - 210 MB

Operating space: Storage server - 715.8 GB free on most full server Log server - 715.8 GB free on most full server

Workload: Read rate - 16 Hz Write rate - 0 Hz Transactions started - 5 Hz Transactions committed - 0 Hz Conflict rate - 0 Hz

Backup and DR: Running backups - 0 Running DRs - 0

Client time: 07/09/23 21:45:07

3. set up a clojure shell

nix-shell -p clojure

4. try to use the java client by running this clojure command at the shell:

clj -Sdeps '{:deps {org.foundationdb/fdb-java {:mvn/version "7.1.30"}}}' -e '(com.apple.foundationdb.FDB/selectAPIVersion 7130)'

5. observe the link error get produced at runtime:

Execution error (UnsatisfiedLinkError) at jdk.internal.loader.NativeLibraries/load (NativeLibraries.java:-2). /tmp/fdb_java14609399059907539626.library: libfdb_c.so: cannot open shared object file: No such file or directory

### Expected behavior
No UnsatisfiedLinkError should be produced.

### Additional context
I'm unsure that the problem resides with the nixos package, I've never tried using native libraries from the JVM before, so there may be a step that I'm missing.

### Notify maintainers
@thoughtpolice @lostnet  

### Metadata
Please run `nix-shell -p nix-info --run "nix-info -m"` and paste the result.

```console
 - system: `"x86_64-linux"`
 - host os: `Linux 6.1.33, NixOS, 23.05 (Stoat), 23.05.997.ddf4688dc7a`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.13.3`
 - channels(root): `"nixos-23.05"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

[wegank]

libfdb_c.so is located in ${foundationdb.lib}/lib, you'll probably want to add this path to LD_LIBRARY_PATH.

[dpetran]

Alright, I was able to find the foundationdb.lib path by running nix-shell -p fdb.packages.foundationdb71, which produced the following output:

$ nix-shell -p fdbPackages.foundationdb71
these 5 paths will be fetched (4.53 MiB download, 27.03 MiB unpacked):
  /nix/store/087609j187svcvxi5rn0jk3b9rh9pm24-file-5.44
  /nix/store/58l0cd5yhzmrnnb03clma75cys8smdqh-foundationdb-7.1.30-dev
  /nix/store/5wdlffjhcr4i43sfajxcvx3lvnkryh5y-stdenv-linux
  /nix/store/h1i6zdl9x43srgf58b30df86p3w68wm4-foundationdb-7.1.30-lib
  /nix/store/v379zfyn6473hcy2nvlam0vkn120gfbp-gnumake-4.4.1
copying path '/nix/store/087609j187svcvxi5rn0jk3b9rh9pm24-file-5.44' from 'https://cache.nixos.org'...
copying path '/nix/store/h1i6zdl9x43srgf58b30df86p3w68wm4-foundationdb-7.1.30-lib' from 'https://cache.nixos.org'...
copying path '/nix/store/v379zfyn6473hcy2nvlam0vkn120gfbp-gnumake-4.4.1' from 'https://cache.nixos.org'...
copying path '/nix/store/5wdlffjhcr4i43sfajxcvx3lvnkryh5y-stdenv-linux' from 'https://cache.nixos.org'...
copying path '/nix/store/58l0cd5yhzmrnnb03clma75cys8smdqh-foundationdb-7.1.30-dev' from 'https://cache.nixos.org'...

And I saw the lib path at /nix/store/h1i6zdl9x43srgf58b30df86p3w68wm4-foundationdb-7.1.30-lib, which I added to the my LD_LIBRARY_PATH:

$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/nix/store/h1i6zdl9x43srgf58b30df86p3w68wm4-foundationdb-7.1.30-lib/lib/

And then I ran my basic test again

clj -Sdeps '{:deps {org.foundationdb/fdb-java {:mvn/version "7.1.30"}}}' -e '(com.apple.foundationdb.FDB/selectAPIVersion 710)'

And it worked! Thank you.

Is manually setting the LD_LIBRARY_PATH in my project the way forward? I didn't see the lib path in the output when I ran the nixos-rebuild switch command to run the server, so I'm not sure how to find the lib path without manually inspecting the output of the nix-shell command, and I'd like to avoid that if I can.

[wegank]

I guess you could create a shell.nix like this and do the export in shellHook?

[dpetran]

I have a couple of points I'm confused on:

1. I thought the foundationdb.package = pkfs.fdbPackages.foundationdb71; would install the foundationdb71 package, but after I do that the libfdb_c.so nix store path is missing. When I create a shell that uses the foundationdb71 package, the libfdb_c.so nix store path is created. Why doesn't the service definition install the whole package?
2. Shouldn't the package definition properly set the LD_LIBRARY_PATH variable so that it's available to any program that wants to use it?

[wegank]

Why doesn't the service definition install the whole package?

The foundationdb is a multi-output package, meaning that foundationdb.lib would only be retrieved if it's determined at build time to be a runtime dependency of foundationdb.out. This is probably not the case at present.

Shouldn't the package definition properly set the LD_LIBRARY_PATH variable so that it's available to any program that wants to use it?

The pattern is strongly discouraged, see here. In my opinion, this can be problematic if multiple versions of a package are installed.