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)
Change History (15)
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: | High → Normal |
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
).
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.
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 follow-up: 11 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 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: | new → closed |
Rebuilding the package fixed it.