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>
Due to a rebase mistake, we're no longer fetching WNBD, which
is required by rbd-wnbd.
This commit will take care of cloning WNBD and generating an
import library.
Signed-off-by: Lucian Petrut <lpetrut@cloudbasesolutions.com>
Ceph now requires boost>=1.72. We're going to update the Windows
build script accordingly.
There's been one Boost regression for which we have to cherry-pick
a patch that hasn't been released yet.
Signed-off-by: Lucian Petrut <lpetrut@cloudbasesolutions.com>
When building dependencies, we assume that libs will be placed in the
"lib" dir. Still, some distros might use "lib64" by default.
For this reason, we'll explicitly pass the expected lib path.
At the same time, we're dropping an unnecessary lib copy.
Signed-off-by: Lucian Petrut <lpetrut@cloudbasesolutions.com>
We'll fetch the openssl source code from the github repository,
since the download links from the official website tend to expire
quite often.
At the same time, we'll drop the version from the directory name.
Signed-off-by: Lucian Petrut <lpetrut@cloudbasesolutions.com>
We're using a separate dir when building Ceph dependencies for
Windows. The build script isn't entirely idempotent ATM, so the
easiest thing to do is to just cleanup this dir when rebuilding
dependencies.
If *all* dependencies have been successfully built, this step is
skipped by default.
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>
When building in chroot jail, /proc/cpuinfo may not be available. Switch to
nproc which should be widely available, and does not rely on /proc/cpuinfo.
Signed-off-by: Mike Latimer <mlatimer@suse.com>
At the moment, we assume that the dependencies have been successfully
built if the "build.deps" directory exists.
For convenience reasons, this change will use a file instead,
signaling that we've finished building the dependencies. This will
allow the build process to be resumed when interrupted.
Signed-off-by: Mike Latimer <mlatimer@suse.com>
Signed-off-by: Lucian Petrut <lpetrut@cloudbasesolutions.com>
We'll move network operations (git/wget/curl) under a conditional
check of the source directory.
This will ensure that the script is idempotent and that network
operations can be avoided, using pre-existing sources if available.
Signed-off-by: Mike Latimer <mlatimer@suse.com>
Signed-off-by: Lucian Petrut <lpetrut@cloudbasesolutions.com>
Since the switch to Python 3, a few Cmake flags are no longer required.
While at it, we're dropping a few other unused Cmake flags.
We're going to pass the right target os flag when building lz4
and make sure that it's included in our zip archive.
win32_deps_build.sh needs a small change, fixing a sed command to become
idempotent.
Signed-off-by: Lucian Petrut <lpetrut@cloudbasesolutions.com>
Signed-off-by: Mike Latimer <mlatimer@suse.com>
There's a leftover "cat" command used when patching Boost files,
which will wait for stdin. This commit fixes this issue.
Signed-off-by: Lucian Petrut <lpetrut@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>
This change will allow mapping rbd images on Windows, leveraging the
WNBD[1] Virtual Storport Miniport driver [2].
The behavior and CLI is similar to the Linux rbd-nbd, with a few
notable differences:
* device paths cannot be requested. The disk number and path will
be picked by Windows. If a device path is provided by the user
when mapping an image, it will be used as an identifier, which
can also be used when unmapping the image.
* the "show" command was added, which describes a specific mapping.
This can be used for retrieving the disk path.
* the "service" command was added, allowing rbd-wnbd to run as a
Windows service. All mappings are currently perisistent, being
recreated when the service stops, unless explicitly unmapped.
The service disconnects the mappings when being stopped.
* the "list" command also includes a "status" column.
The purpose of the "service" mode is to ensure that mappings survive
reboots and that the Windows service start order can be adjusted so
that rbd images can be mapped before starting services that may depend
on it, such as VMMS.
The mapped images can either be consumed by the host directly or exposed
to Hyper-V VMs.
While at it, we'll skip building rbd-mirror as it's quite unlikely that
this daemon is going to be used on Windows for now.
[1] https://github.com/cloudbase/wnbd
[2] https://docs.microsoft.com/en-us/windows-hardware/drivers/storage/overview-of-storage-virtual-miniport-drivers
Signed-off-by: Lucian Petrut <lpetrut@cloudbasesolutions.com>
Signed-off-by: Alin Gabriel Serdean <aserdean@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>
