Re: [dev] Xorg implementations

From: <>
Date: Mon, 3 Jul 2017 16:10:00 +0000

On Mon, Jul 03, 2017 at 05:33:14PM +0200, hiro wrote:
> I should, so there isn't any? I have alpine here ready and waiting...

Indeed, alpine is musl based (thx to the authors for all the patching, hope
upstream they were not *ss h*les and committed the patches).

For sane C code (or at least have a chance to be sane). The idea is to check if
alpine version of gcc C has no libgcc_s. Namely, C binaries and C shared libs
do not depend on libgcc_s, or compilation of a reasonably sized C binary or C
shared lib does not generate a dep on libgcc_s.

For insane c++ code (it will never be sane, ever), if I recall properly, that
pile of degenerated cr*p which is llvm uses c++ threading for gpu shader
compilation, hence mesa. If alpine has llvm shared libs and not llvm static
libs, the deps of those will have the shared libstdc++ as a dep. If alpine went
the static libstdc++ way, then we would look at libGL*. Namely, if there is a
dep on libgcc_s, it would mean that very probably, gcc libstdc++, even static,
needs a shared libgcc like the glibc.

For a static userland distro, a good thing would be to have only the ELF
dynamic loader and only the shared libs for the closed source binaries (...
dota2 and steam... coze I'm a gamer... nobody is perfect :) ).

For the record, I did ask the glibc maintainers about this sh*tty libgcc_s dep
of pthread_cancel: got a polite "f*ck y*u" (you can check their mailing list
archive, and if I recall properly, was not the only one in the world to ask).
Received on Mon Jul 03 2017 - 18:10:00 CEST

This archive was generated by hypermail 2.3.0 : Mon Jul 03 2017 - 18:12:25 CEST