Opened 10 years ago

Closed 10 years ago

#45794 closed defect (fixed)

osxfuse @2.7.0_0: doesn't build on PPC

Reported by: fhgwright (Fred Wright) Owned by: drkp (Dan Ports)
Priority: Normal Milestone:
Component: ports Version: 2.3.2
Keywords: Cc: xanda-escuyer (xanda)
Port: osxfuse

Description

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.

Attachments (3)

build.sh.diff (2.2 KB) - added by fhgwright (Fred Wright) 10 years ago.
Fixes for build.sh
get_arch.sh (214 bytes) - added by fhgwright (Fred Wright) 10 years ago.
Script to get correct machine architecture
osxfusebuild.log (5.9 KB) - added by xanda-escuyer (xanda) 10 years ago.
Build log

Download all attachments as: .zip

Change History (12)

Changed 10 years ago by fhgwright (Fred Wright)

Attachment: build.sh.diff added

Fixes for build.sh

comment:1 Changed 10 years ago by larryv (Lawrence Velázquez)

Owner: changed from macports-tickets@… to dports@…
Summary: osxfuse doesn't build on PPCosxfuse @2.7.0_0: doesn't build on PPC

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

comment:2 Changed 10 years ago by drkp (Dan Ports)

Status: newassigned

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.

comment:3 in reply to:  2 ; Changed 10 years ago by 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).

Changed 10 years ago by fhgwright (Fred Wright)

Attachment: get_arch.sh added

Script to get correct machine architecture

comment:4 in reply to:  3 ; Changed 10 years ago by 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?

comment:5 in reply to:  4 Changed 10 years ago by 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.

Last edited 10 years ago by fhgwright (Fred Wright) (previous) (diff)

comment:6 Changed 10 years ago by xanda-escuyer (xanda)

Cc: xanda@… added

Cc Me!

Version 0, edited 10 years ago by xanda-escuyer (xanda) (next)

Changed 10 years ago by xanda-escuyer (xanda)

Attachment: osxfusebuild.log added

Build log

comment:7 in reply to:  6 ; Changed 10 years ago by 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. :-)

comment:8 in reply to:  7 Changed 10 years ago by 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.

comment:9 Changed 10 years ago by drkp (Dan Ports)

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.