Are there any plans to support building static library for foundationdb (like libfdb_c.a)?
using dynamic library can be very problematic when using a container environment because binaries (eg. written in go) cannot be statically linked.
Part of the reason we publish a dynamic (rather than static) library (or publish a dynamic library at all rather than baking the client into our bindings where possible) is that there is a strong dependence between the version of the FoundationDB client and the FoundationDB server version. In particular, in the simplest configuration, a client can only talk to a version of the server if they are within the same minor version. (There are also ways of configuring the client to talk to multiple versions by supplying multiple binaries. See: Using FoundationDB Clients with particular focus on the multi-version client.)
By decoupling the client library and the bindings, you can do things like upgrade your client library without having to make any code changes to your application (including upgrading your binding), which can make the process of upgrading smoother.
That being said, decoupling those two things does make it harder to distribute FoundationDB clients and can make deploy configurations more…delicate.
The other problem with publishing static libraries is that they can often be fairly specific to your build system, and I’m not sure how portable they are. I think we’d want to make sure they actually could be ported across distros before we were to publish them.
Our general advice for those running in containers is to include them within their application in their container, and then to set the LD_LIBRARY_PATH environment variable (if they are running in a Linux container) to something that includes the path to the dynamic library.