encfs depends on obsolete port fuse4x

[jrblevin@…]

When installing encfs, I receive an error message about fuse4x being replaced by osxfuse. Possibly the dependencies of encfs need to be updated?

:error:configure fuse4x has been made obsolete by the port osxfuse. Please install osxfuse instead.
:error:configure org.macports.configure for port fuse4x returned: obsolete port
:debug:configure Error code: NONE
:debug:configure Backtrace: obsolete port

[mf2k (Frank Schima)]

In the future, please Cc the port maintainers (port info --maintainers encfs).

[axet (Alexey Kuznetsov)]

Cc Me!

[hapaguy (Brian Kurt Fujikawa)]

Cc Me!

[flx.ms@…]

Please see also 39456

[flx.ms@…]

Cc Me!

[flx.ms@…]

OK, the solution is extremely easy. In the encfs port file just replace the line:

depends_lib         port:rlog port:openssl path:lib/libfuse.dylib:fuse4x port:gettext port:boost

with

depends_lib         port:rlog port:openssl path:lib/libfuse.dylib:osxfuse port:gettext port:boost

and everything builds and works fine. So it's really just "osxfuse" instead of "fuse4x" - that's all.

In case you do not want to await the official update follow the instructions here: ​https://guide.macports.org/#development.local-repositories

Cheers and happy Easter!

[axet (Alexey Kuznetsov)]

No. It is not that easy.

If you just replace Portfile with new dependency encfs configure will fail with:

:info:configure Encfs 1.3 requires FUSE 2.5 or newer. Please check config.log for errors. If

[flx.ms@…]

Well, I am sorry to read, that my proposal did not work for you. For me (OSX Mavericks 10.9.2) it works fine exactly as I described it above (uninstalled an cleaned encfs; afterwards recompiled it with the updated portfile; of course you should also remove & clean fuse4x package and install osxfuse package BEFORE you try to recompile encfs). I am already using EncFS again without any problems and the mount Symbol-Text has changed to "OSXFUSE Volume 0 (encfs)" - as exepected - when mounting a directory. - But maybe I was just lucky for some reason?

• just as a of course very trivial hint: did you update all other packages to the very latest versions? I also had to restart the system once due to changes in some OpenSSL kernel modules.

Good luck!

[flx.ms@…]

By the way, I believe, that this change r119124 supports the thesis, that the proposal above should work (at least for most people)?

Hope that helps!

[neverpanic (Clemens Lang)]

Use osxfuse and make sure the right fuse is being used

[neverpanic (Clemens Lang)]

Please check for any files called fuse.h and/or libfuse.dylib in /usr/local, since those might cause problems while building encfs. See wiki:FAQ#usrlocal for more information.

I've attached a patch that changes the dependency to osxfuse and tries to avoid libraries from /usr/local. Maintainer: OK to commit?

[cooljeanius (Eric Gallager)]

Cc Me!

[axet (Alexey Kuznetsov)]

Following patch failed on FUSE_MAJOR_VERSION check

Encfs 1.3 requires FUSE 2.5 or newer. Please check config.log for errors. If

osxfuse fuse.h does not have MAJOR macro, only FUSE_USE_VERSION

# check for a supported FUSE_MAJOR_VERSION.
AC_MSG_CHECKING([For supported FUSE API version])
AC_RUN_IFELSE([ 
    AC_LANG_PROGRAM([[#include "fuse.h"]],
[[
    if(FUSE_MAJOR_VERSION == 2 && FUSE_MINOR_VERSION >= 5)
    {
        return 0;
    } else
        return -1;
]])], 
    [AC_MSG_RESULT([yes])],
    [AC_MSG_RESULT([no])
    AC_MSG_FAILURE([
Encfs 1.3 requires FUSE 2.5 or newer.  Please check config.log for errors.  If
you cannot determine the problem, mail encfs-users@lists.sourceforge.net
and include the config.log file])
    ]
)

[neverpanic (Clemens Lang)]

$prefix/include/osxfuse/fuse/fuse_common.h has the FUSE_MAJOR_VERSION and FUSE_MINOR_VERSION macros and is included from $prefix/include/osxfuse/fuse.h, which should be included from this test. Please attach config.log so somebody can check if compilation of the test program failed (which would mean there's a bad include path somewhere) or the wrong fuse.h was used (possibly from /usr/local, as mentioned above).

[axet (Alexey Kuznetsov)]

yep. working fine and well mounted. thanks for pointing out.

i had issues with proper patching configure.ac

[drkp (Dan Ports)]

Cc Me!

[drkp (Dan Ports)]

Fixed in r119221

[mouse07410 (Mouse)]

Log of failed encfs installation

[mouse07410 (Mouse)]

Sorry, encfs-1.7.5-135 does not compile on Mavericks 10.9.2 with the latest Xcode (5.1.1). The log is attached. I have to request re-opening of this ticket, and patching of the encfs/main.cpp code (lines 573 and 574). The problem seems to be wrong number of parameters...

Needless to say, this is after the Portfile was edited to adjust for the move from fuse4x to osxfuse.

[mouse07410 (Mouse)]

Another problem - encfs (as it comes in the macports) does not seem to be friendly to clang. My system uses clang-3.4, and most everything else in macports is built with it, including boost. encfs, on the other hand, seems to use g++. As we all know, some c++ code - especially involving templates (like boost_filesystem :) - tends to crash when linked to a library created by a different compiler.

To keep the long story short, after some editing and patching, encfs from macports compiles and links fine, but crashes upon invocation because (as I suspect) encfs was compiled and linked with gcc-4.8.2, and boost libraries - by clang-3.4.

After I edited the Makefiles to set all the CC variables to clang/clang++ - encfs promptly stopped compiling with errors in encfs/Cipher.cpp, complaining that type shared_ptr is not defined. Needless to say, including <boost/shared_ptr.hpp> in encfs/Cipher.h did not help.

[axet (Alexey Kuznetsov)]

no problem on my end. same software. check again. try to clean all.

as i remember those problems were fixed recently (3 months ago or so)

[pavel@…]

I can confirm the same problem installing EncFS on Mavericks (latest Xcode). I tried to cleanup the boost library and install from scratch, but this happens all the time:

main.cpp:573:25: error: assigning to 'int (*)(const char *, const char *, const char *, size_t, int)' from incompatible type 'int (const char *, const char *, const char *, size_t, int, uint32_t)': different number of parameters (5 vs 6)

encfs_oper.setxattr = encfs_setxattr;

[drkp (Dan Ports)]

I'm unclear on how this could be a problem with boost or clang, as MacPorts has used clang to build encfs for ages. From the log, it looks like this could be caused by encfs attempting to link against another osxfuse installation in /usr/local. I committed a patch in r119238 that should help with this. Please try again after a selfupdate and see if that helps.

[pavel@…]

Ah ok, that was the problem, I had some custom osxfuse installed in /usr/local that came with NTFS-3G, after removing it it seems to compile just fine.

[mouse07410 (Mouse)]

I checked, and indeed found an old osxfuse installation in /usr/local. Somewhat ashamed, promptly removed it (libraries and include files), and re-run the "sudo port install encfs".

This time installation ended up with a working encfs, however "port" still said that encfs was broken. Digging deeper, the problem turned out to be the presence of two boost installations. After removing one of them, the installation finally succeeded.

The moral (for me): make sure to never install two different versions of boost in the same /opt/local/lib. :-) :-(

Pavel and Dan, thank you!