Looks like I got it working (beyond a toy example). This is still via mrustc, but it serves the purpose.
Here is as-tree port:
Here is as-tree port:
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.
I have fixed Rust for powerpc (via mrustc, but it works with real apps now)
- Thread starter barracuda156
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
Is PPCPorts able to be installed on top of an existing MacPorts installation? I run `sudo port sync` and then `sudo port install mrustc` and I get "mrustc cannot be installed for the configured build_arch 'ppc' because it only supports the arch(s) 'arm64 x86_64'.
I haven't had much success with PPCPorts, and I'm not sure if it's because of the way I set it up or if there's something I'm doing wrong. Trying to install `fastfetch` for example fails when installing dependency `brotli` (failed to build brotli: command execution failed).
edit: I forgot the main difference between your environment and mine is that I'm running 10.5 and you're probably testing all of this stuff on 10.6. I ran into issues with Xcode on 10.6 but I'll have to take another crack at it.
I haven't had much success with PPCPorts, and I'm not sure if it's because of the way I set it up or if there's something I'm doing wrong. Trying to install `fastfetch` for example fails when installing dependency `brotli` (failed to build brotli: command execution failed).
edit: I forgot the main difference between your environment and mine is that I'm running 10.5 and you're probably testing all of this stuff on 10.6. I ran into issues with Xcode on 10.6 but I'll have to take another crack at it.
1. Upgrading on top of existing MacPorts should work, but a) deactivate all ports prior to that and b) either delete /opt/local/etc/macports before installing or edit configs after. They are not overwritten.
It is probably a good idea to back up /opt/local/var/macports/software directory. That way, even if you wipe out the whole of MacPorts, you can always install compiled ports back (not a convenient procedure, so this is just a safe-guard).
2. Testing on 10.5 is occasional and limited, but failures will be addressed, at least for fundamental ports. Please open an issue (with attached logs). What I am not gonna do is try to guess what fails or pro-actively test evert port on Leopard: there is no time/resources for that.
P. S. It might work to pull over select ports without switching to PPCPorts base, but that is not and won’t be supported.
Last edited:
It will not work out of the box, because essential components (binaries, not libs) are Intel-only.
What I do myself and advise to follow is described here: https://macos-powerpc.org/installation.html
Some issues gonna pop up once in a while, since this procedure only installs required Unix tools but not everything which may be used. Solution is either a) just to use ports (bison, flex, m4 etc.) or b) recompile/borrow from 10a190 whatever remains. In most cases you are good with ports.
It takes a lot of time & effort to get something building this way. But looks like with enough motivation builds can work (not the latest version though).
I wanted to get a few example apps working, so here is the list. I did not test functionality beyond very basic, but at least apps launch and behave sensibly.
as-tree
eva
ned
ripgrep
Upd. skim added now.
I wanted to get a few example apps working, so here is the list. I did not test functionality beyond very basic, but at least apps launch and behave sensibly.
as-tree
eva
ned
ripgrep
Upd. skim added now.
Last edited:
@Forest Expertise If you still want to try this on 10.4, now it is meaningful, since at least you can build something and confirm it works.
Thank you for your hard work on this. I was trying to build last night, but unfortunately it requires posix_spawn stuff, which doesn't exist on Tiger. I know @kencu mentioned he was working on a posix_spawn implementation for Tiger at one point. If he is able to share that work, it would help immensely. Otherwise I will need to patch out all the unsupported posix_spawn functions and try to replace them with something that works. Trivial compared to the immense work you have put in to get this working on PowerPC Mac OS X at all, but still difficult by my standards.
Nim may be higher priority, and also easier, since most of its fixes for Tiger are just the same fix over and over, iirc.
This is cool! Possibly stupid question—if mrustc works, why doesn't mainline Rust? Can't you just use mrustc to compile Rust?
Because “blazing fast” crab compiler cannot figure out which target machine to create for the triple 🤷🏻♂️
Support PowerPC: rustc itself builds fine, LLVM target is not created correctly · Issue #300 · thepowersgang/mrustc
What is needed to support building for PowerPC? Currently mrustc builds, but rust tries to build for x86: test -e bin/mrustc /usr/bin/make -C tools/minicargo/ make[1]: Nothing to be done for `all'....
github.com
It looks to me as badly written code. This issue should never arise at all with native compilation. Here it became a non-trivial obstacle, making rustc binary unusable despite being fine otherwise (no segfaults, it just does not want to use what is available).
The rust compiler is a frontend that generates intermediate representation (IR) code. By default, it then uses LLVM to optimize and generate machine code.
Code generation - Rust Compiler Development Guide
A guide to developing the Rust compiler (rustc)
rustc-dev-guide.rust-lang.org
LLVM has somewhat limited support for architectures, especially old or very niche architectures, and does not support powerpc-darwin-* as a target triple, so if you try to make it use that triple, it just tells you that and stops.
There is work ongoing to allow rust to use other codegens besides LLVM as a middle/backend, and one of those is a gcc backend. This is being actively developed, and if it is finished, gcc does support powerpc-darwin-* as a target triple.
GitHub - rust-lang/rustc_codegen_gcc: libgccjit AOT codegen for rustc
libgccjit AOT codegen for rustc. Contribute to rust-lang/rustc_codegen_gcc development by creating an account on GitHub.
github.com
The good news there is that the gcc code generator for rust can be worked on using a current machine of nearly any architecture, and if it were finished there a lot of other archs that would then be supported by rust beyond just powerpc-darwin-* ... so it seems to me much more likely to be something that is completed someday.
Just to be clear, I use a port of LLVM based on Iain’s 7.1.1 fork, so it does support powerpc*-apple-darwin triple, and can work as the back-end with lfortran, for example.
It is something in rustc which messes things up, and I tried a lot of ways to set target specs and the triple (starting from reproducing x86 with replaced values, then setting triple explicitly like it’s done for some archs with Linux and was done for macOS earlier, tried triple with and without version added – since LLVM reports versioned triple, etc.), nothing works.
What the code should do is to pick default triple which LLVM is built for, like it is done for arch normally (we don’t need to pass -arch ppc when building natively unless there is some mess up). Instead, it fails at matching triple with the target (for unknown reason) and then just fails, while it should have fallen back to default.
@kencu Besides, Ken, if you have an interest in getting rustc to work, I will appreciate your help. You can see current patches in my mrustc port, that should build mrustc-rust up to initial rustc binary and fail at that with this error: https://github.com/thepowersgang/mrustc/issues/300#issuecomment-3541085494
Same for rustc 1.39 and 1.54 (I use the latter now, with patches to restore llvm-7 compat). LLVM itself accepts all sane forms of powerpc-apple-darwin*. But it breaks down on rustc picking it. The issue seems to have affected some other platforms, but so far I could not figure out what causes it for us.
P. S. ppc64 build is broken due to one of vendor libs, only ppc is usable at the moment.
Same for rustc 1.39 and 1.54 (I use the latter now, with patches to restore llvm-7 compat). LLVM itself accepts all sane forms of powerpc-apple-darwin*. But it breaks down on rustc picking it. The issue seems to have affected some other platforms, but so far I could not figure out what causes it for us.
P. S. ppc64 build is broken due to one of vendor libs, only ppc is usable at the moment.
As you point out in the commits and patches in your rust fork for powerpc, Iain's llvm-7.1 for powerpc is incomplete, and does not support the actual Darwin PowerPC ABI. That means it does not put arguments into the proper registers when interacting with other software.
So ... it may be able to build things, but with what ABI layout is the question? That has been the question for years now. It generates machine code, but that code is broken in important ways. Some things do work -- probably things that never interact with other software or system libraries -- but other things do not.
That being said, I looked through the work you've done here, which is (I believe) the active fork and branch:
github.com
The proximate reason why using the powerpc-darwin-* triple immediately fails doesn't jump out at me, but rust has always been a tricky build and I find it hard to work on. I'm not alone there.
Rust lays out the various architectures it plans to support with the llvm backend and has configuration files for each one it supports. Best guess is that there is still some part of these rust configuration files that is still missing for the powerpc-darwin-* architecture, and that generates the error you're seeing.
I'm still thinking the gcc backend for rust is going to be the only viable path forward.
In the meantime, getting mrustc to compile the really essential software parts and libraries that are currently only available in rust would seem to be the best short-term hope.
So ... it may be able to build things, but with what ABI layout is the question? That has been the question for years now. It generates machine code, but that code is broken in important ways. Some things do work -- probably things that never interact with other software or system libraries -- but other things do not.
That being said, I looked through the work you've done here, which is (I believe) the active fork and branch:
Commits · barracuda156/rust
Fix rustc for PowerPC, WIP. Contribute to barracuda156/rust development by creating an account on GitHub.
github.com
The proximate reason why using the powerpc-darwin-* triple immediately fails doesn't jump out at me, but rust has always been a tricky build and I find it hard to work on. I'm not alone there.
Rust lays out the various architectures it plans to support with the llvm backend and has configuration files for each one it supports. Best guess is that there is still some part of these rust configuration files that is still missing for the powerpc-darwin-* architecture, and that generates the error you're seeing.
I'm still thinking the gcc backend for rust is going to be the only viable path forward.
In the meantime, getting mrustc to compile the really essential software parts and libraries that are currently only available in rust would seem to be the best short-term hope.
If we can get `librespot` building we should be able to port over a Spotify client.
Spotify changed their API recently but with `librespot` you can still make the Mac act as a Spotify Connect device, and while you might not be able to view playlists and select songs from that device, you can still use it for playback.
I'll add this to the growing list of things I wanna port over eventually.
EDIT: I get an error related to Unwind semantics when I build mrustc on Leopard. I think I can edit the `config.toml` to tell rustbuild to build std using abort-only panics, but I'm not sure if that's the move here...
Spotify changed their API recently but with `librespot` you can still make the Mac act as a Spotify Connect device, and while you might not be able to view playlists and select songs from that device, you can still use it for playback.
I'll add this to the growing list of things I wanna port over eventually.
EDIT: I get an error related to Unwind semantics when I build mrustc on Leopard. I think I can edit the `config.toml` to tell rustbuild to build std using abort-only panics, but I'm not sure if that's the move here...
Last edited:
Yeah, that’s what @Matias_ reported recently: https://github.com/macos-powerpc/powerpc-ports/issues/62#issuecomment-3720532444
The issue is that while 10.6 (incl. unofficial powerpc version) has libunwind in the system, 10.5 does not. It should work if libunwind (from ports) is linked, we just need to figure out how exactly to do that in this case.
I need to get better at checking GitHub and opening issues for things... will continue over there if I find any way forward.