The Windows build script uses static linking by default, the
reason being that some tests were failing to build otherwise,
mostly due to unspecified dependencies.
Now that the issue was addressed, we can enable dynamic linking
by default.
Worth mentioning that the Ceph MSI build script already uses
dynamic linking.
While at it, we'll drop some duplicate defaults from
"win32_deps_build.sh". For better clarity, we'll avoid exporting
some "win32_build.sh" variables, instead passing them explicitly
to "win32_deps_build.sh".
Signed-off-by: Lucian Petrut <lpetrut@cloudbasesolutions.com>
winpthreads is a library that emulates the pthreads API using
Windows primitives. It's also used by the mingw/gcc libstdc++
for std::thread.
The issue is that winpthreads isn't well maintained. There
have been numerous bugs that haven't been addressed in years.
Specifically, we've been hitting deadlocks because of the
winpthreads rw lock implementation.
This change will allow building Ceph for Windows using mingw/llvm,
which uses libc++ and doesn't rely on winpthreads.
Signed-off-by: Lucian Petrut <lpetrut@cloudbasesolutions.com>
Most of the Windows documentation is currently included in the
README.windows.rst file.
To make it more accessible, we're moving most of it to the
"doc/" folder, adding the following pages:
* Installing Ceph on Windows
* RBD on Windows
* Windows troubleshooting
We'll keep the build and manual install instructions in
README.windows.rst. Note that ceph-dokan already has a separate
doc page.
Signed-off-by: Lucian Petrut <lpetrut@cloudbasesolutions.com>
This change documents ceph-dokan, describing the prerequisites,
usage and limitations.
Some of this was mentioned in README.windows.rst but is now being
moved to the Ceph doc pages.
Signed-off-by: Lucian Petrut <lpetrut@cloudbasesolutions.com>
This patch simplifies releasing Windows binaries along with debug
symbols.
By default, we're going to provide minimum debug information (-g1).
The symbols are extracted from the binaries and placed in separate
files in the ".debug" folder, which is used by gdb implicitly.
This is more convenient than having separate versions of the binaries,
with or without debug symbols.
Signed-off-by: Lucian Petrut <lpetrut@cloudbasesolutions.com>
At the moment, rbd-wnbd daemons are tied to the Windows
session. When the user logs off or the WinRM remote session
terminates, the daemons are killed.
In order to avoid such issues, we'll delegate the daemon
initialization to the centralized Ceph Windows service.
We're using a named pipe for the Ceph service communication.
We're not using Ceph admin sockets for now since unix sockets
aren't available on Windows Server 2016.
Worth mentioning that the Ceph Windows service will restart
registered mappings when the host reboots based on the command
lines saved in the Windows registries. Writing to the registry
key as well as the service named pipe requires admin privileges.
Signed-off-by: Lucian Petrut <lpetrut@cloudbasesolutions.com>
At the moment, the Windows binaries can only be linked statically.
This is less than ideal since:
* the resulting binaries can be quite large, especially when
including debug symbols
* librados and librbd cannot be used directly by 3rd party apps
* the build duration is increased
In order to do a dynamic build, we'll:
* add an option to win32_build.sh
* fix link order
* dynamically link boost
* disable the "-pie" flag when using Mingw, which generates incorrect
executable entry points
* by default, cmake generates import libs for executables. The issue
is that for rados.exe, it generates librados.dll.a, thus overriding
the librados.dll import library, which breaks the build process.
We'll configure cmake to skip generating import libs for executables.
Signed-off-by: Lucian Petrut <lpetrut@cloudbasesolutions.com>
Distributions such as SUSE and Ubuntu differ significantly in their mingw
environments. This adds an OS=(ubuntu|suse) flag, which can be used to
specify which environment is being used for the build. Unless set explicitly,
the scripts will try to automatically detect it.
Depending on the OS selected, various mingw configuration options (binaries,
library paths, etc.) as well as required packages are determined.
Due to these options being configured at runtime, corresponding cmake
files are generated on the fly.
Signed-off-by: Mike Latimer <mlatimer@suse.com>
Signed-off-by: Lucian Petrut <lpetrut@cloudbasesolutions.com>
Signed-off-by: Alessandro Pilotti <apilotti@cloudbasesolutions.com>
We're going to allow building a zip containing stripped binaries
and skipping the ceph tests. We'll use a separate option rather
than changing the build type so that may generate binaries
containing debug symbols as well as stripped binaries in one shot.
While at it, we're updating the Windows readme.
Signed-off-by: Lucian Petrut <lpetrut@cloudbasesolutions.com>
Signed-off-by: Mike Latimer <mlatimer@suse.com>
For now, we'll only build some of the Ceph CLI binaries when
targeting Windows. In order to avoid over complicating the
cmake files, it was decided that the build script should pick
the targets that are to be compiled.
To keep the build script relatively simple, we'll stop supporting
Ninja, sticking to "make". Another reason for that is that some
targets cannot be compiled using Ninja:
http://paste.openstack.org/raw/796649/
Signed-off-by: Lucian Petrut <lpetrut@cloudbasesolutions.com>
This patch adds a couple of scripts that can be used for
building Ceph for Windows along with its dependencies.
For now, we're going to cross compile it using mingw.
It's supposed to run on Ubuntu (feel free to update
the command that's installing some of the dependencies
within win32_deps_build.sh if you're interested in other
distros).
This commit also adds a short readme, describing the focus of
the Windows porting effort, the building process and the current
status.
Signed-off-by: Lucian Petrut <lpetrut@cloudbasesolutions.com>
Signed-off-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
