Opened 11 years ago
Closed 10 years ago
#43415 closed defect (fixed)
osxfuse architecture mismatch when kernel arch different from userspace
Reported by: | soulne4ny (Alexey Luchko) | Owned by: | drkp (Dan Ports) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | Cc: | pixilla (Bradley Giesbrecht), mp@…, dliessi (Davide Liessi), steven@…, k3ithk@…, Michael.Tiernan@…, ivl1705, cooljeanius (Eric Gallager), leeawalsh@…, ryandesign (Ryan Carsten Schmidt), fieldlab, emai@… | |
Port: | osxfuse ntfs-3g sshfs |
Description (last modified by dbevans (David B. Evans))
$ sudo port uninstall fuse4x fuse4x-kext ntfs-3g testdisk $ sudo port install testdisk ---> Computing dependencies for testdisk Error: Cannot install ntfs-3g for the arch(s) 'x86_64' because Error: its dependency osxfuse only supports the arch(s) 'i386'. Error: Unable to execute port: architecture mismatch $ uname -mprsv Darwin 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:26:45 PDT 2012; root:xnu-1699.32.7~1/RELEASE_I386 i386 i386 OsX 10.7.5.
Attachments (2)
Change History (29)
comment:1 Changed 11 years ago by dbevans (David B. Evans)
Description: | modified (diff) |
---|---|
Keywords: | fuse osxfuse ntfs-3g fuse4x removed |
Owner: | changed from macports-tickets@… to dports@… |
Port: | ntfs-3g added |
Version: | 2.2.1 |
comment:2 Changed 11 years ago by mf2k (Frank Schima)
I'm guessing you have osxfuse installed outside of Macports.
$ port -d installed osxfuse ntfs-3g The following ports are currently installed: ntfs-3g @2014.2.15_0 (active) platform='darwin 13' archs='x86_64' osxfuse @2.6.4_0 (active) platform='darwin 13' archs='x86_64'
Also,
$ file /opt/local/lib/libosxfuse_i64.2.dylib /opt/local/lib/libosxfuse_i64.2.dylib: Mach-O 64-bit x86_64 dynamically linked shared library
comment:3 follow-up: 17 Changed 11 years ago by neverpanic (Clemens Lang)
No, it's probably because the osxfuse
Portfile uses the output of uname -m
to determine the supported_archs
, and uname -m
on 10.7.5 apparently returns i386
, limiting the port to 32-bit only.
comment:4 Changed 11 years ago by mf2k (Frank Schima)
Cc: | pixilla@… added |
---|
This was added to the osxfuse Portfile by pixilla in ticket:39456#comment:34. Cc'ing him for comment. Bradley, any thoughts on this?
comment:5 Changed 11 years ago by soulne4ny (Alexey Luchko)
There is no other osxfuse in the system:
$ sudo find / -iname '*osxfuse*' 2>/dev/null /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/fuse/osxfuse
Installing osxfuse:
$ sudo port install osxfuse Password: ---> Fetching archive for osxfuse ---> Attempting to fetch osxfuse-2.6.4_0.darwin_11.i386.tbz2 from http://lil.fr.packages.macports.org/osxfuse ---> Attempting to fetch osxfuse-2.6.4_0.darwin_11.i386.tbz2.rmd160 from http://lil.fr.packages.macports.org/osxfuse ---> Installing osxfuse @2.6.4_0 ---> Activating osxfuse @2.6.4_0 When upgrading, unmount all FUSE filesystems and then unload the kernel extension. Unloading can be done via: sudo kextunload -b com.github.osxfuse.filesystems.osxfusefs Alternativley (or if this fails), just reboot your computer now. ---> Cleaning osxfuse ---> Updating database of binaries: 100.0% ---> Scanning binaries for linking errors: 100.0% ---> No broken files found.
Installing ntfs-3g:
$ sudo port install ntfs-3g Error: Cannot install ntfs-3g for the arch(s) 'x86_64' because Error: its dependency osxfuse is only installed for the arch 'i386' Error: and does not have a universal variant. Error: Unable to execute port: architecture mismatch
Installing osxfuse from source gives the same result.
The following ports are currently installed: osxfuse @2.6.4_0 (active) platform='darwin 11' archs='i386'
comment:6 Changed 11 years ago by drkp (Dan Ports)
Yes, we don't have great support in base for building kernel modules with the right architecture on systems where the userspace and kernel have different architectures. Probably the way to do this is to force osxfuse to build universal by default on systems where this is possible (Lion and earlier, right?)
With fuse4x, we built the kext from a different port so we could make sure that was the only thing that had to build universal, which was nice, but it's not a terrible loss if we have to build everything universal too (like we did with macfuse).
comment:7 Changed 11 years ago by drkp (Dan Ports)
Summary: | osxfuse i386 blocks ntfs3g x86_64 → osxfuse architecture mismatch when kernel arch different from userspace |
---|
comment:10 Changed 11 years ago by dliessi (Davide Liessi)
I'm also getting this.
$ uname -v Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 $ uname -m i386
comment:13 Changed 11 years ago by Michael.Tiernan@…
Yes, I'll add myself to the group.
I've read the thread and done the checks as requested.
This is where I started from:
{~}$ sudo port selfupdate ---> Updating MacPorts base sources using rsync MacPorts base version 2.2.1 installed, MacPorts base version 2.2.1 downloaded. ---> Updating the ports tree ---> MacPorts base is already the latest version The ports tree has been updated. To upgrade your installed ports, you should run port upgrade outdated {~}$ sudo port upgrade outdated Password: ---> Computing dependencies for encfs Error: Cannot install encfs for the arch(s) 'x86_64' because Error: its dependency osxfuse only supports the arch(s) 'i386'. Error: Unable to upgrade port: architecture mismatch To report a bug, follow the instructions in the guide: http://guide.macports.org/#project.tickets
So I tried the obvious:
sudo port install osxfuse ---> Cleaning osxfuse ---> Updating database of binaries: 100.0% ---> Scanning binaries for linking errors: 100.0% ---> Found 4 broken file(s), matching files to ports ---> Found 2 broken port(s), determining rebuild order ---> Rebuilding in order encfs @1.7.5-135 sshfs @2.4 ---> Computing dependencies for encfs Error: Cannot install encfs for the arch(s) 'x86_64' because Error: its dependency osxfuse only supports the arch(s) 'i386'. Error: Unable to upgrade port: architecture mismatch Error rebuilding encfs while executing "error "Error rebuilding $portname"" (procedure "revupgrade_scanandrebuild" line 382) invoked from within "revupgrade_scanandrebuild broken_port_counts $opts" (procedure "macports::revupgrade" line 5) invoked from within "macports::revupgrade $opts" (procedure "action_revupgrade" line 2) invoked from within "action_revupgrade $action $portlist $opts" (procedure "action_target" line 96) invoked from within "$action_proc $action $portlist [array get global_options]" (procedure "process_cmd" line 93) invoked from within "process_cmd $remaining_args" invoked from within "if { [llength $remaining_args] > 0 } { # If there are remaining arguments, process those as a command set exit_status [process_cmd $remaining..." (file "/opt/local/bin/port" line 4857)
And when none of that gave the results expected I did the steps as mentioned here...
{~}$ port version Version: 2.2.1 {~}$ uname -mprsv Darwin 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386 i386 {~}$ port -d installed osxfuse The following ports are currently installed: osxfuse @2.6.4_0 (active) platform='darwin 10' archs='i386' {~}$ file /opt/local/lib/libosxfuse_i64.2.dylib /opt/local/lib/libosxfuse_i64.2.dylib: Mach-O i386 dynamically linked shared library
So, hopefully that helps.
Here's the system:
Model Name: MacBook Pro Model Identifier: MacBookPro5,2 Processor Name: Intel Core 2 Duo Processor Speed: 3.06 GHz Number Of Processors: 1 Total Number Of Cores: 2 L2 Cache: 6 MB Memory: 8 GB Bus Speed: 1.07 GHz Boot ROM Version: MBP52.008E.B05 SMC Version (system): 1.42f4 System Version: Mac OS X 10.6.8 (10K549) Kernel Version: Darwin 10.8.0 Boot Mode: Normal Secure Virtual Memory: Enabled 64-bit Kernel and Extensions: No
comment:17 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | leeawalsh@… ryandesign@… fieldlab4@… added |
---|---|
Port: | sshfs added |
Has duplicates #43439, #44317.
Replying to cal@…:
No, it's probably because the
osxfuse
Portfile uses the output ofuname -m
to determine thesupported_archs
, anduname -m
on 10.7.5 apparently returnsi386
, limiting the port to 32-bit only.
uname -m
returns the kernel architecture. Whether that's i386
or x86_64
depends both on the OS X version and on the specific Mac model.
comment:19 Changed 10 years ago by emai@…
Also a problem for me on my 10.6.8 Mac OSX. Upgrading to Mavericks and hope someone makes progress on this.
Cheers,
Eric
comment:20 Changed 10 years ago by soulne4ny (Alexey Luchko)
I've found that homebrew provides a formula for osxfuse. It works installed from a binary package, so should be buildable too. (I do not suppose to start a holywar :)
osxfuse provides support for homebrew with their build.sh
: https://github.com/osxfuse/osxfuse/blob/osxfuse-2/build.sh#L1849
May be one who better understands macosx specifics could find a solution or share ideas what to try to solve the issue. Keeping homebrew just because of one package is a bit stupid.
comment:21 follow-up: 22 Changed 10 years ago by neverpanic (Clemens Lang)
The fix for this is a simple as adding the block
# We want to match the supported arch set kernel_arch [exec uname -m] switch ${kernel_arch} { i386 - x86_64 { supported_archs ${kernel_arch} } default { supported_archs i386 x86_64 } }
to every Portfile
affected by the problem, i.e. osxfuse
, ntfs-3g
, and sshfs
.
Can somebody please provide patches that do this for the aforementioned ports?
comment:22 Changed 10 years ago by drkp (Dan Ports)
Replying to cal@…:
The fix for this is a simple as adding the block [...] to every
Portfile
affected by the problem, i.e.osxfuse
,ntfs-3g
, andsshfs
.
That goes a bit far. We don't need the user space library to be built for the kernel arch, and indeed we don't want it to since that would force all the filesystems and their dependencies to be built for a non-standard arch. We just want the kernel component to be built for the right architecture.
comment:23 Changed 10 years ago by drkp (Dan Ports)
So how about this? Can someone give the attached patch a try? It seems to behave correctly but I don't have a machine with different kernel/userland architectures handy to actually test it on.
This builds the kernel module for the kernel arch (as well as a couple support scripts, which should be fine), but leaves libfuse using the normal userspace architecture.
Not totally ideal -- we don't record the architecture that the kernel module is built for in the registry, so we have to disable binary packages in certain cases -- but it should get things working for those who are having problems.
comment:24 follow-up: 25 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
It would be good if the kernel module would be in its own subport, separate from the libraries and programs and other stuff, as mentioned in comment:ticket:43439:6.
comment:25 Changed 10 years ago by drkp (Dan Ports)
Replying to ryandesign@…:
It would be good if the kernel module would be in its own subport, separate from the libraries and programs and other stuff, as mentioned in comment:ticket:43439:6.
Yes, I agree, I would like to split it into multiple (sub)ports like we did for Fuse4X -- that was much cleaner and easier to maintain. However, it seems harder to make the OSXFUSE build system work this way. So assuming this patch works I think we should do that for now and try to split up the port later.
Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
Attachment: | osxfuse-ryandesign.diff added |
---|
comment:26 follow-up: 27 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
The patch seems to work:
$ port -q cont osxfuse | xargs file | grep 86 /Volumes/Data/macports/snowleopard/Library/Filesystems/osxfusefs.fs/Support/load_osxfusefs: setuid Mach-O executable i386 /Volumes/Data/macports/snowleopard/Library/Filesystems/osxfusefs.fs/Support/mount_osxfusefs: Mach-O executable i386 /Volumes/Data/macports/snowleopard/Library/Filesystems/osxfusefs.fs/Support/osxfusefs.kext.dSYM/Contents/Resources/DWARF/osxfusefs: Mach-O dSYM companion file i386 /Volumes/Data/macports/snowleopard/Library/Filesystems/osxfusefs.fs/Support/osxfusefs.kext/Contents/MacOS/osxfusefs: Mach-O object i386 /Volumes/Data/macports/snowleopard/Library/Frameworks/OSXFUSE.framework/OSXFUSE: Mach-O 64-bit dynamically linked shared library x86_64 /Volumes/Data/macports/snowleopard/Library/Frameworks/OSXFUSE.framework/Versions/A/OSXFUSE: Mach-O 64-bit dynamically linked shared library x86_64 /Volumes/Data/macports/snowleopard/Library/Frameworks/OSXFUSE.framework/Versions/A/Resources/Debug/OSXFUSE.framework.dSYM/Contents/Resources/DWARF/OSXFUSE: Mach-O 64-bit dSYM companion file x86_64 /Volumes/Data/macports/snowleopard/Library/Frameworks/OSXFUSE.framework/Versions/A/Resources/Debug/libosxfuse_i32.dylib.dSYM/Contents/Resources/DWARF/libosxfuse_i32.dylib: Mach-O 64-bit dSYM companion file x86_64 /Volumes/Data/macports/snowleopard/Library/Frameworks/OSXFUSE.framework/Versions/A/Resources/Debug/libosxfuse_i64.dylib.dSYM/Contents/Resources/DWARF/libosxfuse_i64.dylib: Mach-O 64-bit dSYM companion file x86_64 /Volumes/Data/macports/snowleopard/lib/libosxfuse.2.dylib: Mach-O 64-bit dynamically linked shared library x86_64 /Volumes/Data/macports/snowleopard/lib/libosxfuse.dylib: Mach-O 64-bit dynamically linked shared library x86_64 /Volumes/Data/macports/snowleopard/lib/libosxfuse_i32.2.dylib: Mach-O 64-bit dynamically linked shared library x86_64 /Volumes/Data/macports/snowleopard/lib/libosxfuse_i32.dylib: Mach-O 64-bit dynamically linked shared library x86_64 /Volumes/Data/macports/snowleopard/lib/libosxfuse_i64.2.dylib: Mach-O 64-bit dynamically linked shared library x86_64 /Volumes/Data/macports/snowleopard/lib/libosxfuse_i64.dylib: Mach-O 64-bit dynamically linked shared library x86_64
I've attached a slightly revised patch, which, when clearing the archive_sites, checks not if the user arch and kernel arch are unequal, but checks if the user arch is not equal to x86_64, because x86_64 is the kernel arch on the buildslaves.
comment:27 Changed 10 years ago by drkp (Dan Ports)
Resolution: | → fixed |
---|---|
Status: | new → closed |
This looks good, thanks (and thanks for testing)!
Committed in r123208.
Replying to ryandesign@…:
The patch seems to work:
$ port -q cont osxfuse | xargs file | grep 86 /Volumes/Data/macports/snowleopard/Library/Filesystems/osxfusefs.fs/Support/load_osxfusefs: setuid Mach-O executable i386 /Volumes/Data/macports/snowleopard/Library/Filesystems/osxfusefs.fs/Support/mount_osxfusefs: Mach-O executable i386 /Volumes/Data/macports/snowleopard/Library/Filesystems/osxfusefs.fs/Support/osxfusefs.kext.dSYM/Contents/Resources/DWARF/osxfusefs: Mach-O dSYM companion file i386 /Volumes/Data/macports/snowleopard/Library/Filesystems/osxfusefs.fs/Support/osxfusefs.kext/Contents/MacOS/osxfusefs: Mach-O object i386 /Volumes/Data/macports/snowleopard/Library/Frameworks/OSXFUSE.framework/OSXFUSE: Mach-O 64-bit dynamically linked shared library x86_64 /Volumes/Data/macports/snowleopard/Library/Frameworks/OSXFUSE.framework/Versions/A/OSXFUSE: Mach-O 64-bit dynamically linked shared library x86_64 /Volumes/Data/macports/snowleopard/Library/Frameworks/OSXFUSE.framework/Versions/A/Resources/Debug/OSXFUSE.framework.dSYM/Contents/Resources/DWARF/OSXFUSE: Mach-O 64-bit dSYM companion file x86_64 /Volumes/Data/macports/snowleopard/Library/Frameworks/OSXFUSE.framework/Versions/A/Resources/Debug/libosxfuse_i32.dylib.dSYM/Contents/Resources/DWARF/libosxfuse_i32.dylib: Mach-O 64-bit dSYM companion file x86_64 /Volumes/Data/macports/snowleopard/Library/Frameworks/OSXFUSE.framework/Versions/A/Resources/Debug/libosxfuse_i64.dylib.dSYM/Contents/Resources/DWARF/libosxfuse_i64.dylib: Mach-O 64-bit dSYM companion file x86_64 /Volumes/Data/macports/snowleopard/lib/libosxfuse.2.dylib: Mach-O 64-bit dynamically linked shared library x86_64 /Volumes/Data/macports/snowleopard/lib/libosxfuse.dylib: Mach-O 64-bit dynamically linked shared library x86_64 /Volumes/Data/macports/snowleopard/lib/libosxfuse_i32.2.dylib: Mach-O 64-bit dynamically linked shared library x86_64 /Volumes/Data/macports/snowleopard/lib/libosxfuse_i32.dylib: Mach-O 64-bit dynamically linked shared library x86_64 /Volumes/Data/macports/snowleopard/lib/libosxfuse_i64.2.dylib: Mach-O 64-bit dynamically linked shared library x86_64 /Volumes/Data/macports/snowleopard/lib/libosxfuse_i64.dylib: Mach-O 64-bit dynamically linked shared library x86_64I've attached a slightly revised patch, which, when clearing the archive_sites, checks not if the user arch and kernel arch are unequal, but checks if the user arch is not equal to x86_64, because x86_64 is the kernel arch on the buildslaves.
Please use WikiFormatting to make terminal output more readable and CC relevant maintainer(s) when submitting tickets.