# FoundationDB clients on Alpine Linux **URL:** \ **Category:** Using FoundationDB\ **Created:** [September 21, 2018, 9:07am UTC](https://forums.foundationdb.org/t/foundationdb-clients-on-alpine-linux/720 "2018-09-21T09:07:13Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![num](https://avatars.discourse-cdn.com/v4/letter/n/db5fbb/32.png) [@num](https://forums.foundationdb.org/u/num)\ **Post date:** [September 21, 2018, 9:07am UTC](https://forums.foundationdb.org/t/foundationdb-clients-on-alpine-linux/720/1 "2018-09-21T09:07:13Z")
Anyone tried to link with FoundationDB client library (libfdb\_c.so) on Alpine Linux? Alpine Linux is a default choice when using docker containers but it doesn’t use glibc, so existing libfdb\_c.so does not work (missing symbols are reported). ---
**Author:** ![markus.pilman](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/markus.pilman/32/379_2.png) [@markus.pilman](https://forums.foundationdb.org/u/markus.pilman)\ **Post date:** [September 24, 2018, 6:08pm UTC](https://forums.foundationdb.org/t/foundationdb-clients-on-alpine-linux/720/2 "2018-09-24T18:08:11Z")
Generating an archive instead of a shared object should be pretty straight forward. But this archive will still depend on glibc. Statically linking glibc is virtually impossible as glibc depends on many shared libraries that are linked in at runtime using dlopen. To some degree this might also be true for libstdc++. I think you have two possibilities here: 1. Ship a container that contains all dependencies 2. Rewrite the fdbclient in go (this would be a major project, but it should be doable). You can try to build a fdbc archive and link against uclibc and link statically against libstdc++ (which also has to be linked against uclibc). But I never did this so I can’t say how much work that would be. Also: where are you planning to run these docker containers? Are a few hundred megabytes on disk really an issue for you? Also keep in mind that FDB is not tested with uclibc. So the performance characteristics might be very different and changing the C library might unearth new bugs. ---
**Author:** ![num](https://avatars.discourse-cdn.com/v4/letter/n/db5fbb/32.png) [@num](https://forums.foundationdb.org/u/num)\ **Post date:** [September 24, 2018, 7:52pm UTC](https://forums.foundationdb.org/t/foundationdb-clients-on-alpine-linux/720/3 "2018-09-24T19:52:29Z")
I managed to make it work by installing glibc package on Alpine Linux. It worked for scenarios I tried so far. Target is to use it on OpenWhisk FaaS platform, so containers should be as small as possible since larger containers have longer cold-start times. Alpine Linux has switched to musl instead of uclibc, but neither is supported by FoundationDB as-is, so adding support would be a continuous task (works until new FoundationDB gets released) unless it gets supported by FoundationDB maintaners. AFAIK, all bindings use libfdb\_c.so C client library, so just replacing it with a newer version it could talk using a newer wire protocol used by some new version of FoundationDB. It could be rewritten in Go, but has the same problem as support for musl. ---
**Author:** ![amirouche](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/amirouche/32/2096_2.png) [@amirouche](https://forums.foundationdb.org/u/amirouche)\ **Post date:** [December 9, 2021, 10:59am UTC](https://forums.foundationdb.org/t/foundationdb-clients-on-alpine-linux/720/4 "2021-12-09T10:59:32Z")
There is a github issue to track musl support, hence possibly alpine: > > > We've fought with glibc versioning issues over time, and it's the reason for our… docker dev environment being centos 6, as it's the oldest glibc (2.12) that has a c++17 toolchain backported to it. Finding a way to link against musl to avoid glibc would free us from having to use older distributions, and be able to use modern tools to produce binaries that could run on ancient systems. > > (Filing to have an issue for this, as it's been discussed a few times, but without anything to track the idea.) ---
**Author:** ![amirouche](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/amirouche/32/2096_2.png) [@amirouche](https://forums.foundationdb.org/u/amirouche)\ **Post date:** [December 9, 2021, 11:44am UTC](https://forums.foundationdb.org/t/foundationdb-clients-on-alpine-linux/720/5 "2021-12-09T11:44:11Z")
I am trying to build foundationdb on Alpine edge x86-64, both branch `release-6.3` and `release-7.0` fail with the following error after calling again `ninja -j1`: ```auto % ninja -j7 .... % ninja -j1 [21/542] Completed 'boost_targetProject' [22/542] Building CXX object documentation/tutorial/CMakeFiles/tutorial.dir/tutorial.actor.g.cpp.o In file included from /root/src/c/foundationdb/flow/flow.h:41, from /root/src/c/foundationdb/documentation/tutorial/tutorial.actor.cpp:22: /root/src/c/foundationdb/flow/Platform.h:422:1: error: 'dev_t' does not name a type; did you mean 'div_t'? 422 | dev_t getDeviceId(std::string path); | ^ ~~~~ | div_t In file included from /root/src/c/foundationdb/flow/flow.h:41, from /root/src/c/foundationdb/documentation/tutorial/tutorial.actor.cpp:22: /root/src/c/foundationdb/flow/Platform.h:653:21: error: 'void* aligned_alloc(size_t, size_t)' was declared 'extern' and later 'static' [-fpermissive] 653 | inline static void* aligned_alloc(size_t alignment, size_t size) { | ^ ~~~~~~~~~~~~ In file included from /usr/include/fortify/stdlib.h:22, from /usr/include/c++/10.3.1/cstdlib:75, from /usr/include/c++/10.3.1/bits/stl_algo.h:59, from /usr/include/c++/10.3.1/functional:65, from /root/src/c/foundationdb/flow/flow.h:35, from /root/src/c/foundationdb/documentation/tutorial/tutorial.actor.cpp:22: /usr/include/stdlib.h:42:7: note: previous declaration of 'void* aligned_alloc(size_t, size_t)' 42 | void *aligned_alloc(size_t, size_t); | ^ ~~~~~~~~~~~~ ``` That happens on an up-to-date alpine edge, with `gcompat` and `gblic` packages installed Anyone can help? ---
**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:** [December 9, 2021, 8:48pm UTC](https://forums.foundationdb.org/t/foundationdb-clients-on-alpine-linux/720/6 "2021-12-09T20:48:35Z")
> [@amirouche](#): > > In file included from /root/src/c/foundationdb/flow/flow.h:41, > from /root/src/c/foundationdb/documentation/tutorial/tutorial.actor.cpp:22: > /root/src/c/foundationdb/flow/Platform.h:422:1: error: ‘dev\_t’ does not name a type; did you mean ‘div\_t’? > 422 | dev\_t getDeviceId(std::string path); > | ^ ~~~~ > | div\_t ```auto #ifndef __dev_t_defined #include #endif /* __dev_t_defined */ ``` > [@amirouche](#): > > ```auto > In file included from /root/src/c/foundationdb/flow/flow.h:41, > from /root/src/c/foundationdb/documentation/tutorial/tutorial.actor.cpp:22: > /root/src/c/foundationdb/flow/Platform.h:653:21: error: 'void* aligned_alloc(size_t, size_t)' was declared 'extern' and later 'static' [-fpermissive] > 653 | inline static void* aligned_alloc(size_t alignment, size_t size) { > | ^ ~~~~~~~~~~~~ > > ``` This aligned\_alloc detection code has caused us trouble a number of times. You’ll need to just kind of play with the macros that it’s using to detect support a bit until you find the right way to detect and handle musl correctly without breaking the other platforms.