Building windows manifoldc.dll for version 3.0.0

[BasTossings]

Hey all,

I've been trying to get version 3.0.0's C-bindings to build for Windows x64 as a DLL and I've been unsuccessful so far. I tried following the readme (which is very brief on the subject). I found several other discussions touching on the subject, to no avail.

I'm not awfully familiar with either CMAKE or vcpkg, so that isn't helping either.

I keep getting CMAKE and/or build errors relating to dependencies (mostly Clipper2).

Also, it is recommended for Windows to set -DBUILD_SHARED_LIBS=OFF but in that case I only get statically linkable lib files, not dll's.

Any help would be greatly appreciated. Also, I wouldn't mind throwing a comprehensive step-by-step build guide together for Windows users once I get it to build.

Thanks in advance.

P.S: If anyone can point me to binaries for version 3.0.0 for windows that can help me out right now that would also be great.

[pca006132]

Can you post the error log you got?

And regarding -DBUILD_SHARED_LIBS=OFF, did you manage to get something working (lib files) or you still got similar issues with clipper2?

[BasTossings]

Ok so I'll try and document my steps so far as clearly as possible:

Step 1:

git clone --recurse-submodules https://github.com/elalish/manifold.git

Step 2:

cd manifold
cmake . -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF -DMANIFOLD_DEBUG=ON -DMANIFOLD_PAR=TBB -A x64 -B build

Step 3:

Open the generated .\build\manifold.sln in Visual Studio. And build the solution. This succeeds, however, the .\build\bin\Debug folder contains only executables and pdb's, and the .\build\lib\Debug contains only lib files. No 'dll''s to be found anywhere. Not surprising as in the manifoldc project settings, Configuration Type is set to Static library (.lib)

[pca006132]

Yes, so at least this means our existing guide is useful when you don't need a dll :)

And now, can you post the error logs when you set BUILD_SHARED_LIBS=ON?

[BasTossings]

Same thing happens when I replace step 2 with:

cd manifold
cmake --build . --target ALL_BUILD --config Release

[BasTossings]

Ok, so now I set the CMAKE options to what I think they should be for my desired configuration:

Step 1

git clone --recurse-submodules https://github.com/elalish/manifold.git

Step 2

cd manifold
cmake . -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=ON -DMANIFOLD_EXPORT=ON -DMANIFOLD_DEBUG=ON -DMANIFOLD_CROSS_SECTION=ON -DMANIFOLD_CBIND=ON -DMANIFOLD_PAR=TBB -A x64 -B build

And then I get:

CMake Error at cmake/manifoldDeps.cmake:143 (find_package):
  By not providing "Findassimp.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "assimp", but
  CMake did not find one.

  Could not find a package configuration file provided by "assimp" with any
  of the following names:

    assimpConfig.cmake
    assimp-config.cmake

  Add the installation prefix of "assimp" to CMAKE_PREFIX_PATH or set
  "assimp_DIR" to a directory containing one of the above files.  If "assimp"
  provides a separate development package or SDK, be sure it has been
  installed.
Call Stack (most recent call first):
  CMakeLists.txt:207 (include)

-- Configuring incomplete, errors occurred!

[pca006132]

Set -DMANIFOLD_EXPORT=OFF. It requires assimp if you need that to be on.

[BasTossings]

Ok I will try that. But is there still a way to get it to build with that option enabled if I should need that functionality?

[pca006132]

You need to install assimp, somehow.

[elalish]

Also, there is work happening for vcpkg, so you might follow that too. Also those folks are most likely to know how to get Windows builds working: #853 (comment)

[BasTossings]

So with -DMANIFOLD_EXPORT=OFF, CMAKE succeeds, and it builds and produces a manifoldc.dll in build\bindings\c\Release but it's suspiciously small (107kb) and it fails to load. I suspect it is because it expects a dependency dll to be there or something else.

Up until now I've been testing with de manifoldc.dll (which is 1.5MB) that comes with the ManifoldNET NuGet package. But that one is fairly old and doesn't have all the features of Manifold 3.0.0.

[BasTossings]

I also looked at @weianweigan his NuGet GitHub action and I can't see what he is doing differently to get it to build. It's also building an older version of Manifold so it could be that.

[pca006132]

Can you list the files in build\Release?

[BasTossings]

OK, I managed to get it to load at last, apparently the build also produces a separate manifoild.dll that manifoldc.dll has a dependency on. It makes sense I guess, but why doesn't ManifoldNET's manifoldc.dll require it? It seems there, Manifold is statically linked into the manifoldc.dll. No idea how I can get mine to do this, but for now I at least got a working solution. Thanks for the help!

[pca006132]

There are two kinds of consumers: C++ users and C binding users. C++ users should link to manifold.dll, and C binding users should link to manifoldc.dll which transitively links to manifold.dll. We expect distros to ship both manifold.dll/so and manifoldc.dll/so, so we don't statically link the main library into manifoldc.dll/so to avoid bloat.

And do you want to document the build process as well as where to find the dll files? Feel free to open a PR for that (add to the windows section on our README I guess)

[weianweigan]

why doesn't ManifoldNET's manifoldc.dll require it?

---

I checked the dependencies of manifoldc.dll. There is no manifold.dll. The DLLs that manifoldc.dll depends on should be the following:

[pca006132]

The reason is that previously, ManifoldNET builds manifold as a static library (-DBUILD_SHARED_LIB=OFF), but manifoldc was forced to be a shared library, so its dll file includes all the static library content.

However, in v3.0, we think that some users may want to use the C binding as a static library, e.g. rust which loves static linking. So if you build manifold as a static library, you get a static manifoldc library, instead of a dll.

If users really want to get a single dll for c binding, we can modify the cmake code to build that, but I am not sure if that is a good idea...