OCaml 4.13.1 fails to compile on Alpine / RISC-V

[kit-ty-kate]

OCaml 4.13.1 segfaults during the compilation process on Alpine/riscv64

../../ocamlc.opt -g -nostdlib -I ../../stdlib -c -for-pack Dynlink_compilerlibs -strict-sequence -principal -absname -w +a-4-9-40-41-42-44-45-48-66-70 -warn-error +A -bin-annot -safe-string -strict-formats -I byte \
          -I dynlink_compilerlibs -o dynlink_compilerlibs/binutils.cmo dynlink_compilerlibs/binutils.ml
[..]
make[4]: *** [Makefile:181: dynlink_compilerlibs/binutils.cmo] Segmentation fault
make[4]: *** Waiting for unfinished jobs....

See https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/30066 for details.

From what I can see they only do the equivalent of:

./configure CC=gcc AS="gcc -c" ASPP="gcc -c"
make world.opt

and have the following patch:

--- a/configure	2021-02-24 13:49:29.000000000 +0000
+++ b/configure	2021-09-25 17:08:37.549751090 +0000
@@ -14487,17 +14487,23 @@ fi
 # e.g. Ubuntu >= 17.10 for i386, which uses the glibc dynamic loader.

 case $arch in #(
-  amd64|s390x|none) :
+  amd64|aarch64|s390x|none) :
     # ocamlopt generates PIC code or doesn't generate code at all
-     ;; #(
+    ;; #(
   *) :
     case $host in #(
-  # expected to match "*-linux-musl" as well as "*-linux-musleabi*"
-    *-linux-musl*) :
-    # Alpine and other musl-based Linux distributions
-       common_cflags="-no-pie $common_cflags" ;; #(
-  *) :
-     ;;
+      i?86-*-linux-musl*) :
+        # Alpine and other musl-based Linux distributions, 32bit x86,
+        # disable DT_TEXTREL, see https://github.com/ocaml/ocaml/issues/9800
+        common_cflags="-Wl,-z,notext -no-pie $common_cflags"
+        mksharedlib="$mksharedlib -Wl,-z,notext"
+        mkmaindll="$mkmaindll -Wl,-z,notext";; #(
+      # expected to match "*-linux-musl" as well as "*-linux-musleabi*"
+      *-linux-musl*) :
+        # Alpine and other musl-based Linux distributions
+        common_cflags="-no-pie $common_cflags" ;; #(
+      *) :
+      ;;
 esac ;;
 esac

[ghost]

if you can think of things to try feel free to ping me- i can run builds on the riscv64 container with the same environment

[nojb]

Did this work with 4.12? 4.11?

[nojb]

Also, unless I'm misremembering ocamlopt always produces PIC code on riscv64 so it should probably be added to

-  amd64|s390x|none) :
+  amd64|aarch64|s390x|none) :

[ghost]

riscv64 has never been enabled to my knowledge- was disabled due to the same error before as well.
sure, i can add the arch to that list and see what changes

[nojb]

riscv64 has never been enabled to my knowledge- was disabled due to the same error before as well. sure, i can add the arch to that list and see what changes

Note that you should add riscv to that list, as that is the official name of the architecture in the configure script.

[ghost]

adding this small change to the above patch:

-  amd64|s390x|none) : 
+  amd64|aarch64|s390x|riscv|none) : 

still fails with the same error. full log: https://img.ayaya.dev/L1GLq9p7NY1r (uploaded due to character limit)
edit: same for 4.14.0~alpha1

[ghost]

if it matters, these builds are inside a qemu-user-riscv64 environment (running latest alpine linux edge, with the above patch, and the build outlined in the APKBUILD), emulated from a x86_64 host. not sure how this would go on actual hardware, but, well, that doesn't exactly exist aside from a few meek boards

[glondu]

Note that ocaml 4.13.1 builds, and tests pass, on Debian/riscv64: https://buildd.debian.org/status/fetch.php?pkg=ocaml&arch=riscv64&ver=4.13.1-3&stamp=1642607971&raw=0

[xavierleroy]

OCaml 4 for RISC-V / Fedora is part of our CI and works fine. There's something specific to Alpine here, probably the use of Musl instead of Glibc. And, as @nojb wrote, OCaml on RISC-V supports PIC from the beginning, so it's not the same issue we had with i386, which doesn't.

[alexfanqi]

I think the segment fault with musl is related to relocation in frametable and the textrel issue in #10688

[nojb]

This was probably fixed by #11042. Feel free to reopen if this is not the case.

[ghost]

the mere patch doesn't, but building latest master works, so i consider this resolved :)

[kit-ty-kate]

the mere patch doesn't, but building latest master works, so i consider this resolved :)

did you try the trunk or 4.14 branch? The former does not compile the native compiler, only bytecode, so it would be normal if the failure isn’t triggered there. (5.0 only supports x86_64 and arm64 at the moment due to the addition of the multicore runtime)

However if you tried the 4.14 branch then it is indeed resolved. If it’s not the case, could someone reopen it?

[ghost]

did you try the trunk or 4.14 branch? The former does not compile the native compiler, only bytecode

ah, that would make sense- i saw the native parts being disabled in the log, as i used the trunk branch.

building latest 4.14 (which has that commit in it already as well) seems to work too (no more segfaults), though the linking process takes forever (never ends)- but i will assume that is the usual emulated-riscv issue, and will only consider it an actual issue if i can one day reproduce it on some hardware :) works for everyone else it seems