Thanks! It appears initial-exec TLS resolves to dynamic definition can be worked around by disabling HAS_DYNAMICLOAD (which avoids using dlopen):

mkdir -p build && cd build
cmake -DHAS_DYNAMICLOAD=OFF .. && make -s

However, we then encounter another crash during startup:

Thread 2 "nchat" received signal SIGSEGV, Segmentation fault.
[Switching to LWP 9226]
0x0000fffff67db708 in runtime.argv_index (argv=0x80000001, i=-159307743) at /usr/lib/go/src/runtime/runtime1.go:63
63              return *(**byte)(add(unsafe.Pointer(argv), uintptr(i)*goarch.PtrSize))
(gdb) bt
#0  0x0000fffff67db708 in runtime.argv_index (argv=0x80000001, i=-159307743) at /usr/lib/go/src/runtime/runtime1.go:63
#1  runtime.sysargs (argc=-159307744, argv=0x80000001) at /usr/lib/go/src/runtime/os_linux.go:236
#2  0x0000fffff67eff5c in runtime.args (c=-159307744, v=0x80000001) at /usr/lib/go/src/runtime/runtime1.go:69
#3  0x0000fffff6813b68 in runtime.args (c=-159307744, v=0x80000001) at <autogenerated>:1
#4  0x0000fffff680f4dc in runtime.rt0_go () at /usr/lib/go/src/runtime/asm_arm64.s:84

This is due to an incompatibility between Go and musl w.r.t. c-shared library usage (which nchat uses to link Go library whatsmeow for WhatsApp support).

The linked issue has been open since 2015, so it appears that neither the Go nor the Musl projects are very interested in fixing it. Based on this I'll probably need to consider musl support out-of-scope for nchat's whatsapp feature.

I'll leave this issue open for a while and see if I can add some musl detection to provide a more user-friendly error message.

Unexpected termination 11 on Alpine #204

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions