By the way, if anyone would be interested to see whether a particular port builds for PPC, Macports’ “port health” is totally meaningless for that purpose, since no buildbots running on PPC. Often there will be a question mark, but any status means nothing. What may carry some useful information is Installation statistics – if someone installed a port for PPC, likely it either works or is fixable. One problem with those stats is that few people use PPC Macs to begin with, and then those using don’t bother submitting statistics (which is very unfortunate, since it demotivates developers to maintain support for PPC). So absence of installations does not mean a port is broken.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Macports development for PowerPC (10.4, 10.5, 10.6): [unofficial] invitation to cooperate
- Thread starter barracuda156
- Start date
-
- Tags
- development macports powerpc
- Sort by reaction score
Moral of the story: if you use Macports install the mpstats package (please)! I usually check by looking at the stats and seeing if there's anything remotely close to or including 10.5 and then actually trying to build the port and weed back through the dependencies that fail. It is a bit cumbersome, but it doens't sound like there's a better way based on your post.
As a semi-random aside, I've been meaning to ask you: is there a way to "hold" MP packages, similar to how APT/aptitude can hold debian packages, preventing them from being upgraded? I made a hack-ish script to strip things like gegl and libsdl2 out of the outdated packages list when doing upgrades, but it still requires manual tinkering every time I run selfupdate again. It would be convenient if I could do the simple 'upgrade outdated'; is that wishful thinking?
1. That is not enough for older systems (perhaps anything lower than Darwin 13? not sure), because system curl is too old, so mpstats fails to actually work. What you need to fix that is this: https://forums.macrumors.com/thread...-rosetta.2332711/?post=30906371#post-30906371
2. Yes, sure. You do exactly the same thing which you need for development in Macports – have a local overlay repo: https://guide.macports.org/chunked/development.local-repositories.html
Ok, I did not realize that mpstats used curl. I don't recall seeing any sort of warning, mpstats just installed as far as I'm aware.
This whole time I thought I'd been sending stats but apparently I haven't been.
This whole time I thought I'd been sending stats but apparently I haven't been.
Ok, thank you, I think that makes sense. If I'm following you correctly, are you saying make a local Portfile repo and place "dummy" Portfiles for the packages I want held into the local repo? The "dummy" Portfiles I would make should have the same version number(s) as the [old] package(s) I have currently installed (and hence don't want upgraded), is that correct?
TBH I never thought to put dummy portfiles there, but yeah, if you never need to rebuild them, that could work. For a while. You may need to rebuild them eventually after something like ICU is updated (or you get stuck at old versions with more and more packages unnecessarily). I would recommend having functional portfiles, just pegged to an older version. Ideally, these should be submitted to Macports (either making a -legacy portfile or setting up a variant – see examples).
Ok, I did not realize that mpstats used curl. I don't recall seeing any sort of warning, mpstats just installed as far as I'm aware.
This whole time I thought I'd been sending stats but apparently I haven't been.
It is supposed to use system tools, so no dependency is declared (in-tree dependency would be a bad idea anyway).
But yeah, to make it work you need a bootstrap tree and rebuilding the main one as --with-curlprefix=. No need to update bootstrap tree too often though. Set it up once and forget.
Everyone using MacPorts, please install mpstats to give an accurate measure of how many people are using it on PPC or whatever version of MacOS you're using! However, mpstats is still not working out of the box for 10.4/10.5. You can check for errors after running it manually by running
If you get an error (likely unless they've fixed it) this is the method I've tried on 3x (2x 10.5, 1x 10.4) hosts with success. Install MacPorts via the traditional methods
Code:
/opt/local/libexec/mpstats submitIf you get an error (likely unless they've fixed it) this is the method I've tried on 3x (2x 10.5, 1x 10.4) hosts with success. Install MacPorts via the traditional methods
- Install libressl (quicker to compile and more lightweight than openssl)
- Install curl
- Recompile MacPorts with the updated curl:
Code:
./configure --with-curlprefix=/opt/local make sudo make install - Install mpstats
- Test to make sure it works!
This is possible, but suboptimal solution. It is better to build it against a standalone tree with curl: https://forums.macrumors.com/thread...-rosetta.2332711/?post=30906371#post-30906371
It was discussed on Trac earlier, I do not have a link at hand.
I apologize in advance if this is a daft question, but it's driving me nuts.
I am trying to get Despotify sorted out, and rather than take the time to study the un-commented source and update it to use Openssl3, I'd rather just tell it to use Openssl 1.0.x. Obviously macports has an Openssl10 port available which I've installed.
I added the following to despotify Portfile:
I don't get any errors, however every time I go to build this somehow Openssl3 pops up and starts writing environment variables! I don't see any references at all to openssl3 in the Portfile nor do I see any in the patch files; does anyone know why it's getting invoked?
For context, I'm seeing this every time when trying to build (I want openssl 1 vars, not openssl3):
Obviously I could manually go in and fix all this, but I'd much rather do it correctly (and then maybe we could even get a shiny new port in our Macports PPC collection!)
I am trying to get Despotify sorted out, and rather than take the time to study the un-commented source and update it to use Openssl3, I'd rather just tell it to use Openssl 1.0.x. Obviously macports has an Openssl10 port available which I've installed.
I added the following to despotify Portfile:
Code:
PortGroup openssl 1.0
PortGroup LegacySupport 1.0
depends_build port:openssl10
depends_lib port:openssl10 \
path:lib/openssl-1.0/libssl.dylib:opensslI don't get any errors, however every time I go to build this somehow Openssl3 pops up and starts writing environment variables! I don't see any references at all to openssl3 in the Portfile nor do I see any in the patch files; does anyone know why it's getting invoked?
For context, I'm seeing this every time when trying to build (I want openssl 1 vars, not openssl3):
Code:
DEBUG: Running callback openssl::set_openssl_dependency
DEBUG: openssl: Set OpenSSL Branch dependency 3
DEBUG: Finished running callback openssl::set_openssl_dependency
DEBUG: Running callback openssl::check_for_cmake
DEBUG: Finished running callback openssl::check_for_cmake
DEBUG: Running callback openssl::configure_build
DEBUG: openssl: Configure Types 'env_vars pkgconfig build_flags' Branch 3
DEBUG: openssl: -> Setting openssl environment variable configuration
DEBUG: openssl: -> Will append OPENSSLDIR=/opt/local/libexec/openssl3 to extract.env
DEBUG: openssl: -> Will append OPENSSLDIR=/opt/local/libexec/openssl3 to configure.env
DEBUG: openssl: -> Will append OPENSSLDIR=/opt/local/libexec/openssl3 to build.env
DEBUG: openssl: -> Will append OPENSSLDIR=/opt/local/libexec/openssl3 to destroot.env
DEBUG: openssl: -> Will append OPENSSLDIR=/opt/local/libexec/openssl3 to test.env
DEBUG: openssl: -> Will append OPENSSL_DIR=/opt/local/libexec/openssl3 to extract.env
DEBUG: openssl: -> Will append OPENSSL_DIR=/opt/local/libexec/openssl3 to configure.env
DEBUG: openssl: -> Will append OPENSSL_DIR=/opt/local/libexec/openssl3 to build.env
DEBUG: openssl: -> Will append OPENSSL_DIR=/opt/local/libexec/openssl3 to destroot.env
DEBUG: openssl: -> Will append OPENSSL_DIR=/opt/local/libexec/openssl3 to test.envObviously I could manually go in and fix all this, but I'd much rather do it correctly (and then maybe we could even get a shiny new port in our Macports PPC collection!)
To choose OpenSSL other than 3.0, you need to add openssl.branch to the portfile.
See: https://github.com/macports/macports-ports/blob/master/_resources/port1.0/group/openssl-1.0.tcl
Example: https://github.com/macports/macport...c88d1ee2d823a745f959/www/Deriv/Portfile#L7-L9
And remove any openssl mentions from depends_lib and depends_build. Portgroup will handle that.
I have added a port for Virtuoso-5, which hopefully gonna work with KDE4 ports: https://github.com/macports/macports-ports/pull/19650
(Later versions are either broken completely or broken for PPC.)
UPD. This one has been merged, so can be installed normally via sudo port install virtuoso (on ppc/ppc64 virtuoso-5 will be chosen).
(Later versions are either broken completely or broken for PPC.)
UPD. This one has been merged, so can be installed normally via sudo port install virtuoso (on ppc/ppc64 virtuoso-5 will be chosen).
Last edited:
Some updates on these:
Go:
There are two routes in principle, via Go and via gccgo.
Problem with gccgo: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986
gccgo: compilation fails on Darwin · Issue #463 · golang/go
by f.guerrieri: What steps will reproduce the problem? 1. After the fix of issue #392 I updated the svn repo 2. from a clean objdir run configure and make 3. wait for the compilation to fail What i...
github.com
Problem with Go: ppc32 support exists in out-of-tree branch of 1.9, but we need Go to build Go, and the one bootstrappable from C is Intel-only.
GHC:
Support for Darwin PPC can be restored with moderate effort, see: https://gitlab.haskell.org/ghc/ghc/-/issues/16106
However, it will not build with 7.6.3, the latest one I was able to build, see: https://trac.macports.org/ticket/64698
So GHC has to be cross-compiled.
That gonna require:
0. If using 10.6.8 (perhaps easier due to Rosetta), fix the latest GHC for 10.6 Intel (likely minor effort or reasonable).
1. Build cross-gcc.
2. Figure out how to cross-compile GHC, and outside of Macports, since no support there. This looks pretty non-trivial.
NodeJS / v8:
Looks doable, but needs some fixes to PowerPC assembler for 32-bit support.
WIP here, but beware, this will not build through completion: https://github.com/barracuda156/node-ppc
GitHub - barracuda156/macports-ports at nodejs20
The MacPorts ports tree. Contribute to barracuda156/macports-ports development by creating an account on GitHub.
github.com
OCaml:
Drop the idea, since OCaml 5 removed support for all 32-bit. Use bytecode which should still work and is supported.
Keka:
Drop the idea, there is no sources for new versions, no point in fixing an archaic one.
OpenJDK8:
Should be doable. Currently stuck at MacOS-specific code in AWT libs. It turned non-trivial to turn off silly MacOS stuff completely and use X11. Otherwise may work.
mpstats works. Power Mac G4. Just submitted. I can test stuff if anyone needs... this thing is just sitting here using up my electricity honestly.
That should be possible in principle, provided ppc(32) is restored and Darwin ABI is added. This may be non-trivial to implement via Macports. I also do not know the exact procedure.
I think it is a bit more complicated than that.
Go has Darwin/amd64, and (previously) Darwin/386, but does not have Darwin/ppc nor Darwin/ppc64.
Go used to have Darwin10 (Snow Leopard) support, but the requirement is now Catalina.
Go has Linux/ppc64. Previously this was PPC970 (G5), but has since been bumped to POWER8 and will not run on Linux/G5. Also, they only officially ship ppc64le (little endian). You can still build big endian, but it isn't "supported".
There is currently no ppc(32) support in Go.
However, via gccgo, you can actually get a working Linux/ppc32 go implementation. However, gccgo does not support Darwin/ppc.
So this will be a multi-pronged effort:
Go has Darwin/amd64, and (previously) Darwin/386, but does not have Darwin/ppc nor Darwin/ppc64.
Go used to have Darwin10 (Snow Leopard) support, but the requirement is now Catalina.
Go has Linux/ppc64. Previously this was PPC970 (G5), but has since been bumped to POWER8 and will not run on Linux/G5. Also, they only officially ship ppc64le (little endian). You can still build big endian, but it isn't "supported".
There is currently no ppc(32) support in Go.
However, via gccgo, you can actually get a working Linux/ppc32 go implementation. However, gccgo does not support Darwin/ppc.
So this will be a multi-pronged effort:
- Darwin support: get go-1.5 (which works on 10.6/x86) working on 10.5/x86 and 10.4/x86, then do go-1.6 ... go-1.21
- PPC970 support: this broke somewhere around go-1.9. Restore it and port up through go-1.21
- PPC32 support: starting with the linux/ppc64 port, implement linux/ppc32
- Darwin/PPC32 support: finally, make it work for 10.5/ppc32 and 10.4/ppc32
- add Darwin support to gccgo
Last edited:
A few baby steps I've taken in this direction:
- go-1.4 working on Leopard/x86: https://github.com/cellularmitosis/go/tree/go-1.4.3-darwin9
- go-1.5 working on Leopard/x86: https://github.com/cellularmitosis/go/tree/go-1.5.4-darwin9
- go-1.6 working on Leopard/x86: https://github.com/cellularmitosis/go/tree/go-1.6.4-darwin9
I'm putting the puzzle pieces together here me thinks....is this also you?
https://github.com/pepaslabs/go-ppc
..~.because that's what I was working off of to try a "fool hardy" attempt at getting a working Go. If that is the case, I will defer to your posts here instead =)
https://github.com/pepaslabs/go-ppc
..~.because that's what I was working off of to try a "fool hardy" attempt at getting a working Go. If that is the case, I will defer to your posts here instead =)
>Go used to have Darwin10 (Snow Leopard) support, but the requirement is now Catalina
Note that not even macports has go 21 running on even 10.9, but this is actually "simple enough" to patch, it's just that legacysupport doesn't yet polyfill all the needed functions (iirc it was something related to TLS and then a syscall that was only added to work around a bug in Yosemite so could be removed).
Note that not even macports has go 21 running on even 10.9, but this is actually "simple enough" to patch, it's just that legacysupport doesn't yet polyfill all the needed functions (iirc it was something related to TLS and then a syscall that was only added to work around a bug in Yosemite so could be removed).
Haha, yeah that was my first attempt from like 3 years ago. Didn't get very far with that one
I spent a couple of days tinkering around, and I've finally gotten a modern version of Emacs (29.1) to compile again on PPC. It currently doesn't work due to some missing functionality in legacy-support, but I submitted a patch that works around the issue. If anyone would like to try it early, let me know and I can write a guide on installing it.
As a side effect, it should (I can't personally test since I don't have an Intel Mac) also restore Emacs support for 10.6-10.8 as well, which seems to have been broken for a while now.
As a side effect, it should (I can't personally test since I don't have an Intel Mac) also restore Emacs support for 10.6-10.8 as well, which seems to have been broken for a while now.