fuse filesystems should support fuse4x as dependency

[drkp (Dan Ports)]

I just added ports for Fuse4X, a fork of MacFUSE that provides 64-bit kernel support among other features. It should be possible to use any of our existing fuse filesystem to run atop fuse4x, although macfuse should remain the default.

At a minimum, existing ports will need to change their port:macfuse dependency to path:lib/pkgconfig/fuse.pc:macfuse

Some other problems ports might run into:

• fuse4x's library is -lfuse4x not -lfuse; ports using pkgconfig should figure this out on their own
• macfuse includes emulation of named semaphores, fuse4x doesn't
• fuse4x's framework is in a different location (and in the fuse4x-framework port)

I am looking through the ports now to see if they work with fuse4x, and will report here if any changes seem to be necessary. I already fixed sshfs in r81150.

[anatol (Anatol Pomozov)]

I already fixed sshfs in r81150

It is better to use updated version of sshfs from fuse4x ​https://github.com/fuse4x/sshfs It already includes fixes you provide plus updates sshfs to version 2.3

[drkp (Dan Ports)]

bindfs, curlftpfs, fuse-bindings-python, fuse-bindings-python25, mhddfs, mp3fs, and ntfs-3g appear to work OK after just changing the dependency to path:lib/pkgconfig/fuse.pc:macfuse. I made that change in r81151.

gmailfs uses the Python interface, so it doesn't need to depend on macfuse directly; fuse-bindings-python2.5 is enough. I removed the macfuse dependency in r81152

encfs, ext2fuse, procfs, and spotlightfs may need some more work. (Actually, procfs may be pretty much broken altogether...)

[drkp (Dan Ports)]

Replying to anatol.pomozov@…:

I already fixed sshfs in r81150

It is better to use updated version of sshfs from fuse4x ​https://github.com/fuse4x/sshfs It already includes fixes you provide plus updates sshfs to version 2.3

Thanks, but I'm trying to make only one change at a time. I'll consider updating to 2.3 later.

[anatol (Anatol Pomozov)]

encfs works fine with fuse4x. There is a prebuild binary that I use ​https://groups.google.com/forum/#!topic/fuse4x/w0s6KNWwoK4

[drkp (Dan Ports)]

Yes, the only issue with encfs seems to be that its configure script has -lfuse hardcoded instead of using pkgconfig. Here's a patch to fix that. Markus, is it OK to apply this?

[raimue (Rainer Müller)]

The gmailfs port did not work with current gmail anyway. Port removed in r81165.

[anatol (Anatol Pomozov)]

fuse4x's library is -lfuse4x not -lfuse; ports using pkgconfig should figure this out on their own

would it be better if fuse4x install fuse.pc instead of fuse4x.pc, as well as libfuse.dylib instead of libfuse4x.dylib? So Portfiles stay unchanged...

You also mentioned about making fuse4x library ABI compatible with macfuse. It looks reasonable to me.

[drkp (Dan Ports)]

Replying to anatol.pomozov@…:

would it be better if fuse4x install fuse.pc instead of fuse4x.pc, as well as libfuse.dylib instead of libfuse4x.dylib? So Portfiles stay unchanged...

You also mentioned about making fuse4x library ABI compatible with macfuse. It looks reasonable to me.

It does get installed as fuse.pc, and I would *not* change that.

Installing the library as libfuse instead of libfuse4x would be OK, but I don't think we need to; things seem fine as it is.

[anatol (Anatol Pomozov)]

Installing the library as libfuse instead of libfuse4x would be OK, but I don't think we need to; things seem fine as it is.

My point is that it would be better to change fuse4x only once than move "choose libfuse vs libfuse4x" logic to existing and future Portfiles.

Original fuse installs libfuse.dylib. I changed it in fuse4x to allow macfuse and fuse4x coexist together. As macports does not allow to coexist these 2 ports then I do not see any reason why libfuse4x should be installed instead of libfuse.

[bonoba@…]

Cc Me!

[anatol (Anatol Pomozov)]

Change library name from libfuse4x to libfuse

[anatol (Anatol Pomozov)]

Dan,

I just added a patch that changes the library name to libfuse. This eliminates patches to portfiles that use '-lfuse'.

[anatol (Anatol Pomozov)]

With my change above encfs and ext2fuse work fine. If I understand correctly the only change need to be done to these ports is

change port:macfuse to path:lib/libfuse.dylib:macfuse

[anatol (Anatol Pomozov)]

There are 2 more ports left: procfs and spotlightfs. My question - do we really need it in macports? These filesystems are marked as deprecated on macfuse page. These fs were created by Amit as an example for OSX book I doubt that many people use it. The portfiles also do not have maintainer.

Is it time to clean it up?

[drkp (Dan Ports)]

OK, I committed the patch to rename the lib to libfuse in r81459, revbumped the ports that can already be built with fuse4x in r81460, and changed the depspec on encfs and ext2fuse in r81461.

That covers everything except procfs and spotlightfs, which are sufficiently broken that we need to either fix them or (more likely) remove the ports. But that's a separate issue.

[tristan.klocke@…]

Tried to build with the new dependencies but it failed. Here is the ticket and log: ​https://trac.macports.org/attachment/ticket/30428/main.3.log

[tristan.klocke@…]

sshfs build error on lion (10.7)

[tristan.klocke@…]

Same for sshfs (see mainlog). Only encfs and ext2fuse went fine.

[drkp (Dan Ports)]

Hmm, I see -DFreeBSD=10 in the CFLAGS, which isn't right; that should only be set for macfuse, not fuse4x. What is the output of pkgconfig --cflags fuse?

[anatol (Anatol Pomozov)]

Replying to tristan.klocke@…:

Tried to build with the new dependencies but it failed. Here is the ticket and log: ​https://trac.macports.org/attachment/ticket/30428/main.3.log

From the error message I see

:info:build Undefined symbols for architecture x86_64:
526	:info:build   "_fuse_sem_destroy", referenced from:
527	:info:build       _sshfs_read in sshfs-sshfs.o
528	:info:build       _sshfs_release in sshfs-sshfs.o
529	:info:build       _process_requests in sshfs-sshfs.o
530	:info:build       _clean_req in sshfs-sshfs.o
531	:info:build       _sshfs_read_end in sshfs-sshfs.o
532	:info:build       _sftp_request_wait in sshfs-sshfs.o
533	:info:build       _submit_read in sshfs-sshfs.o
534	:info:build       ...

the compiler found function _fuse_sem_destroy defined in *macfuse* headers, but it was not able to find it in the dylib.

I also see -DFreeBSD=10 which is absent in the fuse4x fuse4x.pc file.

This makes me think that the issue is you have headers and fuse.pc file from macfuse, but dylib from fuse4x.