cgofuse dynamically loads the library itself - it doesn't use the OS dynamic loader. This means it needs to know where the library is. This has the advantage that you can run rclone on a mac without osxfuse/fuse-t installed and you'll only get an error when you try to use rclone mount.
I didn't write cgofuse that will be @billziss-gh but I know it quite well!
Sorry for the delay. I'm not involved in either project, just an interested observer !
Happy to test when I can (sporadically). Clean install of that branch required workarounds mentioned here and apparently fixed as of this, which if I'm reading correctly implies building rclone with cgofuse v1.5.1-0.20221118130120-84c0898ad2e0 (or master?) should work on a clean install.
PS if you're not aware:
MacStadium is offering free Macs for developers building open source projects for the Apple platform, including macOS, iOS, tvOS, and watchOS.
I already support rclone through Github Payments but if you were to create a campaign for users (especially mac users) to pool money and buy you one for testing and development, I would happily contribute to that as well.
If you make a fork/branch post here if you like - I have a few notes from testing if that’d be useful (don’t expect anything particularly articulate or coherent)
in general fuse-t read-only mounts have performed superbly - on par at least with the old Google FileStream and macFUSE, but without the 6 Google electr*n helpers/Finder/system crashes on every unmount
Both the FUSE-T developers and @ncw have been awesome (as usual!) in helping to clarify these issues too.
Other than those it has been really great. Feels super fast (as usual) and is more stable. It used to be if you accidentally closed rclone without unmounting, you basically needed to restart. Now the "network" connection just dies and it ends nicely.