libc.so.6 dependencies

[Alex Ernst]

Hello Adhemerval and Florian,

Thank you very much for these clarifications. Very sad to hear all of this.

Probably, a workaround would be to define app's own pthread_cancel()
function:

#include <pthread.h>
#include <signal.h>
int pthread_cancel(pthread_t thread)
{
   return pthread_kill(thread,SIGTERM);
}

I do not know, it might have some side effects. And it looks like (in sake
of consistency) glibc should process pthread_kill() similarly to
pthread_cancel() :)

libgcc_s.so.1 must be installed for unwinding to work
libgcc_s.so.1 must be installed for pthread_cancel to work
*libgcc_s.so.1 must be installed for pthread_kill to work !!!*
libgcc_s.so.1 must be installed for pthread_exit to work

Thx,
Alex

On Tue, Jun 24, 2025 at 11:12 PM Adhemerval Zanella Netto <
adhemerval.zanella@linaro.org> wrote:

>
> On 24/06/25 17:56, Alex Ernst wrote:
> > Hello Florian,
> >
> > Thank you for your email.
> >
> > Looks very inconsistent: pthread_create(), pthread_kill() and all other
> pthread functions are in libc/libpthread. These dependencies are shown by
> ldd. But only pthread_cancel() and pthread_exit() dependencies are somehow
> "hardcoded", are not shown by ldd and suddenly at runtime an application
> needs to call the standard POSIX function pthread_cancel() and is getting
> hardcoded message "libgcc_s.so.1 must be installed for pthread_cancel to
> work". It is not fair. :(
> > Has POSIX something to do with gcc library that might be not installed
> at all. I had a problem moving my binaries from a build machine to another
> machine. After some hours of work, an application called  pthread_cancel()
> and I got this nice message. Very strange. My understanding is it should
> not be designed like this. Why do we need libgcc_s.so.1 if pthread_cancel()
> should be in libc/libpthread.so ? :(
>
> This is because how pthread_exit/pthread_cancel was initially designed to
> work
> with C++ exceptions handling.  It is a GNU extension, since POSIX does not
> specify how it should work along C++, and the idea is
> pthread_cancel/pthread_exit
> will also execute any registered eh_frame_hdr functions (for instance C++
> destructors and/or pthread_cleanup_push).
>
> And it is not shown in ldd because the libgcc_s.so is not listed in
> DT_NEEDED,
> it is loaded dynamically as per dlopen.
>
> Besides the deployment issue you noticed, there is other issues about this
> approach where on highly multithread system trying to use
> pthread_exit/pthread_cancel
> might exhaust the allowed process VMA [1].
>
> The libpthread.so now is just a shim library, one option might to just
> call exit
> if the process is single-thread as previously. For a more general case, I
> recall
> to discuss the option to load libgcc_s.so at *loading* time if
> pthread_exit/pthread_cancel
> needs binding; so at least user knows that the library might be eventually
> used
> (and this would be a bit more robust, since pthread_exit/pthread_cancel
> would
> not require additional internal dlopen calls).
>
> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=13119
>
>
> >
> > Thx,
> > Alex
> >
> > On Tue, Jun 24, 2025 at 10:45 PM Florian Weimer <fweimer@redhat.com
> <mailto:fweimer@redhat.com>> wrote:
> >
> >     * Adhemerval Zanella Netto:
> >
> >     > On 24/06/25 14:45, Alex Ernst wrote:
> >     >> Hello glibc developers,
> >     >>
> >     >> Why do we have dependency on libgcc_s.so.1 for pthread_cance()
> and pthread_exit() (compared to older versions of glibc) ?
> >     >>
> >     >> GLIBC 2.28: strings libc.so.6 | grep "must be installed for"
> >     >> libgcc_s.so.1 must be installed for unwinding to work
> >     >>
> >     >> GLIBC 2.41: strings libc.so.6 | grep "must be installed for"
> >     >> libgcc_s.so.1 must be installed for unwinding to work
> >     >> libgcc_s.so.1 must be installed for pthread_cancel to work
> >     >> libgcc_s.so.1 must be installed for pthread_exit to work
> >     >>
> >     >
> >     > The dependency always existed, the 1d95b035c72 (glibc 2.33) moved
> >     > __pthread_unwind_next into libc and the refactor added more
> meaningful
> >     > error messages depending of which symbol triggered the dlopen
> failure.
> >
> >     We had a pthread_exit function in libc that just called exit, without
> >     invoking the cleanup handlers.  The cleanup handlers were only
> called if
> >     libpthread was loaded as well, and that triggered loading of
> >     libgcc_s.so.1.
> >
> >     Thanks,
> >     Florian
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20250625/2aa092ee/attachment.htm>