osxfuse @2.7.0_0: doesn't build on PPC

[fhgwright (Fred Wright)]

When attempting to install osxfuse on a PowerMac, I ran into a couple of issues in the build.sh script.

The first issue, which is really an upstream problem, is that the list of supported Xcode versions doesn't include 3.1, which is the last version that runs under 10.5, which in turn is the last OSX version for PPC. I've reported this in an an already existing thread:

​https://github.com/osxfuse/osxfuse/issues/121

The second issue is that the build.sh as modified by MacPorts specifies the architecture to an xcodebuild command as "Power Macintosh", which xcodebuild chokes on. Changing this to "ppc" makes the build work. I'm not sure whether the problem relates to the Xcode version or the architecture, and I don't know why this one architecture-related tweak to build.sh became "Power Macintosh" while the others became "ppc".

After modifying the build.sh in the MacPorts build area, I was able to successfully install osxfuse on a Quad G5 and on a PowerBook G4 (both running 10.5.8 and Xcode 3.1.4). It was then possible to install sshfs with no issues, and it seems to work properly.

I'm attaching a diff for the the fixes to the MacPorts-modified build.sh, though only the "Power Macintosh" issue is specific to MacPorts.

[fhgwright (Fred Wright)]

Fixes for build.sh

[larryv (Lawrence Velázquez)]

Thanks. In future tickets, please Cc any port maintainers (port info --maintainers osxfuse).

[drkp (Dan Ports)]

Ah, it seems uname -m returns "Power Macintosh" instead of ppc; I probably knew that back when I had a PPC mac! (We use this to identify the kernel architecture, which is why the other architecture references are correct.)

Thanks for looking into this and for reporting the issue upstream. I will fix the portfile to get the right architecture into the build script.

[fhgwright (Fred Wright)]

Replying to dports@…:

Ah, it seems uname -m returns "Power Macintosh" instead of ppc; I probably knew that back when I had a PPC mac! (We use this to identify the kernel architecture, which is why the other architecture references are correct.)

Thanks for looking into this and for reporting the issue upstream. I will fix the portfile to get the right architecture into the build script.

The fixes to allow building are now in the upstream sources, although there hasn't been a release incorporating them yet. There is a 2.7.3 release which has not yet been picked up by MacPorts, but it doesn't fix this issue. Presumably there will be a 2.7.4 release in the near future which will build correctly with Xcode 3.1, but the architecture fix will still be needed.

I did some investigating, and there doesn't seem to be *any* standard tool that reports the architecture in an appropriate manner on all machine types. So I wrote a little script to get around this, which I'm attaching. I've tested in on G4, G5, and MacPro machines, and since it only modifies the sysctl result when it's "Power Macintosh", it's extremely unlikely to work incorrectly on 32-bit Intel Macs (which I don't have).

[fhgwright (Fred Wright)]

Script to get correct machine architecture

[fhgwright (Fred Wright)]

Replying to fw@…:

Replying to dports@…:

Ah, it seems uname -m returns "Power Macintosh" instead of ppc; I probably knew that back when I had a PPC mac! (We use this to identify the kernel architecture, which is why the other architecture references are correct.)

Thanks for looking into this and for reporting the issue upstream. I will fix the portfile to get the right architecture into the build script.

The fixes to allow building are now in the upstream sources, although there hasn't been a release incorporating them yet. There is a 2.7.3 release which has not yet been picked up by MacPorts, but it doesn't fix this issue. Presumably there will be a 2.7.4 release in the near future which will build correctly with Xcode 3.1, but the architecture fix will still be needed.

I did some investigating, and there doesn't seem to be *any* standard tool that reports the architecture in an appropriate manner on all machine types. So I wrote a little script to get around this, which I'm attaching. I've tested in on G4, G5, and MacPro machines, and since it only modifies the sysctl result when it's "Power Macintosh", it's extremely unlikely to work incorrectly on 32-bit Intel Macs (which I don't have).

When I wrote the last paragraph, I'd missed that the problematic area related to constraining the *kernel* architecture, rather than the general build architecture. However, strictly enforcing the single-architecture policy on kexts when running under 10.6 or 10.7 (the "dual bitness" kernels) would cause OSXFUSE to stop working when switching "bitness". Thus, I think the minimum *reasonable* configuration for 10.6/10.7 kexts would be 1386/x86_64 universal.

Here's a table of the various architecture choices:

OS Version	Processor	Minimal kext	Reasonable kext	OSXFUSE Default kext
10.5	ppc/ppc64	ppc	ppc	ppc/i386
10.5	i386/x86_64	i386	i386	ppc/i386
10.6/10.7	i386	i386	i386	i386/x86_64
10.6/10.7	x86_64	i386 *or* x86_64	i386 *and* x86_64	i386/x86_64
>=10.8	x86_64	x86_64	x86_64	x86_64

Thus, removing the kernel architecture tweak altogether would only affect the first three (old platform) cases (relative to the "reasonable" choice), and would only add one architecture in those cases, increasing the disk footprint by a little over 100K in a package that's over 7MB. That doesn't seem unreasonable in the interests of simplicity, and would also fix the current bug.

Although simply removing that one line (119) would be sufficient to fix the build for PowerPC machines (since "Power Macintosh" fails to match "x86_64" just as well as "ppc" or "ppc64" would), I do wonder about the need for the hack in lines 35-37. Indeed the kernel architecture may not necessarily match the userspace architecture, but I believe each combination of userspace architecture and OS version would have exactly one choice of kernel architecture(s) (with the above change), so keying on the former should be a valid way to select precompiled binaries. Or am I missing something here?

[fhgwright (Fred Wright)]

Replying to fw@…:

Although simply removing that one line (119) would be sufficient to fix the build for PowerPC machines (since "Power Macintosh" fails to match "x86_64" just as well as "ppc" or "ppc64" would), I do wonder about the need for the hack in lines 35-37. Indeed the kernel architecture may not necessarily match the userspace architecture, but I believe each combination of userspace architecture and OS version would have exactly one choice of kernel architecture(s) (with the above change), so keying on the former should be a valid way to select precompiled binaries. Or am I missing something here?

There's been no response as to whether the "archive_sites" tweak is really needed, or whether it can be removed.

I've just tested an updated Portfile based on the 2.7.4 release, though I ran afoul of a couple of other issues in the process. I'll post patches soon.

[xanda-escuyer (xanda)]

Cc Me!

[xanda-escuyer (xanda)]

Build log

[fhgwright (Fred Wright)]

Replying to xanda@…:

We think we have the same issue but can't tell for sure. The common denominator is our platform: G4/PPC Mac Mini, running 10.6 Leopard.

Attached is a build log and we'd be grateful for any guidance - even if it's to refer to another ticket or post.

Thanks.

Presumably you mean 10.5 Leopard, since 10.6 is Snow Leopard and doesn't support PPC. :-)

This looks like #46525, which is fixed in the pending update that I attached to #46526. Essentially, it's trying to use incompatible tools to extract content that it has no intention of using. :-)

[xanda-escuyer (xanda)]

Replying to fw@…:

Replying to xanda@…:

We think we have the same issue but can't tell for sure. The common denominator is our platform: G4/PPC Mac Mini, running 10.6 Leopard.

Attached is a build log and we'd be grateful for any guidance - even if it's to refer to another ticket or post.

Thanks.

Presumably you mean 10.5 Leopard, since 10.6 is Snow Leopard and doesn't support PPC. :-)

This looks like #46525, which is fixed in the pending update that I attached to #46526. Essentially, it's trying to use incompatible tools to extract content that it has no intention of using. :-)

Aye it is - 10.5.8 to be precise. Darn fat fingers... ;-) Thanks for reply and look forward to the update.

[drkp (Dan Ports)]

r131918