Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bring back support of PowerPC for Darwin: specific steps? #11216

Closed
barracuda156 opened this issue Apr 23, 2022 · 10 comments
Closed

Bring back support of PowerPC for Darwin: specific steps? #11216

barracuda156 opened this issue Apr 23, 2022 · 10 comments

Comments

@barracuda156
Copy link

I want to bring back support for powerpc-apple-darwin & powerpc64-apple-darwin into ocaml. A quick look into the source code revealed that some sections of the current @4.14.0 still contain support for Darwin PPC (somewhat oddly denoting it as Rhapsody), while one necessary file has been removed – power-rhapsody.S: now runtime has only power.S – which should be in fact power-elf.S (like it was before). Restoring the file itself is trivial, since nothing changed with G4/G5 since then. Another necessary change is to bring back register definitions etc into asmcomp/power/proc.ml.

After patching configure to allow for powerpc-apple-darwin, replacing power.S with Rhapsody file and fixing proc.ml and arch.ml, compilation of ocaml ran on 10.6 PPC for quite a while, eventually failing with ld complaint about duplicate _caml_callback_exn symbol in power_libasmrunpic.o and callback.npic.o. I have not yet tried to figure out why that occurred. Anyway, so far it looks promising, unless I miss something out.

Any suggestions and hints are very much welcomed :)

@barracuda156
Copy link
Author

UPD. Okay, I know the reason of a duplicate symbol. In the last (?) version which had power-rhapsody.S, @4.0.2, caml_callback_exn was defined there, while in @4.14.0 it is defined globally. Since I simply borrowed the old file to replace power.S, it resulted in a contradiction. So I have to actually try rewriting Darwin PPC definitions in the style of the new power.S.

This is the version compatible with Darwin: https://github.com/digitalocean/ocaml/blob/do/trusty/asmrun/power-rhapsody.S

@gasche
Copy link
Member

gasche commented Apr 24, 2022

I want to bring back support for powerpc-apple-darwin & powerpc64-apple-darwin into ocaml

If this is just an experiment on your side, more power to you. But given the tag "feature request" I assume that you would like upstream to re-integrate this support. This begs the question: why? I suppose it was removed because Apple does not use PowerPC anymore, so the user base was shrinking fast and not justifying the maintenance burden. Can you explain why you think we should take on new maintenance work for PowerPC+Darwin now?

@barracuda156
Copy link
Author

I want to bring back support for powerpc-apple-darwin & powerpc64-apple-darwin into ocaml

If this is just an experiment on your side, more power to you. But given the tag "feature request" I assume that you would like upstream to re-integrate this support. This begs the question: why? I suppose it was removed because Apple does not use PowerPC anymore, so the user base was shrinking fast and not justifying the maintenance burden. Can you explain why you think we should take on new maintenance work for PowerPC+Darwin now?

@gasche Thank you for replying! I don’t really ask or even assume someone else gonna fix stuff for me, though I find it upsetting when PPC Darwin is pro-actively removed while users exist (this happened with ghc, ruby and llvm too, for example): it makes it harder to make it work and harder to “sell” PRs.

So I rather ask for opinions from those who know ocaml internally. I mean, in some cases fixing a particular arch is trivial or at least a matter of time-consuming, but straightforward procedure. In other it may be completely non-trivial or impossible (well, given that ocaml @4.0.2 had PPC, it should not be that hard).

If I will make it work on my end, I can open PR, and if upstream won’t be interested nevertheless, I will at least make it available via patches in Macports. (I am sorta volunteering to fix ports for PPC as long as I have some time and motivation – I got G5 Quad, so building is relatively fast.)

@gasche
Copy link
Member

gasche commented Apr 24, 2022

For OCaml 4.14, my guess would be the same as yours, it's probably not too hard to restore support for another PPC variant. If there is no sign of new use-cases, it's probably not going to be integrated and maintained upstream, but indeed asking for help to prepare patches in downstream distributions makes perfect sense.

For the in-development OCaml 5.0 however, things will be more difficult for now because the runtime has changed significantly due to the merge of the Multicore runtime. Only a few backends are available on 5.0, significantly fewer than for the 4.x series. There is no PowerPC backend for now, with no clear date for when a backend would be available. (I don't know if anyone is working on it, my understanding is that very few active OCaml users care about PowerPC anymore.) And it's more work to implement/maintain a 5.0 backend due to multicore / memory-model questions.

@barracuda156
Copy link
Author

For OCaml 4.14, my guess would be the same as yours, it's probably not too hard to restore support for another PPC variant. If there is no sign of new use-cases, it's probably not going to be integrated and maintained upstream, but indeed asking for help to prepare patches in downstream distributions makes perfect sense.

For the in-development OCaml 5.0 however, things will be more difficult for now because the runtime has changed significantly due to the merge of the Multicore runtime. Only a few backends are available on 5.0, significantly fewer than for the 4.x series. There is no PowerPC backend for now, with no clear date for when a backend would be available. (I don't know if anyone is working on it, my understanding is that very few active OCaml users care about PowerPC anymore.) And it's more work to implement/maintain a 5.0 backend due to multicore / memory-model questions.

Thank you. I guess fixing 4.14 or whichever will be there of 4.x series will be good enough. I will look into it in more detail and return here if cannot figure something out or – hopefully – with some evidence of success.

@barracuda156
Copy link
Author

@gasche I got quite a bit further with the build after fixing duplicate symbol definition, but now it failed on the following:

/opt/local/bin/gcc-mp-11 -arch ppc -shared                    -flat_namespace -undefined suppress -Wl,-no_compact_unwind -read_only_relocs suppress                    -L/opt/local/lib -Wl,-headerpad_max_install_names -arch ppc -o libasmrun_shared.so startup_aux.npic.o startup_nat.npic.o main.npic.o fail_nat.npic.o roots_nat.npic.o signals.npic.o signals_nat.npic.o misc.npic.o freelist.npic.o major_gc.npic.o minor_gc.npic.o memory.npic.o alloc.npic.o compare.npic.o ints.npic.o floats.npic.o str.npic.o array.npic.o io.npic.o extern.npic.o intern.npic.o hash.npic.o sys.npic.o parsing.npic.o gc_ctrl.npic.o eventlog.npic.o md5.npic.o obj.npic.o lexing.npic.o unix.npic.o printexc.npic.o callback.npic.o weak.npic.o compact.npic.o finalise.npic.o custom.npic.o globroots.npic.o backtrace_nat.npic.o backtrace.npic.o dynlink_nat.npic.o debugger.npic.o meta.npic.o dynlink.npic.o clambda_checks.npic.o afl.npic.o bigarray.npic.o memprof.npic.o domain.npic.o skiplist.npic.o codefrag.npic.o power_libasmrunpic.o -lm 
ld: relocation used in _caml_system__code_begin from power_libasmrunpic.o not allowed in slidable image
collect2: error: ld returned 1 exit status
make[3]: *** [libasmrun_shared.so] Error 1

@barracuda156
Copy link
Author

Apparently the problem is ages old and never had been addressed for PPC.
However possibly related errors on 32-bit BSD were addressed: #10835
I will see if this can be of help in my case.

@xavierleroy
Copy link
Contributor

I find it upsetting when PPC Darwin is pro-actively removed while users exist (this happened with ghc, ruby and llvm too, for example):

The last macOS version that supports PPC is Leopard, released in 2007 and last updated in 2009.

I find it upsetting when someone insists on using a system that hasn't received any security update for 13 years. Connecting such a system to the Internet should be prohibited by law.

Apple effectively killed the PPC/macOS platform in 2009. We don't support dead platforms, and neither do GHC, Ruby, LLVM, nor most software project with a bit of common sense.

You're free to try to port newer OCaml versions to a dead platform, but support will not be reintegrated in OCaml, and there's no need to record your progress here.

@barracuda156
Copy link
Author

I find it upsetting when PPC Darwin is pro-actively removed while users exist (this happened with ghc, ruby and llvm too, for example):

The last macOS version that supports PPC is Leopard, released in 2007 and last updated in 2009.

I find it upsetting when someone insists on using a system that hasn't received any security update for 13 years. Connecting such a system to the Internet should be prohibited by law.

Apple effectively killed the PPC/macOS platform in 2009. We don't support dead platforms, and neither do GHC, Ruby, LLVM, nor most software project with a bit of common sense.

You're free to try to port newer OCaml versions to a dead platform, but support will not be reintegrated in OCaml, and there's no need to record your progress here.

@xavierleroy Well, I don’t really get why my question caused that much of a discomfort – I did not ask anything from you personally, but after all this is not my business.

For the record, your statement re PPC support is factually wrong: PPC code builds and fully works in 10.6.8 (Snow Leopard), and there are versions of 10.6 that can be used on PPC natively.

@barracuda156
Copy link
Author

For OCaml 4.14, my guess would be the same as yours, it's probably not too hard to restore support for another PPC variant. If there is no sign of new use-cases, it's probably not going to be integrated and maintained upstream, but indeed asking for help to prepare patches in downstream distributions makes perfect sense.

@gasche This is my concluding comment in this thread, I just wanted to thank you for encouragement and inform that I got it built for PPC: macports/macports-ports#14691 (probably it will still require some fixes here and there, but at least it builds now).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants