Build compatibility for macOS

[hyiltiz]

Would it work with macOS? Looking at the dependencies, they all seem compatible with macOS except fuse3. Would macFuse act as a drop-in replacement for it, or maybe one may be able to put a thin shim layer to abstract away differences between fuse3 and macFuse?

Any interest in cross-platform compatibility, and suggestions for directions to go for this?

[hyiltiz]

I successfully build and past all tests using ccache and ninja in M1 (arm64) hosting Debian testing (Linux 6.x arm64). Would be awesome to provide arm64 binaries with the releases.

[akrabu]

Any chance for a Homebrew formula for MacOS? :)

[mhx]

Would it work with macOS? Looking at the dependencies, they all seem compatible with macOS except fuse3. Would macFuse act as a drop-in replacement for it, or maybe one may be able to put a thin shim layer to abstract away differences between fuse3 and macFuse?

That's a good question. I'd definitely love to have support for both macOS and Windows, and both macFuse and winfsp (see also #85) look very promising.

Any interest in cross-platform compatibility, and suggestions for directions to go for this?

Definitely. As a first step, I'd be more than happy if the existing tools worked more or less as-is on all platforms. Stuff like Explorer/Finder integration would be neat, but wouldn't be a priority, and likely even be separate projects.

I successfully build and past all tests using ccache and ninja in M1 (arm64) hosting Debian testing (Linux 6.x arm64). Would be awesome to provide arm64 binaries with the releases.

That would indeed be awesome, but I currently lack the hardware to build these.

[hyiltiz]

Without changing anything, the build fails since we need to at least pipe the build system to depend on different implementations of fuse.

[mhx]

That would indeed be awesome, but I currently lack the hardware to build these.

Actually not true. :)

I built arm64 binaries using qemu & docker.

[hyiltiz]

I was able to build arm64 binaries as well, but does your binaries use macOS specific fuse implementation as well? It might have runtime errors if not.

[mhx]

No, no Mac binaries at this point (hence the Linux part of the name).

[mhx]

I've managed to get DwarFS to build on macOS with all tests passing after a few tweaks in the experimental/osx-build branch. Since my iMac is ancient, I'd appreciate if someone could test the build instructions with more recent hardware / OS. The instructions are for building a "fat" binary including x64/arm64 support, but I've only tested the x64 part.

Also, if anyone feels confident about turning this into a Homebrew recipe, I'd very much appreciate it. All the dependencies are listed either in the instructions or in the vcpkg.json and the cmake arguments are listed in cmake/osx.sh. When building with Homebrew, a regular (non-fat) binary is probably sufficient, so all the lipo-dir-merge.py magic in osx.sh can likely be skipped.

[hyiltiz]

There is a typo in the instruction for spelling git clone. Also, the cmake/osx.sh file hardcodes $HOME/git/, while it may be better to set up something like BUILD_PROJECT_DIR which is the current directory or something. After fixing the above, when I ran sh ../cmake/osx.sh, I got :

> sh ../cmake/osx.sh
-- The C compiler identification is AppleClang 15.0.0.15000100
-- The CXX compiler identification is AppleClang 15.0.0.15000100
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- REAL_SOURCE_DIR: /private/tmp/dwarf-test/dwarfs (/tmp/dwarf-test/dwarfs)
-- GIT_TOPLEVEL: /private/tmp/dwarf-test/dwarfs (/private/tmp/dwarf-test/dwarfs)
-- PRJ_GIT_REV: f669552516
-- PRJ_GIT_DATE: 2024-01-23
CMake Error at CMakeLists.txt:172 (find_program):
  Could not find RONN_EXE using the following names: ronn

-- Configuring incomplete, errors occurred!

[mhx]

Thanks for the feedback. I've no idea how that typo happened.

$HOME/git isn't quite hardcoded, it's just used as a default for 3 variables. But I've made it a bit easier so you just have to set VCPKG_BASEDIR if you want to use something different from $HOME/git.

About ronn, I forgot to list that as something to install via Homebrew.

I've updated the branch with fixes / additions.

[hyiltiz]

Also missing the following build dependencies: upx. After installing that with Homebrew, the build with ninja continued with a few dozen harmless warnings, ultimately failed with:

3 warnings generated.
[406/613] Linking CXX executable bin/thrift1
ld: warning: ignoring duplicate libraries: 'lib/libcompiler_ast.a', 'lib/libcompiler_base.a'
ld: warning: ignoring duplicate libraries: 'lib/libcompiler_ast.a', 'lib/libcompiler_base.a'
[443/613] Linking CXX static library libfeatures_thrift.a
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: for architecture: x86_64 file: libfeatures_thrift.a(features_data.cpp.o) has no symbols
[456/613] Generating src/dwarfs/dwarfsck_manpage.cpp
FAILED: src/dwarfs/dwarfsck_manpage.cpp /tmp/dwarf-test/dwarfs/build/src/dwarfs/dwarfsck_manpage.cpp
cd /tmp/dwarf-test/dwarfs/build && /tmp/dwarf-test/.venv/bin/python3 /tmp/dwarf-test/dwarfs/cmake/render_manpage.py dwarfsck /tmp/dwarf-test/dwarfs/doc/dwarfsck.md /tmp/dwarf-test/dwarfs/build/src/dwarfs/dwarfsck_manpage.cpp
Traceback (most recent call last):
  File "/tmp/dwarf-test/dwarfs/cmake/render_manpage.py", line 1, in <module>
    import mistletoe
ModuleNotFoundError: No module named 'mistletoe'
[457/613] Generating src/dwarfs/mkdwarfs_manpage.cpp
FAILED: src/dwarfs/mkdwarfs_manpage.cpp /tmp/dwarf-test/dwarfs/build/src/dwarfs/mkdwarfs_manpage.cpp
cd /tmp/dwarf-test/dwarfs/build && /tmp/dwarf-test/.venv/bin/python3 /tmp/dwarf-test/dwarfs/cmake/render_manpage.py mkdwarfs /tmp/dwarf-test/dwarfs/doc/mkdwarfs.md /tmp/dwarf-test/dwarfs/build/src/dwarfs/mkdwarfs_manpage.cpp
Traceback (most recent call last):
  File "/tmp/dwarf-test/dwarfs/cmake/render_manpage.py", line 1, in <module>
    import mistletoe
ModuleNotFoundError: No module named 'mistletoe'
[458/613] Generating src/dwarfs/dwarfs_manpage.cpp
FAILED: src/dwarfs/dwarfs_manpage.cpp /tmp/dwarf-test/dwarfs/build/src/dwarfs/dwarfs_manpage.cpp
cd /tmp/dwarf-test/dwarfs/build && /tmp/dwarf-test/.venv/bin/python3 /tmp/dwarf-test/dwarfs/cmake/render_manpage.py dwarfs /tmp/dwarf-test/dwarfs/doc/dwarfs.md /tmp/dwarf-test/dwarfs/build/src/dwarfs/dwarfs_manpage.cpp
Traceback (most recent call last):
  File "/tmp/dwarf-test/dwarfs/cmake/render_manpage.py", line 1, in <module>
    import mistletoe
ModuleNotFoundError: No module named 'mistletoe'
[459/613] Generating src/dwarfs/dwarfsextract_manpage.cpp
FAILED: src/dwarfs/dwarfsextract_manpage.cpp /tmp/dwarf-test/dwarfs/build/src/dwarfs/dwarfsextract_manpage.cpp
cd /tmp/dwarf-test/dwarfs/build && /tmp/dwarf-test/.venv/bin/python3 /tmp/dwarf-test/dwarfs/cmake/render_manpage.py dwarfsextract /tmp/dwarf-test/dwarfs/doc/dwarfsextract.md /tmp/dwarf-test/dwarfs/build/src/dwarfs/dwarfsextract_manpage.cpp
Traceback (most recent call last):
  File "/tmp/dwarf-test/dwarfs/cmake/render_manpage.py", line 1, in <module>
    import mistletoe
ModuleNotFoundError: No module named 'mistletoe'
[460/613] Building CXX object CMakeFiles/dwarfs_categorizer.dir/src/dwarfs/categorizer/pcmaudio_categorizer.cpp.o
ninja: build stopped: subcommand failed.

After installing it via pip3 install mistletoe, I got undefined symbol error (see log file). Possibly related to M1 and macOS (14.1.2) version? error.log.tgz

[mhx]

Ah yes, I need to get rid of the upx dependency — from what I've read, it's pretty unreliable on macOS.

The mistletoe dependency was mentioned in the installation instructions, I think.

About the linker error, that's really odd. It looks like for some reason FLAC was built without arm64 support. Can you check with the lipo tool? On my machine, I see:

% lipo -info ../../@vcpkg-install/uni-osx/lib/libFLAC++.a
Architectures in the fat file: ../../@vcpkg-install/uni-osx/lib/libFLAC++.a are: x86_64 arm64 

Also, your paths look very different from mine:

/tmp/dwarf-test/vcpkg/packages/libflac_x64-osx/lib/libFLAC++.a

Any idea what happened to the uni-osx directory that should have been created in the

../cmake/osx.sh rebuild-vcpkg

step? It looks like you're using the x64 libraries instead of the merged ones.

[hyiltiz]

The paths are slightly different since I did not put the project under ~/git, but rather in /tmp/dwarf-test/. Did a git reset --hard HEAD~20 then followed your instruction in the branch (after a git pull). Still got similar results.

As you noticed, somehow (some of ?) the libraries built for x86_64 rather than arm64 according to the error message.

(.venv) /p/t/d/d/build 〉ls ../../@vcpkg-install/uni-osx/lib/libFL*                                                                                                                                                                               dwarf-test  2024-01-25 02:25:10
───┬──────────────────────────────────────────────┬──────┬──────────┬───────────────
 # │                     name                     │ type │   size   │   modified
───┼──────────────────────────────────────────────┼──────┼──────────┼───────────────
 0 │ ../../@vcpkg-install/uni-osx/lib/libFLAC++.a │ file │ 250.0 KB │ 8 minutes ago
 1 │ ../../@vcpkg-install/uni-osx/lib/libFLAC.a   │ file │ 767.6 KB │ 8 minutes ago
───┴──────────────────────────────────────────────┴──────┴──────────┴───────────────
(.venv) /p/t/d/d/build 〉lipo -info ../../@vcpkg-install/uni-osx/lib/libFLAC++.a                                                                                                                                                                  dwarf-test  2024-01-25 02:25:53
Architectures in the fat file: ../../@vcpkg-install/uni-osx/lib/libFLAC++.a are: x86_64 arm64
(.venv) /p/t/d/d/build 〉lipo -info /tmp/dwarf-test/vcpkg/packages/libflac_x64-osx/lib/libFLAC++.a                                                                                                                                                dwarf-test  2024-01-25 02:26:00
Non-fat file: /tmp/dwarf-test/vcpkg/packages/libflac_x64-osx/lib/libFLAC++.a is architecture: x86_64
(.venv) /p/t/d/d/build 〉diff ../../@vcpkg-install/uni-osx/lib/libFLAC++.a /tmp/dwarf-test/vcpkg/packages/libflac_x64-osx/lib/libFLAC++.a                                                                                                         dwarf-test  2024-01-25 02:26:13
Binary files ../../@vcpkg-install/uni-osx/lib/libFLAC++.a and /tmp/dwarf-test/vcpkg/packages/libflac_x64-osx/lib/libFLAC++.a differ

Also, I did not install the python library mistletoe in the global --user pip directory, but instead created a python3.10 -m venv environment. That allowed the build to proceed until some very late stages of ninja.

The build environment used for this test:

(.venv) /p/t/d/d/build 〉ld -v                                                                                                                                                                                                                    dwarf-test  2024-01-25 02:29:22
@(#)PROGRAM:ld  PROJECT:dyld-1022.1
BUILD 13:21:42 Nov 10 2023
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h
will use ld-classic for: armv6 armv7 armv7s arm64_32 i386 armv6m armv7k armv7m armv7em
LTO support using: LLVM version 15.0.0 (static support for 29, runtime is 29)
TAPI support using: Apple TAPI version 15.0.0 (tapi-1500.0.12.8)
Library search paths:
Framework search paths:
(.venv) /p/t/d/d/build 〉clang --version                                                                                                                                                                                                          dwarf-test  2024-01-25 02:29:24
Apple clang version 15.0.0 (clang-1500.1.0.2.5)
Target: arm64-apple-darwin23.1.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
(.venv) /p/t/d/d/build 〉gcc --version                                                                                                                                                                                                            dwarf-test  2024-01-25 02:29:29
Apple clang version 15.0.0 (clang-1500.1.0.2.5)
Target: arm64-apple-darwin23.1.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
(.venv) /p/t/d/d/build 〉ninja --version                                                                                                                                                                                                          dwarf-test  2024-01-25 02:29:31
1.11.1
(.venv) /p/t/d/d/build 〉cmake --version                                                                                                                                                                                                          dwarf-test  2024-01-25 02:29:39
cmake version 3.26.4

CMake suite maintained and supported by Kitware (kitware.com/cmake).

[mhx]

The paths are slightly different since I did not put the project under ~/git, but rather in /tmp/dwarf-test/.

I know, but still, the bits after that are significantly different.

Did a git reset --hard HEAD~20 then followed your instruction in the branch (after a git pull).

git fetch
git reset --hard origin/experimental/osx-build

Still got similar results.

As you noticed, somehow (some of ?) the libraries built for x86_64 rather than arm64 according to the error message.

(.venv) /p/t/d/d/build 〉ls ../../@vcpkg-install/uni-osx/lib/libFL*                                                                                                                                                                               dwarf-test  2024-01-25 02:25:10
───┬──────────────────────────────────────────────┬──────┬──────────┬───────────────
 # │                     name                     │ type │   size   │   modified
───┼──────────────────────────────────────────────┼──────┼──────────┼───────────────
 0 │ ../../@vcpkg-install/uni-osx/lib/libFLAC++.a │ file │ 250.0 KB │ 8 minutes ago
 1 │ ../../@vcpkg-install/uni-osx/lib/libFLAC.a   │ file │ 767.6 KB │ 8 minutes ago
───┴──────────────────────────────────────────────┴──────┴──────────┴───────────────
(.venv) /p/t/d/d/build 〉lipo -info ../../@vcpkg-install/uni-osx/lib/libFLAC++.a                                                                                                                                                                  dwarf-test  2024-01-25 02:25:53
Architectures in the fat file: ../../@vcpkg-install/uni-osx/lib/libFLAC++.a are: x86_64 arm64
(.venv) /p/t/d/d/build 〉lipo -info /tmp/dwarf-test/vcpkg/packages/libflac_x64-osx/lib/libFLAC++.a                                                                                                                                                dwarf-test  2024-01-25 02:26:00
Non-fat file: /tmp/dwarf-test/vcpkg/packages/libflac_x64-osx/lib/libFLAC++.a is architecture: x86_64
(.venv) /p/t/d/d/build 〉diff ../../@vcpkg-install/uni-osx/lib/libFLAC++.a /tmp/dwarf-test/vcpkg/packages/libflac_x64-osx/lib/libFLAC++.a                                                                                                         dwarf-test  2024-01-25 02:26:13
Binary files ../../@vcpkg-install/uni-osx/lib/libFLAC++.a and /tmp/dwarf-test/vcpkg/packages/libflac_x64-osx/lib/libFLAC++.a differ

Well, that all looks fine to me. The uni-osx lib is a fat file, the others are not.

What I don't understand is how the build picks up the non-fat files from a completely different directory instead of the uni-osx ones given that cmake/osx.sh has:

-DCMAKE_PREFIX_PATH=$VCPKG_INSTALL_ROOT/uni-osx

In the log you sent, the linker is trying to link against:

/tmp/dwarf-test/vcpkg/packages/libflac_x64-osx/lib/libFLAC++.a

But it should rather link against the library in the uni-osx tree. Did you wipe the build directory before trying again? If not, cmake might have use some cached config from the previous run.

[hyiltiz]

Yes, I rm -rf builded directory then redid the cmake and ninja builds. I seem to have two copies of some directory tree and somehow the incorrect tree is being picked up by System /usr/bin/ld. Maybe you can try your build script via Github Actions in a fork repo?

[mhx]

I just had a call with a friend who has an M2 Macbook and we went through the instructions together. Other than the fact that we also had to install cmake via homebrew, the build went about without any issues; they were just copy/pasting the commands from the instructions.

In any case, we'll try to come up with a dwarfs formula for homebrew so people don't have to go through these instructions if they only want to install the tools.

I'll update this issue if there's any news regarding the macOS build.

Thanks for your help!

[mhx]

Thanks to @txkxgit's support, we've completely overhauled the build instructions for macOS.

All the vcpkg stuff is gone. What remains is just installing dependencies through Homebrew and setting up a virtualenv for mistletoe. I'd appreciate if you could give it another try. The branch is still experimental/osx-build, so for now you'll have to also do:

$ git checkout experimental/osx-build

after cloning.

[mhx]

I hope this is fixed with the v0.9.0 release. Please reopen or file a new issue if there are any problems.