Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Fantastic to see the effort you’ve been putting into this is paying off @barracuda156! I will have a look at testing either tonight after I finish work or tomorrow hopefully. I’ll stick it on the upgraded Quicksilver.

I vaguely recall there could have been some issues with gnutls dependents.
That was due to incompatible libs API of gnutls vs gnutls-devel. Since I use the latter, it could have been broken with the former.

This is fixed in the latest update to the ports: I bumped gnutls version to the one compatible with gnutls-devel.
So now no related breakages are expected. I can switch locally between -devel and non-devel versions without causing a breakage.

I have uploaded new ports archive today with this and other updates and new packages.
 
[Guess no one is using this anyway, but] gcc-powerpc updated to the latest snapshot (gcc 15-20240901), all Pythons updated to the latest versions, some new pre-built ports added.

One may switch from gcc14 to gcc15 like this:
Code:
sudo port deactivate libgcc14 libgcc 
sudo port -v install libgcc-powerpc gcc-powerpc

Compilers can co-exist, runtime ports cannot (i.e. you can have both installed, but only one active: either standard libgcc14 with its wrapper libgcc port or libgcc-powerpc).
If someone builds MacPorts from source, you will need to borrow a few commits from my tree to be able to use this, since standard MacPorts won’t recognize gcc-powerpc as a legit name.

You could sort packages by date of being modified on macos-powerpc.org/packages to see what’s new and what has been updated recently.

There will probably be no major updates for some time, but there are about 10k+ ports available, all every-day needs should be covered (editors, e-mail, audio, multimedia, browser, discord client, photo processing etc.); there are also a lot of development tools, perhaps all compilers which could be supported (besides obvious C/C++/Fortran/Python/Perl we got Lisp, OCaml, Ruby, Scheme, Idris, Java, Algol, some older Haskell implementations etc.), various sorts of math software (R, maxima, octave, a lot of implementations of BLAS, theorem provers etc.), some science packages.

Some stuff is in WIP state, but likely gonna take a while (I hope to get X server updated to the latest version, fix some multimedia software and try doing something about Qt6; neither of these are expected too soon though).

Ping me for any bugs noticed.

One thing left is to add some instructions, that will be done next week.
 
Got it working!

Been wanting to test it for a while. It's a quad that I solely used to build TFF, which is not necessary anymore with Aquafox around.

Thanks!
 

Attachments

  • Picture 1.png
    Picture 1.png
    687.8 KB · Views: 56
  • Like
Reactions: barracuda156
Got it working!

Been wanting to test it for a while. It's a quad that I solely used to build TFF, which is not necessary anymore with Aquafox around.

Thanks!

Great!

I will upload new archive for ports tomorrow. Currently what is actually available is several days ahead of what portfiles have.
I should force myself to update documentation also for all this LOL

There are some new ports added (build fine on powerpc):


P. S. Try fastfetch, more output and some PPC fixes.
 
  • Like
Reactions: metallizer
Got it working!

Been wanting to test it for a while. It's a quad that I solely used to build TFF, which is not necessary anymore with Aquafox around.

Thanks!

New ports tarball is up, a lot of updates.

(If something does not work, please ping me.

Also if something is really wanted but unavailable.)
 
I ran sync and it all went smooth zero issues.

The only very minor issue that I'm having is that the export PATH command has to be issued in every terminal session to get macports working.

I'll have to open up this machine and clean up the ram sticks. It supposed to have 4 GB, had 3 in the previous printscreen and now is down to 2.
 

Attachments

  • Picture 2.png
    Picture 2.png
    972.7 KB · Views: 41
  • Like
Reactions: barracuda156
I ran sync and it all went smooth zero issues.

The only very minor issue that I'm having is that the export PATH command has to be issued in every terminal session to get macports working.

I'll have to open up this machine and clean up the ram sticks. It supposed to have 4 GB, had 3 in the previous printscreen and now is down to 2.

I am not sure how MacPorts does it automatically: in the documentation they in fact advise to set PATH in shell config manually when building MacPorts from source (which is what I have been doing myself always). That is only done once though, you do not need to export it every time (I only run export PATH when I want to hide MacPorts tree).
 
I am not sure how MacPorts does it automatically: in the documentation they in fact advise to set PATH in shell config manually when building MacPorts from source (which is what I have been doing myself always). That is only done once though, you do not need to export it every time (I only run export PATH when I want to hide MacPorts tree).

Perhaps post-install script, need to check it.
 
Ok, great. Thank you for checking this.

Now when you have time, I need two things to be checked:

1. Whether Qt4-based stuff works correctly (it should, but just in case). A good test will be to install QMPlay2 and try playing some video file (local one, YouTube works only via SMTube, not directly). The app will be in /Applications/MacPorts.

2. Whether X11 ports work. A bit more tricky, but I hope it will. What is needed here:
– wipe out Apple X11 (see above);
– install xorg-server-legacy, reboot the machine;
– install some X11 or GTK app, for example transmission-x11, try launching it.
If the app starts normally with GUI, that’s a success.
What extremely interesting timing on all this, i just put this up when i found it and it might be og use, i'll see during the weekend that the repo is completete and that i got everything. You could use XSDLXserver maybe? https://sourceforge.net/projects/li...XSDL/XServer-XSDL-1.20.51-src.tar.xz/download

Leaving ' my huge cache of old project files and half compiled mid working on whatever i was trying to do back then '
https://github.com/threader/xnu_gcc_libc_etc_darwin

I might see if i can boot 10.6.x of usb or something to test with when i get around to it. Cheers
 
  • Like
Reactions: barracuda156

That appears to be some port of X11 for Android. What could we do with that?

X server works on macOS, including powerpc. In MacPorts install `xorg-server-legacy`.
(I could build a much newer version with some hacks, but it crashes on launch, and I had no time to get back to fixing it.)

I might see if i can boot 10.6.x of usb or something to test with when i get around to it. Cheers

That should work. At least works fine via FireWire.
 
That appears to be some port of X11 for Android. What could we do with that?

X server works on macOS, including powerpc. In MacPorts install `xorg-server-legacy`.
(I could build a much newer version with some hacks, but it crashes on launch, and I had no time to get back to fixing it.)



That should work. At least works fine via FireWire.
Just a quick reply while i read up: read trough the sources. It should build on linux, bsd, and something else, ive not built it in ages. I remembered the sources i had cloned for my github to work with i fell into doubt with. And im sure there was an SVN on sourceforge for that project. I'll need to read up.

I was reading trough the rest of the thread just now and saw that xorg-legacy was built after 'a day'. I'll have some time to read now and maybe even fire up a laptop, if not just for heating.

Edit:

It seems i built it two years ago
 
Last edited:
Just a quick reply while i read up: read trough the sources. It should build on linux, bsd, and something else, ive not built it in ages. I remembered the sources i had cloned for my github to work with i fell into doubt with. And im sure there was an SVN on sourceforge for that project. I'll need to read up.

Ok, but what is the benefit of having it? While SDL2 works via X11, it does not work amazingly well. What do we get from having xserver-xsdl as compared to the existing and working xorg-server-legacy?

P. S. I mean, if you or someone is interested to add `xserver-xsdl` to MacPorts, that’s great, having options never hurts, but if you expect me to deal with this, I need to understand what is the supposed advantage of using it.
 
Okay, so correct me if this isn't right, but I believe this is not an implementation SDL on X, rather it's an implementation of X on SDL.

I don't know what the advantage is though. Speed? Compatibility?
 
Okay, so correct me if this isn't right, but I believe this is not an implementation SDL on X, rather it's an implementation of X on SDL.

I don't know what the advantage is though. Speed? Compatibility?

I get that, but SDL itself (as long as we talk about SDL2+) uses X11 and X server (because Cocoa has been broken since 2.0.3 or so). How this even gonna work, in fact?
 
  • Like
Reactions: Threaderr
I get that, but SDL itself (as long as we talk about SDL2+) uses X11 and X server (because Cocoa has been broken since 2.0.3 or so). How this even gonna work, in fact?
It's and X11 server running in SDL. So basically you get what the apple x11 already does, no hw accel and all that. The thought is compile and link against the osx libsdl.dylib . I've not done much testing here as i had questions about the sources, years ago, they contained hardlinks that would circle everywhere and all so i decided i need to check more but i still haven't dug up the sourceforge svn i was sure i spotted, years ago noting its origins/compatibility with bsd etc. Been busy with other stuff for a while. I'll get back to this as i get around to looking into it again. I've only built it twice and played with it a bit, read some docs and that too was years ago.

How i mostly use it, on android, is say, launch the XSDLXserver, jump to a Termux session and point to the x11 server running in the native android env.
 
Last edited:
Updates to the ports will be done by the end of this month (i.e. October). I am still away from the hardware, so everything is paused.

As things stand, it is very likely that little to nothing will be submitted from my side to MacPorts upstream further on. I intend to keep supporting PowerPC systems (mostly 10.6 and to some extent 10.5) as before, however updates will be done in my fork of MacPorts.
I will think how to make it more convenient for those who is not interested in custom packaging but rather prefers to run builds manually, relying on my fixes.
 
Consider this a pre-release, perhaps: MacPorts-2.10.4.pkg.zip
Installed on one of my PowerBooks, works fine. Indexing ports on a G4 takes forever, but modern Linux on RISC-V was not much better.

Will be changed to release status once I switch my main machine to using this packaging. A matter of days now, I guess.
 
I am running my MacPorts-2.10.5 now on a clean 10.6.8 (native powerpc). Overall, everything works.

There are a few issues at the moment, however:

1. For some reason on 10.6.8 (as opposed to 10a190) MacPorts runs extra post-install scripts, which among other things download and parse ports archive. This takes forever, but is not anywhere obvious: installer just “runs scripts”. This led me to think it froze, so I killed it and rebooted. This resulted in some minor issues with the installation (not a concern for me at the moment, since I want to rebuild MacPorts against 10.6.8 SDK anyway): possibly certain settings were not completed and I had to delete extracted port sources and run `sudo port -v sync` from scratch. Solution is trivial, but unfortunately non-intuitive. Simply running `sudo port sync` does not work if the initial sync was interrupted. I think I have seen such behavior earlier.
I will try to find a way to a) disable everything post-install, since it is more robust to run `port sync` explicitly, and b) figure out why subsequent syncs do not work without wiping extracted port sources. In a meanwhile, recommended solution is:
a) do not interrupt installation and syncing;
b) if it was interrupted, do `sudo rm -R /opt/local/var/macports/sources/macos-powerpc.org` and then run `sudo port -v sync`.
This should be fixed in a day or two.

2. Since I was building ports on a system with a lot of ports installed, select ones linked to extra libraries which are not declared as dependencies. This is upstream MacPorts issue, but no one properly tests it, so these bugs will exist. The only proper solution (besides fixing hundreds of portfiles) is to rebuild everything like it is done on buildbots, i.e. deactivating all ports before every build. This is time-consuming (and building ports already takes a lot of time), but I will generally follow this procedure onwards – and rebuild those ports which I find to be broken ASAP (they are not actually broken, but just linked to extra libraries; however if you install them without having those extra libs, MacPorts will report ports as broken). I believe, this was the issue which @ChrisCharman faced earlier.
This issue does not have an immediate solution, since it will take weeks to rebuild everything (and then if you start building from source yourself, you can also get opportunistic linking to unwanted libs), so just keep in mind: if you get errors which look like this:
Code:
Could not open /opt/local/lib/libXss.1.dylib: Error opening or reading file (referenced from /opt/local/bin/profanity)
this is not a real breakage, it is simply a linking to undeclared dependency which is not installed. Solution is either to rebuild a given port with `sudo port -v -n -s upgrade --force ${portname}` or install libraries which it expects. And ideally report the issue on Trac (this kind of issues are almost certainly MacPorts upstream bugs and not something added by me, as long as ports in question exist in MacPorts upstream).
 
  • Like
Reactions: ChrisCharman
Related issue to what I explained above, but with a tinier footprint: turned out I had a version of gcc-4 installed into `/usr/local`, and about a dozen of ports (out of 12k) linked to a wrong libgcc. I have already rebuilt almost all of those, just two remain unfixed: `openjdk8-powerpc` and `mercury`. Both are multi-hour builds, so while I will fix them shorty, it won't be today itself. I assume `mercury` is not something hugely popular, but for OpenJDK8 here is a trivial fix:

Code:
sudo install_name_tool -change /usr/local/lib/libgcc_s.1.dylib /usr/lib/libgcc_s.1.dylib /opt/local/Library/Java/JavaVirtualMachines/openjdk8/Contents/Home/jre/lib/server/libjvm.dylib

sudo install_name_tool -change /usr/local/lib/libgcc_s.1.dylib /usr/lib/libgcc_s.1.dylib /opt/local/Library/Java/JavaVirtualMachines/openjdk8-jre/Contents/Home/lib/server/libjvm.dylib

Just two commands, and it should be fine. Sorry for an inconvenience.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.