Compiling on Linux with anything other than Ubuntu 15.04 / docker possible?

Development FoundationDB Core
1

Hi, so I would like to compile foundationdb without docker, debug through it, look through the code etc. Hands on basically. But I’m not the biggest expert in c++ template programming.
What does this error mean?

13:14:20: Running steps for project fdb2…
13:14:20: Starting: “/usr/bin/make” all
Checking hgVersion.h
Compiling flow/ActorCollection.actor.g.cpp
In file included from flow/actorcompiler.h:39:0,
from flow/ActorCollection.actor.cpp:39:
flow/flow.h: In member function ‘bool ErrorOr::operator==(const ErrorOr&) const’:
flow/flow.h:254:22: error: no match for ‘operator==’ (operand types are ‘const Error’ and ‘const Error’)
return error == o.error && (!present() || get() == o.get());
^~~~
In file included from flow/Arena.h:26:0,
from flow/serialize.h:28,
from flow/flow.h:43,
from flow/actorcompiler.h:39,
from flow/ActorCollection.actor.cpp:39:
flow/FastRef.h:163:6: note: candidate: template bool operator==(const Reference

&, const Reference

&)
bool operator==( const Reference

& lhs, const Reference

& rhs ) {
^~~~~~~~
flow/FastRef.h:163:6: note: template argument deduction/substitution failed:
In file included from flow/actorcompiler.h:39:0,
from flow/ActorCollection.actor.cpp:39:
flow/flow.h:254:27: note: ‘const Error’ is not derived from ‘const Reference

’
return error == o.error && (!present() || get() == o.get());
^~~~~
In file included from flow/serialize.h:28:0,
from flow/flow.h:43,
from flow/actorcompiler.h:39,
from flow/ActorCollection.actor.cpp:39:
flow/Arena.h:526:13: note: candidate: bool operator==(const StringRef&, const StringRef&)
inline bool operator == (const StringRef& lhs, const StringRef& rhs ) {
^~~~~~~~
flow/Arena.h:526:13: note: no known conversion for argument 1 from ‘const Error’ to ‘const StringRef&’
In file included from flow/actorcompiler.h:39:0,
from flow/ActorCollection.actor.cpp:39:
flow/flow.h: In member function ‘bool ErrorOr::operator<(const ErrorOr&) const’:
flow/flow.h:261:37: error: no match for ‘operator<’ (operand types are ‘const Error’ and ‘const Error’)
if (error != o.error) error < o.error;
^~~
In file included from flow/serialize.h:28:0,
from flow/flow.h:43,
from flow/actorcompiler.h:39,
from flow/ActorCollection.actor.cpp:39:
flow/Arena.h:529:13: note: candidate: bool operator<(const StringRef&, const StringRef&)
inline bool operator < ( const StringRef& lhs, const StringRef& rhs ) {
^~~~~~~~
flow/Arena.h:529:13: note: no known conversion for argument 1 from ‘const Error’ to ‘const StringRef&’
flow/generated.mk:71: recipe for target ‘.objs/flow/ActorCollection.actor.g.cpp.o’ failed
make: *** [.objs/flow/ActorCollection.actor.g.cpp.o] Error 1
13:14:22: The process “/usr/bin/make” exited with code 2.
Error while building/deploying project fdb2 (kit: Desktop)
When executing step “Make”
13:14:22: Elapsed time: 00:02.

2

Hey,

Looks to me like your build tools don’t match the expectations required to build.

I’m guessing that is the purpose of having the build performed inside a Docker container, to ensure the environment is correctly configured for the build.

You could probably look at the Dockerfile and with some patience figure out the tooling dependencies.

Likely also the team know what those are

3

There’s a few things that newer compilers don’t like, and you’ve found one of them. I’m sitting on some changes that upgrade the docker image and toolchain to something more recent that I’ll eventually push out once I’m sure it’s stable for everyone. I have vague memory of hitting this error and doing something to fix it, but with a quick skim, I don’t see any diff related to it in my patches, so I’ll just bump up releasing the Dockerfile changes I have on my background queue of tasks.

Until then, just to clarify, you don’t need to do everything FDB-related inside the docker image. It’s a convenient way to pull all the dependencies together required to build, but all runtime dependencies are statically linked into fdbserver, so you can run a docker-built fdbserver on your native linux host (and I do).

4

As the creator of the monstrosity that is the current toolchain, I’m curious: will you be building another cross-compiler so that we can continue to run on ancient versions of linux with ancient libcs, or will you be revisiting the decision not to statically link glibc, or are we going to be dropping compatibility with old linux versions?

I have no strong opinion on this decision, I’m just really curious!

5

Neither! A modern toolchain that produces a statically linked fdbserver, which is runnable against glibc 2.11 is feasible.

The restrictions imposed by having a newer glibc are that, by default, you’ll link against the newer versions of symbols provided by glibc. However, glibc still has the old versions of symbols if you ask for them. The majority of our dependencies on a newer glibc come from the change of memcpy in glibc 2.14 (see this informational rant). Force including a file in all translation units that contains __asm__(".symver memcpy,memcpy@GLIBC_2.2.5"); works around this.

The other nontrivial hassles from libstdc++ being built against a >2.14 glibc, so it also has versioned symbol dependencies. This can be fixed with the stdlibc++ frobnication though, although I’m left feeling unclean from adding to that hack. :stuck_out_tongue:

6

Ahhh… that’s a huge improvement. Nice work!