# Using FoundationDB without installing client libraries **URL:** \ **Category:** Using FoundationDB\ **Tags:** bindings\ **Created:** [October 4, 2019, 8:01pm UTC](https://forums.foundationdb.org/t/using-foundationdb-without-installing-client-libraries/1667 "2019-10-04T20:01:14Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![kc626](https://avatars.discourse-cdn.com/v4/letter/k/4af34b/32.png) [@kc626](https://forums.foundationdb.org/u/kc626)\ **Post date:** [October 4, 2019, 8:01pm UTC](https://forums.foundationdb.org/t/using-foundationdb-without-installing-client-libraries/1667/1 "2019-10-04T20:01:14Z")
I’m currently trying to add FoundationDB support to an open source project ([https://github.com/locationtech/geowave](https://github.com/locationtech/geowave)) and am currently using the Java API bindings to try to run it. However, when I try to run `FDB.selectAPIVersion(610)`, I get a `java.lang.UnsatisfiedLinkError:` and realized that the line I’m failing on is `JNIUtil.loadLibrary("fdb_java");`. My guess for why this error is happening is because I currently don’t have the FoundationDB client libraries installed on my computer. Is there a way to bypass this? Ideally, users who use this project would not have to actually install the client libraries themselves. ---
**Author:** ![alloc](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/alloc/32/9_2.png) [@alloc](https://forums.foundationdb.org/u/alloc)\ **Post date:** [October 8, 2019, 12:23am UTC](https://forums.foundationdb.org/t/using-foundationdb-without-installing-client-libraries/1667/2 "2019-10-08T00:23:43Z")
Hm, interesting that you’d be failing on the `fdb_java` line. That library should be included within the jar (unless you’re running on some system we don’t support, but there is a Linux so file, a macOS dylib, and a Windows DLL included). There is also separately an `fdb_c` dependency that you’ll need to include. There’s no way to run the FoundationDB client without having the dependency around (short of [running a separate proxy service](https://forums.foundationdb.org/t/proxy-layer-for-securing-the-cluster/1611)), but you don’t need the user to have installed the library, necessarily. On Linux, you should be able to set the `LD_LIBRARY_PATH` environment variable to include the path to a directory where you have included the library. Less tested, but also, I think on all platforms, if you set the `FDB_LIBRARY_PATH_FDB_C` Java system property to the path of the library, then I think that, too, should load the C library. (Note that this is undocumented, and I’m not sure if it was really intended to be something use in real environments.) You can download the C library from our website: ```auto https://www.foundationdb.org/downloads/${version}/${os}/libfdb_c_${version}.${ext} ``` Where `${version}` is the FDB version, `${os}` is your operating system (linux, macOS, or windows), and `${ext}` is the platform specific dynamic library file extension. ---
**Author:** ![kc626](https://avatars.discourse-cdn.com/v4/letter/k/4af34b/32.png) [@kc626](https://forums.foundationdb.org/u/kc626)\ **Post date:** [October 8, 2019, 3:19am UTC](https://forums.foundationdb.org/t/using-foundationdb-without-installing-client-libraries/1667/3 "2019-10-08T03:19:13Z")
Thanks so much! I did as you said and installed the `libfdb_c_6.1.12.dylib` & added the directory its in to `LD_LIBRARY_PATH`. It works now! 🙂 ---
**Author:** ![spullara](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/spullara/32/125_2.png) [@spullara](https://forums.foundationdb.org/u/spullara)\ **Post date:** [October 9, 2019, 7:34pm UTC](https://forums.foundationdb.org/t/using-foundationdb-without-installing-client-libraries/1667/4 "2019-10-09T19:34:27Z")
It would probably be convenient to create artifacts for the Java library that include the actual client library as well under a different artifact id. No real reason to make it a separate install if all you need is the .so. ---
**Author:** ![alloc](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/alloc/32/9_2.png) [@alloc](https://forums.foundationdb.org/u/alloc)\ **Post date:** [October 9, 2019, 8:47pm UTC](https://forums.foundationdb.org/t/using-foundationdb-without-installing-client-libraries/1667/5 "2019-10-09T20:47:37Z")
I believe the reason is that you need to match the client C library version with the server C library version (and/or use the multi-version client in order to have no client downtime during an upgrade). Separating the C library from the Java artifact allows the user to then upgrade the C library like they would update some other part of their “config” information rather than needing to update their Java dependency. That being said, keeping them separate is somewhat of a hassle and keeps the learning curve for new people relatively high, so it might make sense to have some kind of separate dependency with them included. ---
**Author:** ![spullara](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/spullara/32/125_2.png) [@spullara](https://forums.foundationdb.org/u/spullara)\ **Post date:** [October 9, 2019, 9:37pm UTC](https://forums.foundationdb.org/t/using-foundationdb-without-installing-client-libraries/1667/6 "2019-10-09T21:37:08Z")
This might be crazy but how about a way to download the client libraries from the server. Been thinking about this for a different database recently and am probably going to implement it. ---
**Author:** ![john\_brownlee](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/john_brownlee/32/22_2.png) [@john\_brownlee](https://forums.foundationdb.org/u/john_brownlee)\ **Post date:** [October 10, 2019, 3:45pm UTC](https://forums.foundationdb.org/t/using-foundationdb-without-installing-client-libraries/1667/7 "2019-10-10T15:45:18Z")
I think that could make sense as an option, though it would likely require adding a new HTTP interface and more information in the cluster file on how to discover it. Part of the reason we haven’t pursued that is because of security and reliability concerns around dynamically injecting code at run time, but if there are members of the community that want to accept that trade-off I don’t see anything unreasonable about it. ---
**Author:** ![josephg](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/josephg/32/84_2.png) [@josephg](https://forums.foundationdb.org/u/josephg)\ **Post date:** [October 14, 2019, 10:08pm UTC](https://forums.foundationdb.org/t/using-foundationdb-without-installing-client-libraries/1667/8 "2019-10-14T22:08:46Z")
Hi! Nodejs foundationdb maintainer here. I’ve wanted this for a long time for the nodejs bindings too. (Usually nodejs libraries should just work out of the box!). This is the #1 issue for people just getting started, since any project which depends on the node foundationdb bindings in any way can’t even npm install without a working `libfdb_c`. @spullara If you add a way for the server to send the client the `libfdb_c` library in some way, I’ll happily integrate it into the node bindings too. Another approach (rather than running an http server) would be to have an API to allow the server to tell the client the URL for an appropriate library file from the [downloads page](https://www.foundationdb.org/download/) along with a checksum. ---
**Author:** ![spullara](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/spullara/32/125_2.png) [@spullara](https://forums.foundationdb.org/u/spullara)\ **Post date:** [October 17, 2019, 4:44pm UTC](https://forums.foundationdb.org/t/using-foundationdb-without-installing-client-libraries/1667/9 "2019-10-17T16:44:26Z")
That approach works as long as the system that is using the driver can reach the internet. One nice thing about distributing from the server is that we know the client can reach it otherwise it won’t be able to connect either. ---
**Author:** ![alexmiller](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/alexmiller/32/326_2.png) [@alexmiller](https://forums.foundationdb.org/u/alexmiller)\ **Post date:** [October 17, 2019, 5:43pm UTC](https://forums.foundationdb.org/t/using-foundationdb-without-installing-client-libraries/1667/10 "2019-10-17T17:43:21Z")
If we used [foundationdb.org](http://foundationdb.org) as a root of trust, one could theoretically arrange… 1. libfdb\_c.so available for download on [foundationdb.org](http://foundationdb.org) as a .signature section that contains a signature verifying that it is from the official distribution 2. The public key for this signature is baked into fdbserver and bindings 3. Bindings verify that the libfdb\_c that they receive is signed using the embedded public key Would resolve the security concerns here, I think. However, that’s a ton of security/cryptography heavy code that I’m not sure I’d even be personally comfortable writing… ---
**Author:** ![josephg](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/josephg/32/84_2.png) [@josephg](https://forums.foundationdb.org/u/josephg)\ **Post date:** [October 18, 2019, 2:31am UTC](https://forums.foundationdb.org/t/using-foundationdb-without-installing-client-libraries/1667/11 "2019-10-18T02:31:48Z")
The crypto part of that isn’t as bad as it sounds. It just depends on signatures. I’d probably use [libsodium’s `crypto_generichash`](https://libsodium.gitbook.io/doc/hashing/generic_hashing#purpose), which is explicitly marked as being appropriate for file integrity checking. Even just using SHA256 would _probably_ be fine, but I’d want to check that thats safe against length extension attacks. (I trust that libsodium is definitely safe, since the authors know what they’re doing. But it is another dependancy though.) @spullara I agree and I hear you. On the flip side, one nice thing about pointing to the website is we don’t bloat up the server with a bunch of extra binaries. To make this robust we’d need to ship copies of fdb\_c for each platform foundationdb supports. At a minimum we’d want the libraries for windows, mac and linux, and mac version alone is 7mb in size. ---
**Author:** ![alexmiller](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/alexmiller/32/326_2.png) [@alexmiller](https://forums.foundationdb.org/u/alexmiller)\ **Post date:** [October 18, 2019, 5:46am UTC](https://forums.foundationdb.org/t/using-foundationdb-without-installing-client-libraries/1667/12 "2019-10-18T05:46:11Z")
Oh, yeah, this does sound way easier if it’s not trying to mentally contort myself to understand an openssl API. It looks like [`crypto_sign_*`](https://download.libsodium.org/doc/public-key_cryptography/public-key_signatures) is what I wanted to use the official builders as a root of trust. I think someone would next need to sit down and write up a document proposing exactly how clients would discover and download libfdb\_c versions from servers in a way that fits into our client protocol, would scale (ie. cluster wouldn’t die if 10K clients show up at once), and have a sane operational story. There’s also a “competing” proposal floating around to solve this problem via offering a well defined gRPC or similar interface, and a new “Client API Proxy” role that translates this API into FDB’s native protocol. This would leave binding authors with essentially two different ways of speaking to FDB, with the native library offering lower latency, and the gRPC interface offering libfdb\_c freedom. ---
**Author:** ![subramaniamr](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/subramaniamr/32/658_2.png) [@subramaniamr](https://forums.foundationdb.org/u/subramaniamr)\ **Post date:** [January 3, 2020, 9:36am UTC](https://forums.foundationdb.org/t/using-foundationdb-without-installing-client-libraries/1667/13 "2020-01-03T09:36:21Z")
@alloc Is this solution expected to work in Intel Xeon E5 processor ? Its certainly failing while loading the fdb\_java.dll ---
**Author:** ![jon](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/jon/32/1896_2.png) [@jon](https://forums.foundationdb.org/u/jon)\ **Post date:** [January 17, 2025, 8:32pm UTC](https://forums.foundationdb.org/t/using-foundationdb-without-installing-client-libraries/1667/14 "2025-01-17T20:32:24Z")
Friends, I hope you’ll pardon me for reviving this ancient topic. I’m aware of a number of other packages (at least in the Java world) that include native libraries. I’ll call out [sqlite-jdbc](https://github.com/xerial/sqlite-jdbc) and [netty-tcnative-boringssl-static](https://netty.io/wiki/forked-tomcat-native.html) as examples. We’re just starting our journey with FoundationDB, but if we really wind up using it, I think we’d be willing to do some work to put together a batteries-included jar for (at least) Java. Assuming the technical obstacles are surmountable, would y’all be interested in that kind of contribution? Are there licensing concerns or other subtle gotchas that might stand in the way? Thanks kindly! ---
**Author:** ![danm](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/danm/32/1393_2.png) [@danm](https://forums.foundationdb.org/u/danm)\ **Post date:** [January 31, 2025, 3:20pm UTC](https://forums.foundationdb.org/t/using-foundationdb-without-installing-client-libraries/1667/15 "2025-01-31T15:20:09Z")
@jon In terms of subtle _technical_ gotchas, something that we’ve found on MacOS on Apple Silicon (i.e. arm) is that for some reason the JNILib contained within the jar isn’t correctly loaded. We have to symlink the dylib from the default FDB install path to one of Mac’s standard Java lib paths, and then also pull the jnilib out of the jar and put it in the same location. Only then does our local dev stuff work. We had no such problems with our deployed system on Linux, and no problems on MacOS until Apple released the Apple Silicon/arm Macs. For a while we had some staff on Intel Macs and some on arm, running the same OS version, and those on Intel were fine and those on arm were not. When we tried to fix arm it broke Intel. We’d got everyone transitioned to arm before we’d properly nailed down the issues and resolved them, so we ditched the Intel support. But if you were able to produce something where we could just install FDB from package, install the Java lib, and everything would Just Work ™ on Mac without faffing about it would be _amazing_…