[Solved?] Building 7.3 on Windows

Development FoundationDB Core
1

As the release of 7.3 is closing in, I’m trying to build it on windows for development purposes (and to create the fdb_java.dll for JNI). It was working fine for 7.1 (without even building boost), but with 7.3 I get strange static linking errors:

I’m using VS2019 as the readme suggests, but I had to upgrade boost to 1.78 for FDB 7.3.

Building boost:

cd c:\boost
.\bootstrap.bat --with-libraries=all 
.\b2 link=static cxxflags="-std=c++14 -stdlib=libc++ -nostdlib++ -fPIC" linkflags="-stdlib=libc++ -nostdlib++ -static-libgcc -lc++ -lc++abi" -j32 install

Building FDB:

cd c:\build
cmake -G "Visual Studio 16 2019" -A x64 -T ClangCl c:\foundationdb
msbuild /p:Configuration=Release foundationdb.sln /p:UseMultiToolTask=true /p:CL_MPCount=8

Error:

lld-link : error : /failifmismatch: mismatch detected for 'RuntimeLibrary': [c:\build\bindings\c\fdb_c.vcxproj]
  >>> flow.lib(JsonTraceLogFormatter.obj) has value MT_StaticRelease
  >>> libboost_filesystem-vc142-mt-x64-1_78.lib(operations.obj) has value MD_DynamicRelease

This seems strange, as I have built boost to be static (mt in the filename also suggests that), but cmake is complaining that is dyamic? Has anyone succeeded to build it on windows?

2

I managed to progress forward with:

Install Python 3.12
Install CMake: 3.27.6
Install Boost: 1.78

python3 -m pip install setuptools==65.3.0 sphinx-bootstrap-theme==0.8.1 docutils==0.19 sphinx==5.1.1 sphinx-autobuild Jinja2==3.1.2 urllib3==2.0.2

Building boost:
.\bootstrap.bat --with-libraries=all 
.\b2 cxxflags="-std=c++14 -stdlib=libc++ -nostdlib++ -fPIC" linkflags="-stdlib=libc++ -nostdlib++ -static-libgcc -static -lc++ -lc++abi" -j32 link=static threading=multi runtime-link=static release install

Building FDB:
cd c:\
mkdir c:\build
git clone --depth 1 --branch 7.3.19 https://github.com/apple/foundationdb.git
cd c:\build && cmake -G "Visual Studio 16 2019" -A x64 -T ClangCl c:\foundationdb
msbuild /p:Configuration=Release foundationdb.sln /p:UseMultiToolTask=true /p:CL_MPCount=4

After this, the fdb_c.dll, the fdb_java.dll and the fdbcli binaries are correctly built, but the build of the fdbserver fails with:

In file included from C:/foundationdb/fdbserver/workloads/workloads.actor.cpp:25:
  In file included from C:\foundationdb\fdbclient\include\fdbclient/DataDistributionConfig.actor.h:23:
  In file included from C:/foundationdb/fdbclient/include/fdbclient/DataDistributionConfig.actor.h:32:
  In file included from C:\foundationdb\fdbclient\include\fdbclient/KeyBackedRangeMap.actor.h:24:
C:/foundationdb/fdbclient/include/fdbclient/KeyBackedRangeMap.actor.h(131,100): error : no matching constructor for initialization of 'ObjectCodec<DDRangeConfig, _IncludeVersion>' [c:\build\fdbserver\fdbserver.vcxproj]
  C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.29.30133\include\type_traits(598,49): note: in instantiation of default function argument expression for 'KeyBackedRangeMap<Standalone<StringRef>,
  DDRangeConfig, TupleCodec<Standalone<StringRef>>, ObjectCodec<DDRangeConfig, _IncludeVersion>>' required here
  C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.29.30133\include\optional(170,44): note: in instantiation of variable template specialization 'std::is_constructible_v<KeyBackedRangeMap<Standalone
  <StringRef>, DDRangeConfig, TupleCodec<Standalone<StringRef>>, ObjectCodec<DDRangeConfig, _IncludeVersion>>>' requested here
  C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.29.30133\include\optional(171,24): note: while substituting prior template arguments into non-type template parameter [with _Types = <>]
  C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.29.30133\include\optional(155,7): note: while substituting deduced template arguments into function template 'optional' [with _Types = <>, $1 = (no

Any ideas?

3

I managed to build it (windows installer, JNI DLL) after modifying the source to create default initializers for the following structs:

  • for VersionOptions in ObjectCodec
  • for ProtocolVersion in IncludeVersion’

These are used in the KeyBackedRangeMap.

Example:

--- a/fdbclient/include/fdbclient/KeyBackedTypes.actor.h
+++ b/fdbclient/include/fdbclient/KeyBackedTypes.actor.h
@@ -186,7 +186,7 @@ struct BinaryCodec {
 // Codec for using Flatbuffer compatible types via ObjectWriter/ObjectReader
 template <typename T, typename VersionOptions>
 struct ObjectCodec {
-       ObjectCodec(VersionOptions vo) : vo(vo) {}
+       ObjectCodec(VersionOptions vo = VersionOptions{}) : vo(vo) {}
        VersionOptions vo;

        inline Standalone<StringRef> pack(T const& val) const { return ObjectWriter::toValue<T>(val, vo); }

I built it using VS2022 instead of VS2019, so it complained about a bunch of == comparisons between a structs and Optional-s: in

  • tester.actor.cpp
  • DcLag.actor.cpp
  • GcGenerations.actor.cpp

I don’t know c++, but are these comparisons handled on linux via operator overloading, or are these returning always false (a bug)?

Example:

--- a/fdbserver/workloads/GcGenerations.actor.cpp
+++ b/fdbserver/workloads/GcGenerations.actor.cpp
@@ -97,7 +97,7 @@ struct GcGenerationsWorkload : TestWorkload {
                std::vector<IPAddress> remoteIps; // all remote process IPs
                for (const auto& process : g_simulator->getAllProcesses()) {
                        const auto& ip = process->address.ip;
-                       if (process->locality.dcId().present() && process->locality.dcId().get() == g_simulator->remoteDcId &&
+                       if (process->locality.dcId().present() && process->locality.dcId().get() == g_simulator->remoteDcId.get() &&
                            !isCoordinator(coordinators, ip)) {
                                remoteIps.push_back(ip);
                        } else {
diff --git a/flow/include/flow/serialize.h b/flow/include/flow/serialize.h
4

The latest main branch should have fixed these issues, mainly in Fixed compiling foundationdb with the clang 17 compiler by oleg68 · Pull Request #10518 · apple/foundationdb · GitHub