On Sat, Oct 17, 2020, at 6:29 PM, David Topham wrote: > I noticed same error seemed to have occurred from user installing to > gentoo Linux. I can't tell from this if it was resolved or not (I'm > relatively inexperienced) > > https://bugs.gentoo.org/713178 > > One thing in common between Alpine and this environment is they are > using musl libc > > Could that be an issue?
I built polyml HEAD in an alpine chroot and reproduced the crash. e6081b5540fb:~/polyml$ readelf -d .libs/lt-poly | grep TEXTREL 0x0000000000000016 (TEXTREL) 0x0 TEXTREL is not supported by musl, so this is the problem. This indicates that position-dependent code has somehow gotten into an executable marked as PIE. If I configure poly/ml using: ./configure LDFLAGS="-no-pie" it works. Nothing is installed here except musl-dev gcc g++ make git curl; it is a fresh git checkout, rev d68c673. Looking at polyexport.o (with objdump -d -r) there are a large number of X86_64_RELATIVE relocations in area%1u symbols, mixed with data that visually looks like x86_64 machine code. The relocations apply to aligned 64-bit blocks, not 64-bit immediates in move instructions. Not sure if this is easily fixable or if poly does something like old GHC that relies on mixing data and code so closely. -s _______________________________________________ polyml mailing list polyml@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml