[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