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).
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).
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:
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.
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.
There is a github issue to track musl support, hence possibly alpine:
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
:
% 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?
#ifndef __dev_t_defined
#include <sys/types.h>
#endif /* __dev_t_defined */
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.