fix support for OpenBSD/macppc (32-bit powerpc) #6049
Original bug ID: 6049
This patch adds support in 4.1 for OpenBSD/macppc (running on a Powerbook G4). With the patch, OPAM compiles to native code and is churning out package builds. The system is ELF and BSD, so I had to add a bsd_elf SYSTEM variant to select the right combination of native code features. Let me know if you'd prefer a different scheme here.
It would be great to get this into 4.1 so that we can package it on OpenBSD without local patches, but it's not a big deal if it's too late in the release cycle.
Raw patch available at: https://github.com/avsm/ocaml/commit/c2a8e549f6376c42ddccfff4f7262c0725402ca0.patch
asmcomp/power/emit.mlp | 21 ++++++++++++---------
diff --git a/asmcomp/power/emit.mlp b/asmcomp/power/emit.mlp
let emit_symbol =
@@ -64,7 +64,7 @@ let emit_symbol =
let label_prefix =
@@ -78,19 +78,19 @@ let emit_data_label lbl =
let data_space =
let code_space =
let rodata_space =
@@ -158,7 +158,7 @@ let is_native_immediate n =
let emit_upper emit_fun arg =
let emit_lower emit_fun arg =
let declare_global_data s =
let emit_item = function
let extcall_use_push = false
diff --git a/asmrun/signals_osdep.h b/asmrun/signals_osdep.h
/****************** PowerPC, BSD */
-#elif defined(TARGET_power) && defined(SYS_bsd)
The text was updated successfully, but these errors were encountered:
Comment author: @avsm
You're right. That was actually only necessary in order to avoid a special rule for power-bsd_elf, but it turns out rule was needed anyway.
I'm just compiling the simpler patch and will update this issue with a patch when it's tested (I can't see any way to re-open this issue, however).
Moreover, PowerPC 32 bits is dying, just like the old Macs that were able to run it. POWER8 64-bits seems to be the last healthy variant of this architecture.
So, with all due respect to dead architectures, I will close this issue.
Xavier Leroy (2019/03/17 09:45 -0700):
I'm afraid support for PowerPC under non-Linux platforms was removed in 2015 as part of commit 8815d7e, even though traces remain in `configure.ac` (to be discussed with @shindere).
Oops, many thanks for your attention. PR#8536 has just been opened to finish the cleanup.