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
