macOS build instructions in README don't work (again)
I read through #1539 and did a little experimenting, but am stuck with a cairo issue:
/Users/rcarmo/Build/solvespace/extlib/cairo/src/cairo-mutex-impl-private.h:262:3: error: "XXX: No mutex implementation found. Cairo will not work with multiple threads. Define CAIRO_NO_MUTEX to 1 to acknowledge and accept this limitation and compile cairo without thread-safety support."
262 | # error "XXX: No mutex implementation found. Cairo will not work with multiple threads. Define CAIRO_NO_MUTEX to 1 to acknowledge and accept this limitation and compile cairo without thread-safety support."
I think this is due to cmake not setting the right values, since I am trying to build with:
cmake .. -DCMAKE_BUILD_TYPE=Release -DENABLE_OPENMP=ON -DCMAKE_POLICY_VERSION_MINIMUM=3.5
This is because if I do it without the policy version I get this:
...
-- Using in-tree mimalloc
CMake Error at extlib/mimalloc/CMakeLists.txt:1 (cmake_minimum_required):
Compatibility with CMake < 3.5 has been removed from CMake.
Update the VERSION argument <min> value. Or, use the <min>...<max> syntax
to tell CMake that the project requires at least <min> but has been updated
to work with policies introduced by <max> or earlier.
Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway.
-- Configuring incomplete, errors occurred!
My cmake is 4.0.1, by the way (and I have all the latest brew tooling, running on Sequoia)
CMake >= 4.0.0 introduced an incompatibility with existing CMake projects due to dropping support for versions < 3.5 (see the discussion in #1558). Some of our dependencies (such as zlib) still haven't released a version that's compatible with the new CMake >= 4.0.0 policies, which is why we didn't bother updating any of our dependencies yet.
In any case, the CMake recommendation to set back the policy to 3.5 is bad, and breaks our CMake rules. The best course of action is to downgrade your local CMake to 3.31.6, but if you can't do that, try setting -DCMAKE_POLICY_VERSION_MINIMUM to 3.13, which worked for me (although note that this hack is not supported in any way, and isn't guaranteed to work).
Thanks, I completely get that (I actually went and tried to update Cairo, which went about as you'd expect...)
In the meantime I managed to build on Fedora and had a go at #206 via #1580 - which was seriously bugging me.
Next evening I'll have another go at a Mac build and report back, since I think it would be important to have updated Mac instructions/builds.
As a workaround try without -DENABLE_OPENMP=ON I think some people had problems with it on Macs - just a guess...
I tried to build it on macOS with CMake 3.31.7, but I'm getting several errors like:
CMake Error at CMakeLists.txt:206 (add_subdirectory):
The source directory
/Users/adrian/Tests/solvespace/extlib/libdxfrw
does not contain a CMakeLists.txt file.
Any ideas?
I tried to build it on macOS with CMake 3.31.7, but I'm getting several errors like:
CMake Error at CMakeLists.txt:206 (add_subdirectory): The source directory
/Users/adrian/Tests/solvespace/extlib/libdxfrwdoes not contain a CMakeLists.txt file.
Any ideas?
My guess is that you did not clone/update the submodules. Did you follow this? https://github.com/solvespace/solvespace?tab=readme-ov-file#via-source-code
For extra ideas look here: https://github.com/solvespace/solvespace/blob/960f08b34ca5f5db30c3981d1708897bac156c35/.github/scripts/build-macos.sh#L35
If it still does not work paste your cmake command together with the output.
Arg, I did at one point, but then I checked out the repo again from GitHub. Of course then I forgot 🤦♂️. Thanks!
Since it doesn't work with CMake 4 yet, I'm trying to build it with CMake 3.31.6 via Nix. Getting those errors now:
In file included from /Users/adrian/Tests/solvespace/extlib/zlib/zutil.c:10:
In file included from /Users/adrian/Tests/solvespace/extlib/zlib/gzguts.h:21:
/nix/store/yi5049jrgkd1rmv18bax1m6ichwpfcv0-apple-sdk-11.3/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdio.h:210:7: error: expected identifier or '('
210 | FILE *fdopen(int, const char *) __DARWIN_ALIAS_STARTING(__MAC_10_6, __IPHONE_2_0, __DARWIN_ALIAS(fdopen));
| ^
/Users/adrian/Tests/solvespace/extlib/zlib/zutil.h:140:33: note: expanded from macro 'fdopen'
140 | # define fdopen(fd,mode) NULL /* No fdopen() */
| ^
/nix/store/fh4c0c26lwg4xap9bynxqmdzw9wk7qv2-clang-wrapper-19.1.7/resource-root/include/__stddef_null.h:26:16: note: expanded from macro 'NULL'
26 | #define NULL ((void*)0)
| ^
In file included from /Users/adrian/Tests/solvespace/extlib/zlib/zutil.c:10:
In file included from /Users/adrian/Tests/solvespace/extlib/zlib/gzguts.h:21:
/nix/store/yi5049jrgkd1rmv18bax1m6ichwpfcv0-apple-sdk-11.3/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdio.h:210:7: error: expected ')'
/Users/adrian/Tests/solvespace/extlib/zlib/zutil.h:140:33: note: expanded from macro 'fdopen'
140 | # define fdopen(fd,mode) NULL /* No fdopen() */
| ^
/nix/store/fh4c0c26lwg4xap9bynxqmdzw9wk7qv2-clang-wrapper-19.1.7/resource-root/include/__stddef_null.h:26:16: note: expanded from macro 'NULL'
26 | #define NULL ((void*)0)
| ^
/nix/store/yi5049jrgkd1rmv18bax1m6ichwpfcv0-apple-sdk-11.3/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdio.h:210:7: note: to match this '('
/Users/adrian/Tests/solvespace/extlib/zlib/zutil.h:140:33: note: expanded from macro 'fdopen'
140 | # define fdopen(fd,mode) NULL /* No fdopen() */
| ^
/nix/store/fh4c0c26lwg4xap9bynxqmdzw9wk7qv2-clang-wrapper-19.1.7/resource-root/include/__stddef_null.h:26:15: note: expanded from macro 'NULL'
26 | #define NULL ((void*)0)
| ^
In file included from /Users/adrian/Tests/solvespace/extlib/zlib/zutil.c:10:
In file included from /Users/adrian/Tests/solvespace/extlib/zlib/gzguts.h:21:
/nix/store/yi5049jrgkd1rmv18bax1m6ichwpfcv0-apple-sdk-11.3/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdio.h:210:7: error: expected ')'
210 | FILE *fdopen(int, const char *) __DARWIN_ALIAS_STARTING(__MAC_10_6, __IPHONE_2_0, __DARWIN_ALIAS(fdopen));
| ^
/Users/adrian/Tests/solvespace/extlib/zlib/zutil.h:140:33: note: expanded from macro 'fdopen'
140 | # define fdopen(fd,mode) NULL /* No fdopen() */
| ^
/nix/store/fh4c0c26lwg4xap9bynxqmdzw9wk7qv2-clang-wrapper-19.1.7/resource-root/include/__stddef_null.h:26:22: note: expanded from macro 'NULL'
26 | #define NULL ((void*)0)
| ^
/nix/store/yi5049jrgkd1rmv18bax1m6ichwpfcv0-apple-sdk-11.3/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdio.h:210:7: note: to match this '('
/Users/adrian/Tests/solvespace/extlib/zlib/zutil.h:140:33: note: expanded from macro 'fdopen'
140 | # define fdopen(fd,mode) NULL /* No fdopen() */
| ^
/nix/store/fh4c0c26lwg4xap9bynxqmdzw9wk7qv2-clang-wrapper-19.1.7/resource-root/include/__stddef_null.h:26:14: note: expanded from macro 'NULL'
26 | #define NULL ((void*)0)
| ^
3 errors generated.
make[2]: *** [extlib/zlib/CMakeFiles/zlibstatic.dir/build.make:275: extlib/zlib/CMakeFiles/zlibstatic.dir/zutil.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:523: extlib/zlib/CMakeFiles/zlibstatic.dir/all] Error 2
make: *** [Makefile:156: all] Error 2
The errors in zlib (and LibPNG) can bve solved by updating them see here: https://github.com/solvespace/solvespace/issues/1595#issuecomment-3155132606
I have a branch where I updated zlib, libpng, mimalloc, pixman, and cairo to their latest versions. I haven't submitted it because I also want to get ANGLE updated first, and because I didn't want to bombard the projects with PRs, seeing as I already have a bunch of them open, and the dependencies update is quite a large change.
Indeed... and I have an (unfinished) branch where I updated libdxfrw... sorry for not looking into all your open PR-s - time is... finite...
No worries. I didn't mean it as a criticism, and I'm sorry if it came out this way. Just wanted to let you know that I'm working on it.
@iscgar n.p.
@phkahler Here is a pull request updating libdxfrw https://github.com/solvespace/libdxfrw/pull/15
After it is merged I will create a pull request here to use it (needs a very small change in exportvector.cpp and update the submodule),
After it is merged I will create a pull request here to use it (needs a very small change in
exportvector.cppand update the submodule),
@ruevs Ready :-)
Shoud be fixed - see here https://github.com/solvespace/solvespace/pull/1611#issuecomment-3172851903
@rcarmo @ad-si please test.