Sounds awesome. Have you opened a PR to legacy-support repo?
P. S. I can try compiling only in Rosetta at the moment, away from PPC hardware for a while, but I am interested
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
Sounds awesome. Have you opened a PR to legacy-support repo?
P. S. I can try compiling only in Rosetta at the moment, away from PPC hardware for a while, but I am interested
I have indeed, although no telling if / when it'll get merged. I haven't heard anything back yet.Sounds awesome. Have you opened a PR to legacy-support repo?
P. S. I can try compiling only in Rosetta at the moment, away from PPC hardware for a while, but I am interested
If you'd like to give it a try, it's pretty easy. First, you need to extract legacy-support with `sudo port -v patch legacy-support`. Then, navigate to the build directory (I think it's under `/opt/local/var/macports/build/`). You then need to edit `src/atcalls.c`. On line 106, this is the code you need to insert:
C:
// Ignore AT_EACCESS, Bug #65569 and #67406
if (flags == AT_EACCESS)
flags = 0; // Zero out flag, ignore request to use effective user IDThen you just continue the install with `sudo port -v install legacy-tools` like normal. After that, you should be able to just install Emacs straight away on an Snow Leopard or newer system.
If on a PPC system, you need to remove the configure checks that stop the build on Leopard and earlier. To do this, do the same extraction process as above with Emacs, with `sudo port -v patch emacs -nativecomp` (I think nativecomp actually works on PPC, at least with GCC 12, but it was taking an extremely long time on my PowerBook G4). Search for the string "Apple Darwin", and it should take you right above a long switch statement that marks different platforms as supported or not. On the apple-darwin-[0-9] line, the unported=yes statement needs to be changed to unported=no . After that, you should be able to run `sudo port -v install emacs -nativecomp` and have it just work.
I did run into a build failure with treesitter-cpp, one of the dependencies for Emacs, but it's an extremely quick fix - just navigate to the file and line of code the error message says, then comment it out (I think it was static_assert() or something like that). Alternatively, you can also build emacs with `sudo port -v install -nativecomp -treesitter`, which bypasses the dependency completely.
Nice, I'll give this a shot. I had tried building modern emacs a while back but ran into a bunch of issues with their Obj-C code.
Take a look at what @catap has replied in your PR. That has to be tested, but possibly we can arrive at a proper fix to the issue.
Static asserts may fail superficially sometimes due to wrong assumptions on size of bool and/or spinlock and associated alignments. Could you quote the log of the failure there?
Unfortunately, I'm only able to get the terminal version working at the moment, the GUI part indeed uses a bunch of Obj-C code that seems to rely on functionality introduced in Snow Leopard.
Yep, I saw his suggested patch. It's definitely the superior solution, and with a few minor tweaks, it works great. I left a comment suggesting we go with his. Hopefully we can get it merged soon.
The exact issue with tree-sitter-cpp is this:
Code:
---> Configuring tree-sitter-cpp
---> Building tree-sitter-cpp
scanner.c: In function 'tree_sitter_cpp_external_scanner_serialize':
scanner.c:128:5: warning: implicit declaration of function 'static_assert' [-Wimplicit-function-declaration]
128 | static_assert(RAW_STRING_DELIMITER_MAX * sizeof(wchar_t) <
| ^~~~~~~~~~~~~
Undefined symbols:
"_static_assert", referenced from:
_tree_sitter_cpp_external_scanner_serialize in scanner.o
ld: symbol(s) not found
collect2: error: ld returned 1 exit statusAs an idea, without looking at the code: you could disable ObjC backend completely and use whatever normal Unix would use. X11, ncurses or whatever is there.
Static assert thing looks trivial and should be solved by adding an appropriate header and/or define.
Take a look: https://trac.macports.org/ticket/64113
ayyyyy!
Unfortunately it appears pkg-config didn't detect a lot of the dependencies I had installed. I'll have to take another pass at this.
Also the icons appear corrupted.
Unfortunately it appears pkg-config didn't detect a lot of the dependencies I had installed. I'll have to take another pass at this.
Also the icons appear corrupted.
So just as an update; the fix to legacy-support was merged, so now users on older versions of OSX should be able to just install emacs and it'll work without any manual fixing required. For 10.5 and older, Emacs unfortunately has a built in configure check that will fail; I'm planning on submitting a patch that disables it.
There are apparently problems with Emacs working in nativecomp mode on at least 10.6, so it may be necessary to use the interpreter with the -nativecomp variant (though to be honest with you, that might be a good idea anyway, as native compilation takes a long time on these older Macs).
For tree-sitter-cpp, it turns out that one needs to include legacy-support for it to build in C11 mode on older OS X versions. I just submitted a patch fixing this, and since it's so short, it'll hopefully be merged soon.
There are apparently problems with Emacs working in nativecomp mode on at least 10.6, so it may be necessary to use the interpreter with the -nativecomp variant (though to be honest with you, that might be a good idea anyway, as native compilation takes a long time on these older Macs
).For tree-sitter-cpp, it turns out that one needs to include legacy-support for it to build in C11 mode on older OS X versions. I just submitted a patch fixing this, and since it's so short, it'll hopefully be merged soon.
Hey! I've been working on getting MacPorts set up on a Power Mac G4 under 10.4.11, but am running into an issue getting legacy-support to build. Log is here if anyone's able to make heads or tails of it. This is a blocker for installing most new things, though, so it'd be nice to get it resolved.
Thank you for taking interest.
We know it is broken on 10.4, and the WIP can be found here: https://github.com/macports/macports-legacy-support/pull/69
You may try installing `legacy-support-devel` port from this PR. If it still fails, please respond in the issue, it will help to fix it faster.
UPD. I can confirm that `legacy-support-devel` from https://github.com/macports/macports-legacy-support/tree/d63ef362afd7800d17be90cb6333d70264d081f9 builds fine on 10.4 and seems to work normally (at least tests pass).
Last edited:
Could someone try this on a PowerPC system? (No idea if it will build on Tiger, but on 10.5–10.6 it should.)
ports.macports.org
Long story short, upstream of mpv killed support for all macOS prior to Catalina (!) in v. 0.37.0. This is supposed to be a port to support earlier systems.
(I have no time to sort the mess with X11 installation, which prevents from using apps which rely on it.)
mpv-legacy | MacPorts
Long story short, upstream of mpv killed support for all macOS prior to Catalina (!) in v. 0.37.0. This is supposed to be a port to support earlier systems.
(I have no time to sort the mess with X11 installation, which prevents from using apps which rely on it.)
There is a temporary fix now, not a good one, but acceptable for the time-being: Tiger has been reverted to a somewhat earlier version which should build. Please update us if you do try.
Could someone try this on a PowerPC system? (No idea if it will build on Tiger, but on 10.5–10.6 it should.)
mpv-legacy | MacPorts
Long story short, upstream of mpv killed support for all macOS prior to Catalina (!) in v. 0.37.0. This is supposed to be a port to support earlier systems.
(I have no time to sort the mess with X11 installation, which prevents from using apps which rely on it.)
Why x11? You should be able to get native backend working even on ppc. After all you just need window bound to opengl context to render the quad.
Well to be honest I assumed it is broken beyond repair, since Macports disabled it even for x86 on everything prior to 10.10: https://github.com/macports/macport...1ab7e7cd6f1/multimedia/mpv/Portfile#L170-L178
For 10.6 and below it was done in 0.26.0 already: https://github.com/macports/macports-ports/commit/25514ec35106cb0203d7f40684abe989dc788b71
Well, I can see if the code can be fixed, but it is a huge gap between versions.
P. S. Without looking at the thing, I expect it to use ObjC, which will not build with gcc at all. Maybe it can be replaced with old code and still work, I would try that.
UPD. With 0.36.0 enabling cocoa fails already at configure check.
UPD2. Cocoa support was broken by https://github.com/mpv-player/mpv/commit/b5ca8c41cc62f1ef097f4fc93525dec8b84f59a0 (at least, might be prior to that).
Which is 0.25.0.
Last edited:
>I assumed it is broken beyond repair,
No, works fine on 10.8-10.9 before non-swift backend was removed (there might have been a 1-line patch required, don't remember).
>Cocoa support was broken by
Yeah it's just trivial polyfill stuff. You could patch it easily and get it working down to 10.6 at least. Below that might be trickier, as the code assumes ARC.
No, works fine on 10.8-10.9 before non-swift backend was removed (there might have been a 1-line patch required, don't remember).
>Cocoa support was broken by
Yeah it's just trivial polyfill stuff. You could patch it easily and get it working down to 10.6 at least. Below that might be trickier, as the code assumes ARC.
Last edited:
I can try throwing away configure checks. It also has a wrong ObjC syntax which cannot work as is with GCC, but that is perhaps easily fixable.
>has wrong ObjC syntax?
Hm yeah there's also some use of blocks in there, which I read gcc doesn't support. I think the more major issue for anything below 10.6 is that libdispatch is used to coordinate between VO and main thread inside the cocoa backend. Again in principle you could replace that with your own dispatch & signaling mechanism (mpv already has its own abstraction) but at that point you're essentially rewriting it.
Hm yeah there's also some use of blocks in there, which I read gcc doesn't support. I think the more major issue for anything below 10.6 is that libdispatch is used to coordinate between VO and main thread inside the cocoa backend. Again in principle you could replace that with your own dispatch & signaling mechanism (mpv already has its own abstraction) but at that point you're essentially rewriting it.
libdispatch needs blocks, that is why it is broken (on 10.6 ppc as well).
Good-written software provides fallbacks to mach semaphores, but most of developers do not care.
Some discussion re libdispatch is here: https://trac.macports.org/ticket/65988
Nothing works, as of now
mpv doesn't actually use GCD semaphores at all, it only uses libdispatch for the dispatch_sync functionality to run things on the main thread while blocking VO thread.
Which is why I mentioned it is theoretically possible to rewrite it to remove this libdispatch dependence. Although I don't actually know how you'd do it. implementing your own dispatch-queue equivalent for a non-main thread is easy (just block on a mutex until signaled then process elements in a work queue), but the main thread is also used by Cocoa for drawing. So just naively blocking would prevent UI updates. So maybe you also have to hook into the CFRunloop functionality. I don't know how devs on 10.5 handled this before libdispatch came along.
Which is why I mentioned it is theoretically possible to rewrite it to remove this libdispatch dependence. Although I don't actually know how you'd do it. implementing your own dispatch-queue equivalent for a non-main thread is easy (just block on a mutex until signaled then process elements in a work queue), but the main thread is also used by Cocoa for drawing. So just naively blocking would prevent UI updates. So maybe you also have to hook into the CFRunloop functionality. I don't know how devs on 10.5 handled this before libdispatch came along.
I got tired of this issues with libdispatch and just built it for PPC. Apparently despite a claim in 10A190 header it does not require blocks to build – it worked with a standard gcc-4.2.
Not tested IRL though. Whether it is actually usable is left to be determined.
Can be installed as libdispatch-legacy port. It will be put into libexec/dispatch, so it will not be automatically found unless flags are added.
This has probably been said, but to re-iterate just in case:
Since almost nobody tests anything even on older Intel systems, forget PPC, stuff gets broken regularly. If no one notices, it will be left broken.
So if you try installing something from Macports and it fails, it may be worth trying again in a few days.
(Or complain here, or open a ticket on Trac.)
Some idea re something being installable may be had from Installations statistic tab on port Details in Macports. Notice, port health is mostly meaningless. If installations shows someone built it for PowerPC, likely it does build or can be built, or at least a recent version worked and can be restored.
P. S. Macports has new release, 2.9.0, seems to work nicely on PowerPC. (For 10.6 you still need to fix portsandbox by hand.)
Since almost nobody tests anything even on older Intel systems, forget PPC, stuff gets broken regularly. If no one notices, it will be left broken.
So if you try installing something from Macports and it fails, it may be worth trying again in a few days.
(Or complain here, or open a ticket on Trac.)
Some idea re something being installable may be had from Installations statistic tab on port Details in Macports. Notice, port health is mostly meaningless. If installations shows someone built it for PowerPC, likely it does build or can be built, or at least a recent version worked and can be restored.
P. S. Macports has new release, 2.9.0, seems to work nicely on PowerPC. (For 10.6 you still need to fix portsandbox by hand.)
Could someone do me a favor and try the following on a PowerPC system (assuming you have a functional Macports setup)?
`xapian-core` is required for the other two, but doing it sequentially does not hurt.
I need to know if everything of these build, and if something fails, see where it does (preferably get the whole log as a text file, not just an error message).
Code:
sudo port -v install xapian-core
sudo port -v install xapian-bindings-ruby31
sudo port -v install nmail`xapian-core` is required for the other two, but doing it sequentially does not hurt.
I need to know if everything of these build, and if something fails, see where it does (preferably get the whole log as a text file, not just an error message).
Last edited:
I tried to install xapian-core with GCC13 on 10.5.8 Powerbook G4, failed with:
EDIT: You specifically asked for a log and not just an error message didn't you? I promise I can read...sometimes =). Attached log.
Code:
libtool: compile: /opt/local/bin/g++-mp-13 -DHAVE_CONFIG_H -I. -I./common -I./include -I/opt/local/include -Wall -W -Wredundant-decls -Wpointer-arith -Wcast-qual -Wcast-align -Wformat-security -fno-gnu-keywords -Wundef -Woverloaded-virtual -Wstrict-null-sentinel -Wshadow -Wstrict-overflow=1 -Wlogical-op -Wmissing-declarations -Wdouble-promotion -Winit-self -Wduplicated-cond -Wduplicated-branches -fvisibility=hidden -fvisibility-inlines-hidden -pipe -Os -D_GLIBCXX_USE_CXX11_ABI=0 -arch ppc -fno-math-errno -MT net/tcpclient.lo -MD -MP -MF net/.deps/tcpclient.Tpo -c net/tcpclient.cc -fno-common -DPIC -o net/.libs/tcpclient.o
In file included from net/tcpclient.cc:29:
net/resolver.h: In constructor 'Resolver::Resolver(const std::string&, int, int)':
net/resolver.h:99:18: error: 'AI_NUMERICSERV' was not declared in this scope; did you mean 'NI_NUMERICSERV'?
99 | flags |= AI_NUMERICSERV;
| ^~~~~~~~~~~~~~
| NI_NUMERICSERV
make[2]: *** [net/tcpclient.lo] Error 1EDIT: You specifically asked for a log and not just an error message didn't you? I promise I can read...sometimes =). Attached log.
Last edited: