Fix segfaults when static linking with musl

[waj]

This is a workaround for segfaults that are showing up when raising exceptions in musl and the binary was statically linked.

The issue is with pthread_once. In musl is defined as a weak symbol:

$ nm /usr/lib/gcc/x86_64-alpine-linux-musl/9.2.0/libgcc.a
...
                 w pthread_once
...

The unwind API implementation uses this function, but through a wrapper __gthread_once: https://github.com/gcc-mirror/gcc/blob/8d9254fc8aa32619f640efb01cfe87cc6cdc9ce1/libgcc/unwind-dw2.c#L1597-L1600

But the implementation of __gthread_once refers to the weak version of the function:
https://github.com/gcc-mirror/gcc/blob/8d9254fc8aa32619f640efb01cfe87cc6cdc9ce1/libgcc/gthr-posix.h#L696-L703

For some reason I don't fully understand yet, that makes the linker to not include that function in the final binary.

Note also that __gthread_once checks __gthread_active_p to see if the current code is multithreaded or not. It's a hack that looks for other existing symbols within the same binary. That's why when linking with the GC it failed but it doesn't when compiling with -Dgc_none: the GC uses multithreaded code and thus links to pthread_create and other symbols.

Thank you very much to @ggiraldez for help with this debugging!!!

NOTE: the backtraces still cannot be decoded with static linking, but that's a different issue

Fixes: #4276, #6934

[RX14]

Wow, that's amazing debugging, thank you!!

[bcardiff]

I smoke tested the build process and shards binary without the hack on 64/32 and everything seems to work fine.

[j8r]

Should we now create a new issue to track the empty strack traces problem for static linking against musl?

[waj]

@j8r sure, I'll do it. It's a totally unrelated issue. I've been doing some research and I have a possible solution already.

[j8r]

That's a really great work @waj , thanks a lot.

I didn't see Crystal reaching 1.0 without this essential issues solved, static linking is a very good selling point for the language: easy application distribution.
Go has it too, but it is not as easy to link statically. Last time, I had to set LDFLAGS='-extldflags "-static -fuse-ld=bfd"' (?!).

[rdp]

Should this also be reported upstream somewhere? Just wondering...

[waj]

@j8r well... I didn't open the issue, but just sent a PR instead: #9267 😉

[waj]

@rdp I'm not sure where the bug actually is. Anyway, I have a really small example in plain C to reproduce the issue, so I might send it to Alpine.