osxfuse architecture mismatch when kernel arch different from userspace

[soulne4ny (Alexey Luchko)]

$ 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.

[dbevans (David B. Evans)]

Please use WikiFormatting to make terminal output more readable and CC relevant maintainer(s) when submitting tickets.

[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

[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.

[mf2k (Frank Schima)]

This was added to the osxfuse Portfile by pixilla in ticket:39456#comment:34. Cc'ing him for comment. Bradley, any thoughts on this?

[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'

[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).

[mp@…]

Cc Me!

[dliessi (Davide Liessi)]

Cc Me!

[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

[steven@…]

Cc Me!

[k3ithk@…]

Cc Me!

[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

[Michael.Tiernan@…]

Cc Me!

[ivl1705]

Cc Me!

[cooljeanius (Eric Gallager)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Has duplicates #43439, #44317.

Replying to cal@…:

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.

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.

[emai@…]

Cc Me!

[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

[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.

[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?

[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, and sshfs.

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.

[drkp (Dan Ports)]

proposed patch

[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.

[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.

[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.

[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.

[drkp (Dan Ports)]

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_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.