Doesn't work in PPC Leopard server!?

[angelus1969]

This doesn't seem to work in PPC Leopard Server. It installs okay, but after opening the control, it states that MacFuse isn't installed. It lets me install again,but keeps saying it's not installed.

[bfleischer]

The official osxfuse package should work just fine on Leopard. I just ran some tests for the newly released version 2.6.3.

Did you build osxfuse yourself or install an unofficial build? Please try uninstalling osxfuse. Then remove the preference pane (control-click onto preference pane icon). After the uninstall is complete try reinstalling the official version.

[BlackcatSW]

I've run into the same problem with 10.5.8 PPC on a G5 quad. Installation ran fine, rebooted. osxfuse won't install in the Control Panel. Removed osxfuse and reran the installer. This time, the installer wanted to perform a upgrade. Did so, rebooted. CP still won't install. The 2.6.4 installer was downloaded from this site.

[bfleischer]

Thanks for the update. This makes it a ppc64 issue rather than a ppc issue. Correct me if I'm wrong but a G5 quad is a 64-bit processor.

Could you check if mounting volumes using ppc64 binaries works after you run the osxfuse installer manually? You can use the sshfs package from http://osxfuse.github.io to test this.

Since I don't own a Mac equipped with a G5 I'm not sure if I can fix this on my own. I'll look into it and let you know if I find something.

[bfleischer]

Could you run the following command in Terminal and post the output here?

/Library/PreferencePanes/OSXFUSE.prefPane/Contents/MacOS/autoinstall-osxfuse-core -v --print

[BlackcatSW]

Affirmative, the G5 quad is 64-bit, a ppc970.

Here's the output, it's the same if run as a user or root.

$ /Library/PreferencePanes/OSXFUSE.prefPane/Contents/MacOS/autoinstall-osxfuse-core -v --print
<KSTicket:0x114fb0
    productID=com.github.osxfuse.OSXFUSE
    version=0
    xc=<KSPathExistenceChecker:0x1130e0 path=/>
    url=http://osxfuse.github.com/releases/DeveloperRelease.plist
    creationDate=2014-05-08 09:12:12 -0400
>

I'll check the mounts tonight.

[bfleischer]

version=0 seems to be the problem. I'm getting the following output on an G4 Mac Mini running 10.5.8:

$ /Library/PreferencePanes/OSXFUSE.prefPane/Contents/MacOS/autoinstall-osxfuse-core -v --print
<KSTicket:0x115300
    productID=com.github.osxfuse.OSXFUSE
    version=2.6.4
    xc=<KSPathExistenceChecker:0x1134c0 path=/>
    url=http://osxfuse.github.com/releases/DeveloperRelease.plist
    creationDate=2014-05-08 21:37:58 +0200
>

[BlackcatSW]

I cloned the repository. Added support to the build.sh script for XCode 3.1 and limited the architectures to ppc64, ppc7400, & ppc970.

The osxfusefs build failed, stating the valid architectures were only ppc and i386. Next, opened up osxfusefs.xcconfig. ppc64 is not present in as a valid architecture for 10.5. Was this intentional?

Added ppc64 to the list, and the build ran until a slew of failed dependencies arose; possibly due to xcrun not present.

[bfleischer]

osxfusefs.xcconfig is only relevant for the kernel extension. As far as i know Mac OS X only comes with i386 and ppc kernels. There is not ppc64 kernel. ppc64 not being in osxfusefs.xcconfig is intentional.

The autoinstall-osxfuse-core tool is part of the prefpane submodule and is only compiled with ppc support, not ppc64. I'm not sure but I think there have been some issues with ppc64 support. However, as far as I know ppc binaries should run just fine on a ppc64 processor.

[fhgwright]

You're correct that ppc 32-bit binaries run fine on a ppc64. In fact, since Apple didn't start adding 64-bit support until after abandoning PowerPC, all PowerPC code for Macs (including the kernel and its extensions) needs to be 32-bit.

The biggest issue with the build procedure is the omission of Xcode 3.1 / GCC 4.0 as a valid Xcode version, since that's the last version that runs under Leopard (regardless of architecture). It's also possible that including ppc64 in the definition of M_SDK_105_ARCHS is problematic; it's at best useless.

When I ran afoul of this issue, I was actually attempting to install osxfuse 2.7.0 via MacPorts, which makes some modifications to build.sh, including replacing all architecture lists with just the target architecture. This rendered the possible "ppc64" issue moot, but for some reason just one of the architecture references became "Power Macintosh" instead of "ppc". After adding entries for Xcode 3.1 and fixing the latter issue, it built and ran successfully on both my Quad G5 and my PowerBook G4.

Here is a diff for the MacPorts-modified version of the 2.7.0 build.sh, which should be applicable to the standard version with the exception of the xcodebuild "Power Macintosh" fix:

*** build.sh.orig 2014-10-23 13:31:58.000000000 -0700
--- build.sh 2014-11-05 13:27:15.000000000 -0800

---

*** 63,68 ****
--- 63,71 ----

Other implementation details

• declare M_XCODE31=""

• declare M_XCODE31_VERSION=3.1

• readonly M_XCODE31_COMPILER="4.0"
  declare M_XCODE32=""
  declare M_XCODE32_VERSION=3.2
  readonly M_XCODE32_COMPILER="4.2"

  ---

  *** 1906,1912 ****

  m_log "building OSXFUSE kernel extension and tools"

! xcodebuild -configuration "$m_configuration" -target All GCC_VERSION="$m_compiler" ARCHS="Power Macintosh" SDKROOT="$m_usdk_dir" MACOSX_DEPLOYMENT_TARGET="$m_platform" >$m_stdout 2>$m_stderr

  m_exit_on_error "xcodebuild cannot build configuration $m_configuration."

--- 1909,1915 ----

  m_log "building OSXFUSE kernel extension and tools"

! xcodebuild -configuration "$m_configuration" -target All GCC_VERSION="$m_compiler" ARCHS="ppc" SDKROOT="$m_usdk_dir" MACOSX_DEPLOYMENT_TARGET="$m_platform" >$m_stdout 2>$m_stderr

  m_exit_on_error "xcodebuild cannot build configuration $m_configuration."

---

*** 2307,2312 ****
--- 2310,2323 ----
m_xcode_version=DEVELOPER_DIR="$m_xcode_root" xcodebuild -version | grep "Xcode" | cut -f 2 -d " "

      case $m_xcode_version in

•         3.1*)
  

•             m_version_compare $M_XCODE31_VERSION $m_xcode_version
  

•             if [[ $? != 2 ]]
  

•             then
  

•                 M_XCODE31="$m_xcode_root"
  

•                 M_XCODE31_VERSION=$m_xcode_version
  

•             fi
  

•             ;;
        3.2*)
            m_version_compare $M_XCODE32_VERSION $m_xcode_version
            if [[ $? != 2 ]]
  

  ---

  *** 2402,2407 ****
  --- 2413,2427 ----
  done

  Use most recent version of Xcode for each SDK

• if [[ -n "$M_XCODE31" ]]
  

• then
  

•     m_xcode_latest="$M_XCODE31"
  

•     M_SDK_105="$M_XCODE31/SDKs/MacOSX10.5.sdk"
  

•     M_SDK_105_XCODE="$M_XCODE31"
  

•     M_SDK_105_COMPILER="$M_XCODE31_COMPILER"
  

•     m_platform_realistic_add "10.5"
  

• fi
  

  if [[ -n "$M_XCODE32" ]]
  then
  m_xcode_latest="$M_XCODE32"

I didn't include any additional OS versions in the Xcode 3.1 section, since I' not sure which (if any) would be valid.

I'm not sure the diff can be unmangled from what the forum does to it, and the forum refuses to accept attachments other than pictures.

Fred Wright

[fhgwright]

It's not clear that anyone is still paying attention to this thread, but just in case, here's an update:

1. Xcode 3.1 includes GCC 4.2, though it's not the default. It seems to work fine to specify it in the 3.1 case, making it less different from 3.2.

2. I found some standard system executables with ppc64 code, so I've left it in the architecture list, even though the value is questionable.

3. The "reload" target uses kextutil, which doesn't exist in 10.5/3.1, but that vintage of kextload provides the same functionality.

4. There's no pkgbuild in 10.5/3.1, and there doesn't seem to be an easy replacement for its --analyze option, so I don't have a fix for the "dist" and "smalldist" targets.

5. Although the usage text implies that the "lib" target establishes the prerequisites for the "examples" target, empirically the former doesn't place libraries where the latter expects. This is equally true in the 10.9/6.1 case, so it's unrelated to the issue at hand (but interferes with testing).

There's a pull request with my current fixes here:

#180

Fred Wright

[fhgwright]

I've temporarily closed the pull request until I get the kextutil existence check to work right.

[fhgwright]

Although I've fixed the aforementioned problem affecting the "reload" target, I've now discovered another problem preventing the release binaries from working on the G5. It seems that the ppc64 "fork" in the kext support utilities is broken when built by Xcode 3.2, such that they crash with a segfault on startup. What I've found so far is that:

1. They work fine on the G4.

2. They work fine on the G5 if forced to run in 32-bit mode via the "arch" command.

3. They work fine when launched via gdb (making the problem hard to trace). Though I haven't determined whether gdb is running them as 32- or 64-bit binaries.

4. My own universal builds with Xcode 3.1 (and the "homebrew" target) work fine. I don't have a way to install Xcode 3.2 here, so it's just my suspicion that it's the culprit. I believe the Xcode 3.2 installer only works under 10.6, though the installed code can be forward-migrated to newer OS versions (which is presumably how the release packages are built).

I suspect that this was actually the OP's problem, though the thread morphed into issues relating to building on PPC rather than running on PPC. The segfault is completely hidden by the library (becoming the "the OSXFUSE file system is not available" message), though one can find the crash report in the logs once one knows that that's what's happening.

Although it would be nice to figure out what the real problem is and fix it, an acceptable workaround would be to tweak the build procedure to exclude the ppc64 architecture when building the kext support programs.

Fred Wright

[fhgwright]

Additional notes:

1. Since load_osxfusefs runs setuid root, you need to look in /Library/Logs/CrashReporter/, not ~/Library/Logs/CrashReporter/ to find a crash.

2. I did a bisection across the available downloads, and determined that the ppc64 (G5) issue appeared between 2.6.1 and 2.6.2. The (10.5) binaries of the two support programs shrunk at that point, and haven't changed since. Thus, something affecting ppc64 builds of those programs got broken between 18-Jul-2013 and 12-Nov-2013.

3. I can run the released 2.7.3 on the G5 if I replace those two programs with my own builds from the same source. These are still four-way universal builds, but with Xcode 3.1.4.

Fred Wright

[fhgwright]

I've opened three pull requests with fixes for Leopard and PPC (both building and running). It's three because two submodules are involved. These fix all known issues related to Leopard and/or PPC except the inability to build the dist/smalldist targets on Leopard.

osxfuse: #186
prefpane: osxfuse/prefpane#1
kext: osxfuse/kext#1

Fred Wright

[bfleischer]

Thanks @fhgwright for all the work.

Could you check if autoinstall-osxfuse-core returns the actual version number (2.7.3) using the official osxfuse 2.7.3 release when running the following command in Terminal on your G5?

/Library/PreferencePanes/OSXFUSE.prefPane/Contents/MacOS/autoinstall-osxfuse-core -v --print

[fhgwright]

On Mon, 8 Dec 2014, Benjamin Fleischer wrote:

Thanks @fhgwright for all the work.

Could you check if autoinstall-osxfuse-core returns the actual version
number (2.7.3) using the official osxfuse 2.7.3 release when running the
following command in Terminal on your G5?

/Library/PreferencePanes/OSXFUSE.prefPane/Contents/MacOS/autoinstall-osxfuse-core -v --print

No, it doesn't:

MacG5:~ fw$
/Library/PreferencePanes/OSXFUSE.prefPane/Contents/MacOS/autoinstall-osxfuse-core -v --print
<KSTicket:0x115480
productID=com.github.osxfuse.OSXFUSE
version=0
xc=<KSPathExistenceChecker:0x112a60 path=/>
url=http://osxfuse.github.com/releases/CurrentRelease.plist
creationDate=2014-12-08 15:49:13 -0800

When I run my own build with my fixes (where I hadn't changed the version
number), it does work:

MacG5:~ fw$
/Library/PreferencePanes/OSXFUSE.prefPane/Contents/MacOS/autoinstall-osxfuse-core -v --print
<KSTicket:0x115210
productID=com.github.osxfuse.OSXFUSE
version=2.7.3
xc=<KSPathExistenceChecker:0x1127d0 path=/>
url=http://osxfuse.github.com/releases/CurrentRelease.plist
creationDate=2014-12-08 15:55:16 -0800

This was built on my MacPro running OSX 10.9.5 and Xcode 6.1/3.1.

The same package also works on the Mac Pro, though I don't have enough
Xcodes to cover all the OS versions.

Fred Wright

[bfleischer]

Do you have any idea what might be causing this? autoinstall-osxfuse-core does not include ppc64 code. I know that the release version works fine on a G4 Mac Mini.

[fhgwright]

As I mentioned in an earlier response, the problem is that the ppc64 content in load_osxfusefs and mount_osxfusefs started being invalid (segfaults at startup, for at least two reasons) in 2.6.2. It just took a while for anyone to notice. :-)

I think I'll file a new issue to figure out what broke (and include what I've figured out about the breakage so far), but it's a low priority issue given that excluding ppc64 (and ppc970, of course) from those two builds is straightforward and has a negligible downside.

My change to the autoinstaller was for a different reason - avoiding trying to run the Extensions Tests in non-native architectures (which caused the 10.5 build with Xcode 3.1 running on the Mac Pro to fail).

[fhgwright]

To summarize my three pull requests:

kext: Removes ppc64 (and ppc970) from the *_osxfusefs builds.
prefpane: Restricts the Extensions Tests to the local architecture (since they run locally).
osxfuse: The above two submodule updates, plus other fixes to support Xcode 3.1.

[bfleischer]

kext: Removes ppc64 (and ppc970) from the *_osxfusefs builds.
prefpane: Restricts the Extensions Tests to the local architecture (since they run locally).
osxfuse: The above two submodule updates, plus other fixes to support Xcode 3.1.

I fully agree with you, dropping ppc64 from all builds but libfuse is the way to go. All I am saying is that it would be great to get autoinstaller fixed, too.

autoinstaller, albeit it has never included ppc64 code, does not work on G5 powered Macs. It does not crash but fails to determine the version number. This has been broken for a long time. In my opinion the interesting part is that even though autoinstaller works fine on G4s the same ppc7400 code does not work on G5s.

[fhgwright]

It works now. :-)

I reported earlier that my build reports the version correctly on my G5. It has nothing to do with autoinstaller itself, but rather that it runs mount_osxfusefs to determine the version. When the latter crashes (due to the broken ppc64 content) as a subprocess of autoinstaller, it doesn't appear to the user as a crash, but simply reports the version as 0. I guess even the "VERY verbose output" provided by -v doesn't include the info on the crash. :-) One can, however, see the crash in /Library/Logs/CrashReporter/ or ~/Library/Logs/CrashReporter/ (I think in the latter when it's invoked from the command line, and in the former when it's invoked from the preference pane).

With the bad ppc64 content removed from mount_osxfusefs, the autoinstaller version check works fine on the G5.

[fhgwright]

Assuming that the lipo tool is available (I'm not sure if it's included in the base install or whether it requires the developer tools), the following script can be used (with sudo) to repair any installed version of OSXFUSE to work on the G5:

---

#!/bin/sh

PROGDIR=/Library/Filesystems/osxfusefs.fs/Support
PROGS="load_osxfusefs mount_osxfusefs"

cd $PROGDIR

for prog in $PROGS; do
lipo -remove ppc64 $prog -output $prog.pat || continue
chmod $(stat -f '%p' $prog) $prog.pat || continue
chown $(stat -f '%u:%g' $prog) $prog.pat || continue
mv -f $prog.pat $prog

done

This will be a NOP (with error messages) when used against future versions of OSXFUSE where the ppc64 content is already absent. It's also a harmless change to apply to versions 2.6.1 and earlier, where the ppc64 content works fine but is unnecessary.

I'd provide it as a downloadable link if the site would let me. :-)

Fred Wright

[bfleischer]

That's great news. Thanks @fhgwright!

[bfleischer]

Version 2.7.4 has been released, so I'm closing this issue.