Poll for G5 owners about ppc/ppc64 preference

[barracuda156]

This is a practically relevant poll which is meant for anyone having a G5 machine in a working condition. Let me make it explicit: this is not about expressing support for development for macOS on PowerPC. I am interested to know whether it makes sense to allocate some resources for ppc64 or rather use those resources for better support of ppc. That is, nothing can be done in addition to, but only at expense of (time and cpu cycles constraints cannot be changed).

If you do not have a G5 but only have a G4, it is obvious that ppc64 support is of zero interest. It is also obvious that even if you have a G5, but also have a G4, the question is only relevant for G5, while G4 will always need 32-bit ppc – and cannot benefit from ppc64 stuff.
This is already factored in, there is no need to “vote strategically”. 32-bit ppc support is not going anywhere, regardless of results of the poll.

Possible responses are formulated in a context of what is given as a fact. We do not have a choice of preferring ppc64 and more software, since some software never existed for ppc64. There is no choice of preferring the newest OS and ppc64 ports, since 10.6 has no support for ppc64 in the system. Also, while in principle it is possible to have a mixed environment in 10.5, using both ppc and ppc64 ports, it is largely broken in practice.

Thanks!

 

[GA204]

For my G5, I'm in the Tiger OS X 10.4 camp until Classic Environment gets ported over, but for 64-bit vs 32-bit in general, I have the following opinion:

The main advantage of 64-bit instructions is being able to use more than about 3 GB memory for a given program. (If you don't have that much ram, it will use the disk as RAM if it's 64-bit, whereas it will generally just crash if it's 32-bit)

Most software you will probably encounter does not need even 1 GB of memory. For instance, you are very unlikely to be editing text or word documents larger than a few MB, let alone larger than 1 GB, so there is little point in compiling gedit as 64-bit. Similarly, most people are unlikely to need 3 GB for an e-mail client or image editing.

However, for those programs that need it, 64-bit is really useful for software which may need to occasionally use more than 3 GB of memory. A good example is LD, which needs to use more than 3 GB of RAM when linking TenFourKit and other complex programs. Usually these are programs where you are working with especially large files or datasets.

 

[Doq]

See, Apple did things pretty smartly when they added 64-bit support to OS X: It's basically transparent to the end user, whether that's running a 32-bit application on the 64-bit kernel or a 64-bit native application. Of course, this only reasonably applies to actual "real" applications that can have multiple binaries in the package (or not). For something like a Macports, this isn't really a thing that's done and so it more or less does matter what arch the binary is and that's mentioned in the OP.

In that regard, I don't think ppc64 is a useful tangent to pursue outside of specialty applications that need lots of RAM. Linux ppc64 would be more worth it than OS X ppc64, IMO.

 

[barracuda156]

See, Apple did things pretty smartly when they added 64-bit support to OS X: It's basically transparent to the end user, whether that's running a 32-bit application on the 64-bit kernel or a 64-bit native application. Of course, this only reasonably applies to actual "real" applications that can have multiple binaries in the package (or not). For something like a Macports, this isn't really a thing that's done and so it more or less does matter what arch the binary is and that's mentioned in the OP.

I don’t really get what’s different between the two cases. And on 10.5 a process may be 32- or 64-bit, it is visible to a user. Whether it is a proprietary or open-source app.

 

[Doq]

I don’t really get what’s different between the two cases. And on 10.5 a process may be 32- or 64-bit, it is visible to a user. Whether it is a proprietary or open-source app.

Of course. For a power user that wants to know, they can know. But it's not immediately obvious; you have to go out of your way to find out.

 

[GA204]

For something like a Macports, this isn't really a thing that's done and so it more or less does matter what arch the binary is and that's mentioned in the OP.

You can certainly have both ppc64/32 bit versions in the same binary file including MacPorts-style plain executable files and libraries (e.g. in /opt/local or the like):

You can do this by using Mac OS X's "lipo" tool on any DYLIB or executable binary file to add other architectures to it. The Mach-O and library specifications on OS X both support this. You just have to compile the program in both architectures before "lipo'ing" them.

For instance, a couple months ago, I used lipo to make the latest "universal" version of my TLS proxy support PPC32, x86 and amd64.

I did this by compiling the PPC32 code on Tiger and then compiling the x86 and amd64 versions in OS X 10.6 on a friend's Mac (and I think I made the x86 target 10.4 so it should also hopefully work on 10.4+, but I don't own an Intel Mac).

Then, I ran lipo to take all three architectures versions (ppc32, x86, and amd64) of both the application binary and the OpenSSL libraries and put them all together into: one universal Unix application file, and two universal Unix library files (libcrypt and libssl) which can work on any and all of those machines (and work in ppc64 albeit in ppc32 mode).

One thing to be aware of when doing this, though, is that when linking programs, the architecture used for any dependency libraries must match exactly (albeit the match can be within a "fat"/universal version of the library file, as above).

Of note, the transition from x86 to amd64 was a little different since Apple removed 32-bit x86 support and libraries from their OS aftter 10.14 Mojave (hence why I included both x86 and amd64 support in the universal version of my proxy program, albeit if your Mac OS is 10.15+, you probably don't need my program).

I haven't used Linux on x86/amd64 in a long time, but from what I recall it doesn't have a lipo equivalent and so on Linux you seem to need separate library files to support mulitple architectures (e.g. x86, amd64, etc.) unlike OS X.

 

[barracuda156]

You can certainly have both ppc64/32 bit versions in the same binary file including MacPorts-style plain executable files and libraries (e.g. in /opt/local or the like):

You can do this by using Mac OS X's "lipo" tool on any DYLIB or executable binary file to add other architectures to it. The Mach-O and library specifications on OS X both support this. You just have to compile the program in both architectures before "lipo'ing" them.

There are two distinct cases when we consider universal builds: anything which builds with Xcode compiler and anything which does not. Xcode compilers (gcc-4.* in cases of 10.4–10.6, clang later) accept multiple archflags at once, so [normally] nothing is needed, it just works in the same way for the user as compiling for a single arch. In the context of powerpc, anything which can be built with Xcode gcc, trivially builds for ppc+ppc64, for example (unless, of course, there are some bugs in a software which is being built). There are a few exceptions to this, perhaps related to specific optimizations. Anything which needs C11/C++11 (or just fails to build with gcc-4.*) becomes a pain, since modern gcc does not accept multiple archflags. MacPorts handles that via muniversal portgroups. The problem is that a) there are two of them (don’t ask); b) ports which need them more often than not do not have them in a portfile; c) just adding PG may not be enough, may or may not work, and needs to be tested, etc. It is that part which is broken. Building something like `libffi` can be simply done by passing `+universal` on command line.