Opened 10 years ago

Closed 9 years ago

#44658 closed defect (fixed)

Encfs fails to mount after the recent upgrade

Reported by: kacnow@… Owned by: Markus.Ueberall@…
Priority: Normal Milestone:
Component: ports Version: 2.3.1
Keywords: Cc: urilabob@…, ryandesign (Ryan Carsten Schmidt)
Port: encfs

Description (last modified by ryandesign (Ryan Carsten Schmidt))

OS X 10.9.4 Mavericks

$ encfs /path /Volumes/path
The directory "/Volumes/path" does not exist. Should it be created? (y,n) y
dyld: lazy symbol binding failed: Symbol not found: __ZN5boost7archive6detail17shared_ptr_helperC2Ev
  Referenced from: /opt/local/lib/libencfs.6.dylib
  Expected in: /opt/local/lib/libboost_serialization-mt.dylib

dyld: Symbol not found: __ZN5boost7archive6detail17shared_ptr_helperC2Ev
  Referenced from: /opt/local/lib/libencfs.6.dylib
  Expected in: /opt/local/lib/libboost_serialization-mt.dylib

Trace/BPT trap: 5
$

Attachments (1)

main.log (76.8 KB) - added by urilabob@… 10 years ago.
log of port -nfstv install encfs

Download all attachments as: .zip

Change History (15)

comment:1 in reply to:  description Changed 10 years ago by kacnow@…

Rebuilding the package fixed it.

Last edited 10 years ago by kacnow@… (previous) (diff)

comment:2 Changed 10 years ago by Ionic (Mihai Moldovan)

He rebuilt encfs, after which it worked.

encfs is missing a revbump due to the latest boost upgrade.

Interestingly, rev-upgrade didn't catch that for some reason.

comment:3 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)

Description: modified (diff)
Keywords: encfs boost removed
Priority: HighNormal

Hmm, did this just start after upgrading to boost 1.56.0? I wonder if ports using boost need to be rebuilt. You could try downgrading boost to 1.55.0, or rebuilding encfs (i.e. sudo port -ns upgrade --force encfs).

Last edited 10 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:4 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)

Oh, sorry, overlooked ionic's previous comment. rev-upgrade only catches library version changes. If the boost developers didn't change the library version (but should have), then it wouldn't catch that.

comment:5 Changed 10 years ago by urilabob@…

I'm not sure why, but rebuilding encfs didn't work for me (compilation errors) - see attached log.

comment:6 Changed 10 years ago by neverpanic (Clemens Lang)

That looks like you have fuse headers in /usr/local. Try this:

sudo port clean encfs
sudo port -nsft upgrade encfs

Note that you should not use /usr/local while using MacPorts because of problems like these. See wiki:FAQ#usrlocal.

comment:7 Changed 10 years ago by urilabob@…

Thank you, Cal, for your advice. As you say, I have osxfuse headers in both /usr and /opt. Unfortunately that doesn't seem to be the whole story. I tried

sudo port clean encfs
sudo port -nsftv install encfs

but got essentially the same errors (will attach the log file). I know it must be something to do with my configuration, as I upgraded my wife's machine to mavericks yesterday (same as mine) and installed Xcode (5.1.1, same as mine) and mavericks macports. On my wife's machine, encfs installed perfectly OK. But on mine, I continue to get these osxfuse-related errors. If you have any further ideas on what I could be doing wrong, I would really appreciate it. In particular, I'm wondering whether there could be some problem related to FUSE_USE_VERSION? A patch of xtreemfs seems to be closely related: https://code.google.com/p/xtreemfs/issues/detail?id=307.

Last edited 10 years ago by urilabob@… (previous) (diff)

Changed 10 years ago by urilabob@…

Attachment: main.log added

log of port -nfstv install encfs

comment:8 Changed 10 years ago by urilabob@…

Cc: urilabob@… added

Cc Me!

comment:9 Changed 10 years ago by neverpanic (Clemens Lang)

Wait, do you actually have osxfuse headers in /usr/include? That would explain why trace mode doesn't fix the problem for you. If they are in /usr/local/include, the bad headers should have been hidden by trace mode (-t).

Have you tried moving /usr/local aside for while? Also, if you have the headers in /usr/include, please revert that. /usr/include is Apple-land and you shouldn't have modified it.

This isn't a source problem with encfs (as it was with the xtreemfs ticket you linked). The encfs code is compatible with this OS X-specific extension to fuse. encfs tries to assign a structure with 6 members (the last one OS X-specific) to a structure defined (by a bad and/or outdated header not installed by MacPorts) with 5 members, which causes the problem.

comment:10 Changed 10 years ago by urilabob@…

Thanks again Cal, the problem is solved for me - encfs compiled and is now running. I don't have osxfuse headers in /usr/include, but there are headers in /usr/local/include. Moving /usr/local aside temporarily allowed encfs to build properly (yay!!). However this means that trace mode didn't work properly, right? The usrlocal FAQ seems to suggest I should file a separate bug report, I presume against encfs, correct?

comment:11 in reply to:  10 Changed 10 years ago by neverpanic (Clemens Lang)

Replying to urilabob@…:

However this means that trace mode didn't work properly, right?

Yes. There are a number of reasons why trace mode might have failed in this case, such as symlinks from outside /usr/local into /usr/local. I'd have to see the log of a failed build with trace mode debugging enabled – however that requires manually recompiling the trace library, so I'm not sure it's worth the effort. Let me know if you want to attempt that and I'll give you instructions on how to do that.

comment:12 Changed 10 years ago by urilabob@…

Thank you again Cal. It sounds like the reason for trace not working is likely to be something specific to my system, and therefore not of wider value. This is a quite old system, originally installed under OSX 10.1, and then migrated a number of times over versions of OSX, over versions of XCode/Developer, and over hardware. For quite a while it had fink installed, before I decided to switch to macports. So there are many reasons why it might be slightly nonstandard, have leftover symlinks etc. I now know that if trace mode fails, I should move /usr/local out of the way temporarily - and anyone googling this discussion knows it too. So overall, I agree it's probably not worth the effort to debug.

Thanks and Best Wishes

Bob

comment:13 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: ryandesign@… added
Owner: changed from macports-tickets@… to Markus.Ueberall@…

This happened again when boost was updated to 1.59.0; see #48696.

The port has been updated to 1.8.1 since then so no further changes are needed at this time.

comment:14 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.