How to make signal-rs run on a musl-based system?

I want to use signal-rs on my PinePhone. The Pinephone is an ARM-based linux smartphone, which in my case runs the Linux distribution PostmarketOS. This Distribution is based on Alpine Linux, which uses musl as its Implementation of the C standard Libary.

I installed the gcompat glibc compatibily layer, which resolved the Issues i had when compiling and linking signal-rs. Now I can build signal-rs using the command: rustup run nightly cargo build --release. However, when I do that and try to run the program (./target/release/signal-rs), It immediately exits with the following error message:

fatal runtime error: assertion failed: thread_info.is_none()
Aborted

The exit code of the Program is 134.

I have no idea on how to solve this, so I'm grateful for every info you provide me.

Well, the first step to debug this would be to compile the signal-rs in debug mode to discover where this assertion failure occurs. (A simple grep through the source of signal-rs shows that this code doesn't occur anywhere in it, so it must be in a dependency).
Also, it might help to ask in a signal-rs specific forum or buglist.

1 Like

I would be inclined to imagine it is the assertion here in the std library, thread_info.rs#L44

1 Like

I already tried compiling it in debug mode, which got the same result. Even if I run it with RUST_BACKTRACE=1, i get no additional output.

Yes, that means what @ratmice told is what is happening - the assert fails in the std library, which is pre-compiled in release mode and so compiling your project in debug mode won't help.
Now, I don't know how gcompat works or why is it necessary - aarch64-unknown-linux-musl is a tier 2 with host tools platform, so things should for most parts compile normally.
Also, given that the assertion failure is in a threading module, which complains that thread_info is not available - I would think this has to do with the underlying pthread library, which is a part of libc.
If I had to take a shot, I would think that gcompat is causing problems, although I may be wrong.
Also, why doesn't your code compile without gcompat?

Not that it's not available, but that it's overridden after being set.

2 Likes

I don't exactly know the internals of gcompat either, but I'm pretty sure it's not the cause for the Issue. I tried compiling it without gcompat in the past and had Issues because /lib/ld-linux-aarch64.so.1 was set as the Interpreter, which wasn't present on my system (only /lib/ld-musl-aarch64.so.1 was). In the end I got it working with some CFLAGS setting. After I solved that issue, I ran into the same problem. I then found out about gcompat in the alpine wiki article about glibc programs and installed with hoping that it would fix the Issue, which it didn't. The only thing where I'm noticing gcompat is that it installed /lib/ld-linux-aarch64.so.1, so I no longer have to take care of setting the Interpreter.

Why not set the target triple to aarch64-unknown-linux-musl?

I did that, but it still got the interpreter wrong.

And what about linking /lib/ld-musl-aarch64.so.1 to /lib/ld-linux-aarch64.so.1?

I haven't tried that, but I'm pretty sure thats not the solution of the Issue, since I also got this issue when I set the correct Interpreter via some CFLAGS setting.

I'll try once again uninstalling gcompat and building signal-rs with setting the interpreter manually. It'll take a while since I'm compiling on the Pinephone.

Ok, I uninstalled gcompat and recompiled signal-rs with

RUSTFLAGS="-Clink-arg=-Wl,--dynamic-linker=/lib/ld-musl-aarch64.so.1" QMAKE=qmake-qt5 CC=aarch-64-alpine-linux-musl-gcc rustup run nightly cargo build

When I now run the Program, I get the following output:

thread '<unnamed>' panicked at 'cannot access a Thread Local Storage value during or after destruction: AccessError', library/std/src/thread/local.rs:418:26
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
fatal runtime error: initialization or cleanup bug
Aborted

thread '<unnamed>' panicked at 'cannot access a Thread Local Storage value during or after destruction: AccessError', library/std/src/thread/local.rs:418:26

When I rerun the program with RUST_BACKTRACE=1, the output is:

thread '<unnamed>' panicked at 'cannot access a Thread Local Storage value during or after destruction: AccessError', library/std/src/thread/local.rs:418:26
stack backtrace:
   0: rust_begin_unwind
             at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/core/src/panicking.rs:143:14
   2: core::result::unwrap_failed
             at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/core/src/result.rs:1784:5
   3: core::result::Result<T,E>::expect
             at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/core/src/result.rs:1034:23
   4: std::thread::local::LocalKey<T>::with
             at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/std/src/thread/local.rs:418:9
   5: std::sys_common::thread_info::set
             at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/std/src/sys_common/thread_info.rs:42:5
   6: std::rt::init
             at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/std/src/rt.rs:86:9
   7: std::rt::lang_start_internal::{{closure}}
             at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/std/src/rt.rs:127:42
   8: std::panicking::try::do_call
             at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/std/src/panicking.rs:492:40
   9: std::panicking::try
             at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/std/src/panicking.rs:456:19
  10: std::panic::catch_unwind
             at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/std/src/panic.rs:137:14
  11: std::rt::lang_start_internal
             at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/std/src/rt.rs:127:5
  12: std::rt::lang_start
             at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/std/src/rt.rs:144:17
  13: main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
fatal runtime error: initialization or cleanup bug
Aborted

And with RUST_BACKTRACE=full:

thread '<unnamed>' panicked at 'cannot access a Thread Local Storage value during or after destruction: AccessError', library/std/src/thread/local.rs:418:26
stack backtrace:
   0:          0x1886d10 - std::backtrace_rs::backtrace::libunwind::trace::hfb44dba5a570d756
                               at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
   1:          0x1886d10 - std::backtrace_rs::backtrace::trace_unsynchronized::hf5fdaf77f53017e8
                               at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:          0x1886d10 - std::sys_common::backtrace::_print_fmt::h39c6fe6cad5710c4
                               at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/std/src/sys_common/backtrace.rs:66:5
   3:          0x1886d10 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h341d332187045a1d
                               at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/std/src/sys_common/backtrace.rs:45:22
   4:          0x18d4c6c - core::fmt::write::hc0aa1684f79ce1c8
                               at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/core/src/fmt/mod.rs:1190:17
   5:          0x1880780 - std::io::Write::write_fmt::h1d4bfbccf9196070
                               at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/std/src/io/mod.rs:1655:15
   6:          0x18886b8 - std::sys_common::backtrace::_print::he1ee8b09017a4d50
                               at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/std/src/sys_common/backtrace.rs:48:5
   7:          0x18886b8 - std::sys_common::backtrace::print::he1884dea0d8fbb61
                               at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/std/src/sys_common/backtrace.rs:35:9
   8:          0x18886b8 - std::panicking::default_hook::{{closure}}::h6daa685758af853a
                               at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/std/src/panicking.rs:295:22
   9:          0x1888370 - std::panicking::default_hook::hde54521b166be63c
                               at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/std/src/panicking.rs:314:9
  10:          0x1888bc8 - std::panicking::rust_panic_with_hook::hab03b2faee81fdca
                               at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/std/src/panicking.rs:698:17
  11:          0x1888aa0 - std::panicking::begin_panic_handler::{{closure}}::hb7bed67b83734246
                               at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/std/src/panicking.rs:588:13
  12:          0x18871c8 - std::sys_common::backtrace::__rust_end_short_backtrace::h40c12eada74e2070
                               at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/std/src/sys_common/backtrace.rs:138:18
  13:          0x18887ec - rust_begin_unwind
                               at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/std/src/panicking.rs:584:5
  14:           0x40d310 - core::panicking::panic_fmt::h62632ae7d5360e3a
                               at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/core/src/panicking.rs:143:14
  15:           0x40d3b4 - core::result::unwrap_failed::h3f0f982107fabe3e
                               at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/core/src/result.rs:1784:5
  16:          0x1887a48 - core::result::Result<T,E>::expect::h4ea353859beeb90b
                               at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/core/src/result.rs:1034:23
  17:          0x1887a48 - std::thread::local::LocalKey<T>::with::hab1524d3f34f8150
                               at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/std/src/thread/local.rs:418:9
  18:          0x1887a48 - std::sys_common::thread_info::set::habcafb24f3500c2a
                               at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/std/src/sys_common/thread_info.rs:42:5
  19:          0x1886680 - std::rt::init::heb921cb1adfaa4f8
                               at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/std/src/rt.rs:86:9
  20:          0x1886680 - std::rt::lang_start_internal::{{closure}}::h31fbee8acfa37b9e
                               at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/std/src/rt.rs:127:42
  21:          0x1886680 - std::panicking::try::do_call::h28c39daaa0ef35d6
                               at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/std/src/panicking.rs:492:40
  22:          0x1886680 - std::panicking::try::hf19dca8d58578ef2
                               at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/std/src/panicking.rs:456:19
  23:          0x1886680 - std::panic::catch_unwind::ha878c9429c9132ed
                               at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/std/src/panic.rs:137:14
  24:          0x1886680 - std::rt::lang_start_internal::h6dbf045aa19afa89
                               at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/std/src/rt.rs:127:5
  25:           0x5a363c - std::rt::lang_start::hb059d6bd99151626
                               at /rustc/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/std/src/rt.rs:144:17
  26:           0x6e2a08 - main
fatal runtime error: initialization or cleanup bug
Aborted

I apologize for falsly stating the error was the exact same, I got it wrong in my memory.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.