Re: libgcc_s.so.1 must be installed for pthread_cancel to work

["Carlos O'Donell" <carlos at systemhalted dot org>]

On Sat, Jun 28, 2014 at 4:49 AM, Waldemar Brodkorb <wbx@openadk.org> wrote:
> Is there a way to avoid libgcc_s.so.1 when using GNU libc?

There is no way to avoid libgcc_s.so.1.

> Is there a technical reason why the needed code can not be linked
> statically from libgcc_eh.a or a libgcc.a (with contains libgcc_eh.a
> functions, in the case of a gcc build with static libgcc)?

Yes, because it would likely prevent you from ever using dlopen, and
because all of NSS uses dlopen you would need a static NSS also to
avoid needing a newer hybrid mix of multiple unwinders for different
sections of code.

Granted it's all possible it's just software, but the present
infrastructure allows:

* One and only one unwinder.
* Loaded dynamically.

Anything else requires you to work with the glibc upstream to help
develop something more.

> There are other C libraries, which do not use any unwinding code
> from libgcc_eh.a to implement pthread_cancel.

Please feel free to post your own suggestions to libc-alpha.

> BTW: Is static linking with GNU libc supported or discouraged?

It is supported, but discouraged because it has security implications
among other things.

> I know there would be still the issue with NSS (but there is a FAQ
> entry on your site, which explains a solution for that), but is static
> linking a supported method or should I avoid it with GNU libc?

It is supported. Any issues with static linking are valid bugs.

> Thanks in advance for clarifying any of my misunderstandings,

I don't think you have misunderstood anything, the feature you want
just doesn't exist today.

Interested parties need to come forward and work on it, discuss it,
and convince other members of upstream that it's a good idea.

Cheers,
Carlos.