Cannot install sshfs for x86_64 because osxfuse only supports i386

[leeawalsh@…]

Today during an upgrade, my fuse4x port was replaced with osxfuse:

--->  fuse4x is replaced by osxfuse
--->  Computing dependencies for osxfuse
--->  Dependencies to be installed: libtool
--->  Fetching archive for libtool
--->  Attempting to fetch libtool-2.4.2_3+universal.darwin_10.i386-x86_64.tbz2 from http://lil.fr.packages.macports.org/libtool
--->  Attempting to fetch libtool-2.4.2_3+universal.darwin_10.i386-x86_64.tbz2.rmd160 from http://lil.fr.packages.macports.org/libtool
--->  Installing libtool @2.4.2_3+universal
--->  Deactivating libtool @2.4.2_3
--->  Cleaning libtool
--->  Activating libtool @2.4.2_3+universal
--->  Cleaning libtool
--->  Fetching archive for osxfuse
--->  Attempting to fetch osxfuse-2.6.4_0.darwin_10.i386.tbz2 from http://lil.fr.packages.macports.org/osxfuse
--->  Attempting to fetch osxfuse-2.6.4_0.darwin_10.i386.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/osxfuse
--->  Attempting to fetch osxfuse-2.6.4_0.darwin_10.i386.tbz2 from http://nue.de.packages.macports.org/macports/packages/osxfuse
--->  Fetching distfiles for osxfuse
--->  Attempting to fetch osxfuse-7b0d8d3.tar.gz from https://github.com/osxfuse/osxfuse/tarball/7b0d8d3/
--->  Attempting to fetch kext-c59029c.tar.gz from https://github.com/osxfuse/kext/tarball/c59029c/
--->  Attempting to fetch framework-9fdde8a.tar.gz from https://github.com/osxfuse/framework/tarball/9fdde8a/
--->  Attempting to fetch prefpane-8c3ea24.tar.gz from https://github.com/osxfuse/prefpane/tarball/8c3ea24/
--->  Attempting to fetch fuse-98b9960.tar.gz from https://github.com/osxfuse/fuse/tarball/98b9960/
--->  Attempting to fetch support-1213520.tar.gz from https://github.com/osxfuse/support/tarball/1213520/
--->  Verifying checksums for osxfuse
--->  Extracting osxfuse
--->  Applying patches to osxfuse
--->  Configuring osxfuse
--->  Building osxfuse
--->  Staging osxfuse into destroot
Warning: osxfuse installs files outside the common directory structure.
--->  Installing osxfuse @2.6.4_0
--->  Cleaning osxfuse
--->  Deactivating fuse4x @0.9.2_1
--->  Unable to deactivate fuse4x @0.9.2_1, the following ports depend on it:
--->  	sshfs @2.4_2
Warning: Deactivate forced.  Proceeding despite dependencies.
--->  Cleaning fuse4x
--->  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
--->  fuse4x-kext is replaced by osxfuse
--->  Deactivating fuse4x-kext @0.9.2_0
--->  Cleaning fuse4x-kext
--->  Cleaning osxfuse

Note that it deactivated sshfs. Trying to upgrade or reactivate it gives:

--->  Computing dependencies for sshfs
Error: Cannot install sshfs 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 do I have to use the old version of fuse (fuse4x @0.9.2_2) and sshfs (sshfs @2.4_2) in order to get them to work?

I did try the recommended unloading of the kernel extension (though I don't know what that means or whether it is relevant), and it failed:

~$ sudo kextunload -b com.github.osxfuse.filesystems.osxfusefs
(kernel) Kext com.github.osxfuse.filesystems.osxfusefs not found for unload request.
Failed to unload com.github.osxfuse.filesystems.osxfusefs - (libkern/kext) not found.

I also do not know why it chose to replace libtool with libtool+universal (I have no other universal ports). (My processor is intel core 2 duo.) Reactivating it as libtool (not universal) doesn't change the behavior of fuse/sshfs.

[mp@…]

Cc Me!

[mp@…]

On Snow Leopard the kernel is 32-bit, which causes OSXfuse to get installed as i386, so sshfs also needs to be i386.

Adding

configure.build_arch ${os.arch}

in the sshfs Portfile and installing with

sudo port install sshfs -universal

works on a Snow Leopard (10.6.8) system with the same issue.

To edit the Portfile:

sudo port ed sshfs

[cooljeanius (Eric Gallager)]

Cc Me!

[leeawalsh@…]

Thanks, that worked for me. It reinstalled many dependencies with the +universal variant. I hadn't realized +universal was for 32 vs 64 bit as well as x86 vs powerpc.

Is there a reason that sshfs doesn't detect the os architecture (or that of osxfuse) by default?

[mp@…]

Well, I meant -universal, because OSXfuse doesn't build with +universal (yet), however it does correctly adapt to whatever the kernel is, so that's why ports that depend on it have to adapt as well, which they do when

configure.build_arch ${os.arch}

is added and they're built with -universal. Any port that depends on OSXfuse has to be built with what matches the kernel, at least until OSXfuse is made to also build with +universal.

The old solution (fuse4x) could be built with +universal, so then all its dependents could be built with either +universal or -universal.

Hopefully some Portfile wizard can also get OSXfuse to build with +universal eventually.

Actually, it's a bit strange with Snow Leopard, because it seems that only the kernel is 32-bit, and everything else can be either 32- or 64-bit. Someone, somewhere might know why...

[ryandesign (Ryan Carsten Schmidt)]

Replying to mp@…:

Well, I meant -universal, because OSXfuse doesn't build with +universal (yet), however it does correctly adapt to whatever the kernel is, so that's why ports that depend on it have to adapt as well, which they do when

configure.build_arch ${os.arch}

is added and they're built with -universal. Any port that depends on OSXfuse has to be built with what matches the kernel, at least until OSXfuse is made to also build with +universal.

"configure.build_arch ${os.arch}" is never correct, because it is a mismatch of concepts. build_arch controls the build architecture, valid values for which are i386, x86_64, ppc, and ppc64, while ​os.arch indicates only whether the computer is Intel-based or PowerPC-based. On all Intel Macs (32-bit and 64-bit), os.arch is "i386", while on all PowerPC Macs (32-bit and 64-bit), os.arch is "powerpc". So setting "configure.build_arch ${os.arch}" will make the build succeed on Intel Macs with a 32-bit kernel, fail on Intel Macs with a 64-bit kernel, and cause configure.build_arch to be set to an invalid value on PowerPC Macs. (Not that osxfuse or any port depending on it can be installed on PowerPC Macs, but it's important not to set variables to invalid values regardless of the system; you don't want an error to occur just because a PowerPC user runs "port info osxfuse" or "sudo port clean all" for example.)

In any case setting configure.build_arch directly is usually not the best solution; usually you should set supported_archs instead. The block that would actually need to be added to all ports that depend on osxfuse, and all ports that depend on those ports, and so on, is the same block that is already in osxfuse:

set kernel_arch [exec uname -m]
switch ${kernel_arch} {
    i386 -
    x86_64 {
        supported_archs ${kernel_arch}
    }
    default {
        supported_archs i386 x86_64
    }
}

It is unfortunate that the osxfuse port currently encompasses two very different pieces of software: a kernel extension, whose architecture needs to match the kernel, and also userland frameworks and libraries that other programs need to link with. It would be ideal if osxfuse could split these two different types of software into two different ports, so that's the kernel modules could be built for their required architecture, while the libraries and frameworks could be built for the same architecture as other userland software, thus eliminating the need to add the above block to any port that directly or indirectly uses osxfuse.

The old solution (fuse4x) could be built with +universal, so then all its dependents could be built with either +universal or -universal.

Hopefully some Portfile wizard can also get OSXfuse to build with +universal eventually.

That is the best solution of all, if someone can come up with it.

Actually, it's a bit strange with Snow Leopard, because it seems that only the kernel is 32-bit, and everything else can be either 32- or 64-bit. Someone, somewhere might know why...

This is not strange; this is perfectly normal. Whether the kernel is 32-bit or 64-bit has no bearing on whether you can run 64-bit userland programs, and whether the kernel is 32-bit or 64-bit varies by Mac model and OS X version. That's just how Apple decided to do it.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign@…:

It is unfortunate that the osxfuse port currently encompasses two very different pieces of software: a kernel extension, whose architecture needs to match the kernel, and also userland frameworks and libraries that other programs need to link with. It would be ideal if osxfuse could split these two different types of software into two different ports, so that's the kernel modules could be built for their required architecture, while the libraries and frameworks could be built for the same architecture as other userland software, thus eliminating the need to add the above block to any port that directly or indirectly uses osxfuse.

I should point out that this is how fuse4x was set up, before osxfuse replaced it.

Hopefully some Portfile wizard can also get OSXfuse to build with +universal eventually.

That is the best solution of all, if someone can come up with it.

That is to say, the hypothetical new port for just the osxfuse userland libraries and frameworks (which other ports would depend on) should be universal capable; the hypothetical new port for just the osxfuse kernel extensions (which only the osxfuse library/framework port would need to depend on, and which would be marked "installs_libs no" so that the architecture check is bypassed) only needs to match the kernel architecture.

[ryandesign (Ryan Carsten Schmidt)]

Duplicate of #43415.