Compiling couchbase on Debian 10 fails with an error

Couchbase Server
1

I’m trying to compile couchbase on Debian 10.
If I run without preselecting debian9, I end up with cmake getting confused that my jemalloc libs are without je_ prefix (but they do have them, cmake is just not looking right).
If I run with preselecting debian9, I get this:
/usr/bin/ld: …/tlm/deps/flatbuffers.exploded/lib/libflatbuffers.a(idl_parser.cpp.o): relocation R_X86_64_32S against .rodata' can not be used when making a PIE object; recompile with -fPIC /usr/bin/ld: ../tlm/deps/flatbuffers.exploded/lib/libflatbuffers.a(idl_gen_text.cpp.o): relocation R_X86_64_32 against.rodata.str1.1’ can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: …/tlm/deps/flatbuffers.exploded/lib/libflatbuffers.a(util.cpp.o): relocation R_X86_64_PC32 against symbol `_ZNSt8ios_baseC2Ev@@GLIBCXX_3.4’ can not be used when making a PIE object; recompile with -fPIC

Any ideas?

2

I’ve seen similar issues when using pre-compiled dependancies (cbdeps) which don’t match your platform - i.e using debian9 binaries on debian 10.

Try using a flatbuffers package from your distro and see if that resolves the problem.

3

Flatbuffers, unfortunately, is not available as a package from the distro. It’s a library that is so small, that it usually is compiled in statically.

4

Any idea where I have to tweak the compilation flags for it so that I can include the -fPIC ?

5

Actually, I installed debian9 now, and tried it again, same problem. It seems like the precompiled flatbuffers.a is broken.

6

I folded. In this case I compiled flatbuffers out-of-tree myself, and then copied in the libflatbuffers.a manually into the tree.

This is not exactly a foolproof build-operation, but given the complexity of the make scripts, it seems to be the only workable solution until they fix the upstream precompiled version.

7

I don’t believe it’s broken, I just think it’s built (and linked against) GCC 7.3.0, which is possibly different to the default compiler for debian9 (we use the same GCC across the board for all official Linux builds, to ensure consistency).

8

I tried forcing it to gcc-7 on debian9, it did not make a difference.

9

Yeah, it’s not the stock gcc-7; it’s a specific build (we literally check out the same GCC 7.3.0 source, build it ourselves on all the supported Linux platforms, then use that for our own official builds).

If you’re building from source anyways (on an unsupported platform) you probably want to “bring your own” dependancies - either from the standard distro packages, or build from source (if the distro doesn’t provide them).

The pre-built cbdeps simply exist to speed up building the Server on supported platforms (and to ensure exact versioning for release builds).

10

If you’re building from source anyways (on an unsupported platform)

Well, that’s the thing. I first had Debian10, which did not work.
Then I did a fresh Debian9 install, which is supposedly a supported platform, and then I followed instructions to install from git, which results in that libflatbuffers.a issue (I did this twice, once with gcc-6 from Debian9, and once with gcc-7 from Debian9). So even if I have a supported platform, it does not work.

you probably want to “bring your own” dependancies - either from the standard distro packages, or build from source (if the distro doesn’t provide them).

I have no problem with that, but it is a bit unclear which parameters to pass to cmake to make it find/use certain precompiled parts in out-of-tree places.

11

It works if you use the same GCC as the original cbdep was built with :wink:

There’s a script to build individual dependancies in tlm/ - try something like:

PACKAGE=flatbuffers deps/scripts/build-one-cbdep

That should build it and copy into the local cache directory (~/.cbdepscache), where it will take prescience over downloading. You probably want to wipe out your build/ and install/ dirs before retrying the build so it’ll use (and extract) the package you just built.

12

It works if you use the same GCC as the original cbdep was built with

Does that mean that if I would strip gcc from the base debian9 environment, it will automatically download and use your “certified and standard” gcc?

PACKAGE=flatbuffers deps/scripts/build-one-cbdep

That seems to do something. Thanks.
It seems like this is not documented anywhere (except here now).

13

Did a clean git clone, then using the above to supersede the the flatbuffers dependency.
It does not work, it ignores this, and insists on using the downloaded variant.

14

So all the CMake build script does it check for an appropriately named cbdep archive in ~/.cbdepscache, if not present it’ll attempt to download it. The above build-one-cbdep script should copy the file into the correct name / location to be picked up, but if you’ve overridden the distro version or similar you might have to tweak the filename it copies to.

(The name of the archive it searches for / attempts to download should be printed in the CMake output).