Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007562OCamlback end (clambda to assembly)public2017-06-22 18:212018-01-05 22:52
Assigned To 
Platformppc64leOSAlpine LinuxOS Version3.6.2
Product Version4.04.1 
Target VersionFixed in Version 
Summary0007562: Ocamlc got segfault in Alpine ppc64le
DescriptionI'm building ocaml in Alpine Linux ppc64le and it builds fine. But when I try to use ocamlc, I'm getting a segfault.

Gdb backtrace shows:

#0 0x00003fffb7fad710 in do_relocs (dso=0x3fffb7ff26a0 <app>, rel=0x200ab4b8, rel_size=2495088,
    stride=3) at ldso/dynlink.c:379
#1 0x00003fffb7fae1ec in reloc_all (p=0x3fffb7ff26a0 <app>) at ldso/dynlink.c:1195
#2 0x00003fffb7fafc94 in __dls3 (sp=<optimized out>) at ldso/dynlink.c:1638
0000003 0x00003fffb7faf3d4 in __dls2 (base=<optimized out>, sp=0x3ffffffffba0) at ldso/dynlink.c:1424
0000004 0x00003fffb7facd2c in _dlstart_c (sp=<optimized out>, dynv=<optimized out>)
    at ldso/dlstart.c:147
0000005 0x00003fffb7fb1104 in _dlstart () from /lib/

I know that ocaml was recently ported to ppc64le architecture and works fine with glic, but seems there is an issue with musl.
Steps To ReproduceThe steps bellow need to be done inside an Alpine ppc64le:

- Clone aports repository
  $ git clone [^]

- Build ocaml package
  $ cd aports/community/ocaml
  $ abuild -r

- Install the built package:
  $ sudo apk add <ocaml_apk>

- Run ocamlc to get the segmentation fault.
TagsNo tags attached.
Attached Files

- Relationships
related to 0007697confirmed static linking fails 

-  Notes
gasche (administrator)
2017-06-22 18:36

The OCaml version seems to be 4.04.1 ( [^] ) with some downstream patches ( [^] ), most of them being build-system related -- the only one affecting code generation marks the stack as non-executable and a ppc64 fix to CONTEXT_* macros in signal_osdeps.h [^] [^]

Since 4.04.0, "ocamlc" points to the native-compiled ocamlc.opt instead of the bytecode-compiled ocamlc.byte. Out of curiosity, does running ocamlc.byte (also installed in PATH) work correctly?
rgdoliveira (reporter)
2017-06-22 18:57

I just tried ocamlc.byte and I was able to compile a simple .ml file and run the generated file (no segfault).
xleroy (administrator)
2017-06-22 20:03

Thanks for trying ocamlc.byte. This confirms my suspicion that the problem is with dynamic loading in OCaml programs compiled to native code, which is the case of ocamlc in this Alpine setup.

The bad news is that we have extremely limited access to ppc64le hardware: just one virtual machine provided by RedHat in Brno, running Fedora (I think). So, I'm at a loss on how to debug this issue.
rgdoliveira (reporter)
2017-06-23 15:39


I have a VM running Alpine ppc64le and I can give you access to this VM, if that helps you with debug.

Can you talk with me at freenode? My username is 'rdutra'.
shinwell (developer)
2017-06-27 17:44

I can also try to look at this, I think I can get access to a suitable machine now. @xleroy please let me know if you have time / want to do it.
rgdoliveira (reporter)
2017-07-06 14:50

I applied a downstream patch (workaround) in Alpine build of ocaml and it fixed the segfault. Basically, I compiled the ocaml natives using -no-pie flag ( [^])
xleroy (administrator)
2017-09-30 18:28

@shinwell: I lost access to a ppc64le machine, so you are most welcome to try and understand this issue while I try to build a qemu-based VM. (virt-builder should make this easy, except that the version that comes with Ubuntu 16.04 LTS doesn't work.)

xleroy (administrator)
2017-09-30 18:30

That '-no-pie' helps suggests a misunderstanding between ocamlopt and the dynamic loader about register usage or what not. I'm afraid that even with -no-pie, later attempts to do dynamic loading would fail.
dbuenzli (reporter)
2018-01-05 14:33

FWIW this is not specific to ppc64le. The same occurs on alpine 'armv6' and is easy to reproduce in docker.

docker run -it arm32v6/alpine sh
apk add --update bash tar make m4 curl git gcc musl-dev
curl -OL [^]
./configure -host armv6l-linux-gnueabihf
make world.opt
make install

All the OCaml '.opt' executable segfault as does any executable produced by ocamlopt.byte except if '-cclib -no-pie' is provided on the cli in the final link step.

The configure makes it a bit difficult to target precisely the phase where you want to add flags (and using -cc 'gcc -no-pie' seems to break jbuilder which seems nowadays needed to bootstrap opam) so I went with a dirty:

sed -i s/common_cflags=\"-O2/common_cflags=\"-no-pie\ -O2/g configure

This adds `-no-pie` everywhere and I suspect that's not a very good thing. I have not tested dynlink as I was interested in building a statically linked executable. One additional problem with the latter is that it seems that the `-Wl,-E` that is added at link time prevents an added `-cclib -static` from doing its job (which I circumvented by doing an -output-obj and performing the final link step manually with 'gcc -no-pie -static').

Info about gcc and ld:

# gcc -v
Using built-in specs.
Target: armv6-alpine-linux-musleabihf
Configured with: /home/buildozer/aports/main/gcc/src/gcc-6.4.0/configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --build=armv6-alpine-linux-musleabihf --host=armv6-alpine-linux-musleabihf --target=armv6-alpine-linux-musleabihf --with-pkgversion='Alpine 6.4.0' --enable-checking=release --disable-fixed-point --disable-libstdcxx-pch --disable-multilib --disable-nls --disable-werror --disable-symvers --enable-__cxa_atexit --enable-default-pie --enable-cloog-backend --enable-languages=c,c++,objc,java,fortran,ada --with-arch=armv6zk --with-tune=arm1176jzf-s --with-fpu=vfp --with-float=hard --with-abi=aapcs-linux --disable-libquadmath --disable-libssp --disable-libmpx --disable-libmudflap --disable-libsanitizer --enable-shared --enable-threads --enable-tls --disable-libitm --with-system-zlib --with-linker-hash-style=gnu

# ld -v
GNU ld (GNU Binutils) 2.28
gasche (administrator)
2018-01-05 17:20

The `-cclib -static` part seems related to MPR#7697: [^]
dbuenzli (reporter)
2018-01-05 22:52

If that may help, exactly the same problem I mention (with identical resolution via `-no-pie`) occurs with:

docker run -it i386/alpine sh
apk add --update bash tar make m4 curl git gcc musl-dev
curl -OL [^]
./configure -host i386-linux
make world.opt
make install

This one should be more pleasant to diagnose with compilation-time wise.

Also note that this doesn't occur with the `amd64/alpine` and `aarch64/alpine` docker images, i.e. no '-no-pie' is needed in these, the compilers work out of the box (despite gcc still being compiled with '--enable-default-pie' in those).

Could this point to some kind of 32-bit issue (though the initial issue mentions ppc64le) ?

- Issue History
Date Modified Username Field Change
2017-06-22 18:21 rgdoliveira New Issue
2017-06-22 18:36 gasche Note Added: 0017941
2017-06-22 18:57 rgdoliveira Note Added: 0017942
2017-06-22 20:03 xleroy Note Added: 0017943
2017-06-22 20:03 xleroy Status new => acknowledged
2017-06-22 20:04 xleroy Category ~DO NOT USE (was: OCaml general) => back end (clambda to assembly)
2017-06-23 15:39 rgdoliveira Note Added: 0017962
2017-06-27 17:44 shinwell Note Added: 0018007
2017-07-06 14:50 rgdoliveira Note Added: 0018053
2017-09-30 18:28 xleroy Note Added: 0018426
2017-09-30 18:28 xleroy Target Version => 4.06.0 +dev/beta1/beta2/rc1
2017-09-30 18:30 xleroy Note Added: 0018427
2017-10-20 16:21 doligez Target Version 4.06.0 +dev/beta1/beta2/rc1 =>
2018-01-05 14:33 dbuenzli Note Added: 0018813
2018-01-05 17:20 gasche Note Added: 0018815
2018-01-05 17:20 gasche Relationship added related to 0007697
2018-01-05 22:52 dbuenzli Note Added: 0018816

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker