[MacPorts] #45794: osxfuse @2.7.0_0: doesn't build on PPC

MacPorts noreply at macports.org
Thu Dec 18 23:45:48 PST 2014


#45794: osxfuse @2.7.0_0: doesn't build on PPC
----------------------+----------------------
  Reporter:  fw@…     |      Owner:  dports@…
      Type:  defect   |     Status:  assigned
  Priority:  Normal   |  Milestone:
 Component:  ports    |    Version:  2.3.2
Resolution:           |   Keywords:
      Port:  osxfuse  |
----------------------+----------------------

Comment (by fw@…):

 Replying to [comment:3 fw@…]:
 > Replying to [comment:2 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?

-- 
Ticket URL: <https://trac.macports.org/ticket/45794#comment:4>
MacPorts <https://www.macports.org/>
Ports system for OS X


More information about the macports-tickets mailing list