Alex Rønne Petersen

> We discussed this in the meeting today and decided that we'll start by changing all `=> unreachable` to `=> return error.Unexpected` in `std.posix` and `std.os`. Just noting that I'm...

Some context if anyone's interested: `.ctors`/`.dtors` are so archaic that even the "new" `.init_array`/`.fini_array` are over two decades old. Defaulting this to `true` is very sensible. GCC still has a...

> Why should we give .jar special treatment in this regard? I have to imagine FFmpeg is not the only case where you might find native libraries in a `.jar`....

The fundamental problem here is that `__tls_get_addr` is expected to be present for PIC (which itself is required when dynamically linking). It is normally provided by libc, but obviously, if...

Upon further thought, I've decided that this is expected behavior. `__tls_get_addr` is normally provided by the dynamic linker and its implementation is tightly coupled to the dynamic linker's TLS implementation....

``` system: library: libpthread.so versions: 2.2.5 targets: x86_64-linux-gnu system: library: libc.so versions: 2.2.5 targets: x86_64-linux-gnu ``` The libpthread symbol is being picked by the linker because it happens to come...

The problem here is going to be the fact that we are no longer interested in maintaining a POSIX compatibility layer in the standard library - see #6600. This has...

> Hmm, I can see the argument is for not making up a POSIX layer on target that don't have one. But given that WASI doesn't try to be POSIX...

I think this makes the function too lax. If you really want to tackle those weird suffixes I mentioned in #23545, then what we should do is match `.so.X`, `.so.X.Y`,...

We are likely going to just delete the unfinished and unmaintained backends (arm, aarch64, sparc64) as they will require a full rewrite anyway.