[OE-core] pthreads should rdepend on libgcc

[Khem Raj]

On Wed, Nov 13, 2019 at 7:50 AM Ross Burton <ross.burton at intel.com> wrote:
>
> On 13/11/2019 15:04, Mark Hatle wrote:
> >> This is because the implementation of __pthread_exit() in glibc calls
> >> pthread_cancel() which leads to pthread_cancel_init() being called in
> >> which said shared object is being loaded with dlopen(). When this
> >> fails, the program aborts with the following error message:
> >>
> >>      libgcc_s.so.1 must be installed for pthread_cancel to work
> >>      Aborted
> >
> > Fix for this would be to declare a runtime-dependency on libgcc_s.so.1 in the
> > glibc libpthread package.
>
> On my todo list for a long time has been:
>
> 1) a QA test to find binaries that link to pthread_cancel but don't
> depend on libgcc_s
> 2) Automatically finding use of pthread_cancel and adding the RDEPENDS
> automatically.
>
> (2) is definitely the best long term solution, but as Mark says: the now
> fix is to add libgcc to RDEPENDS.  There's plenty of prior art in oe-core:
>
> $ git grep -h RDEPENDS.*libgcc
> RDEPENDS_${PN}-ptest += "make ${@bb.utils.contains('PACKAGECONFIG',
> 'python', 'libgcc python3-core python3-logging python3-shell
> python3-stringold python3-threading python3-unittest ${PN}-python', '', d)}"
> RDEPENDS_${PN} = "libgcc"
> RDEPENDS_${PN}-ptest = "${PN}-modules ${PN}-tests unzip bzip2 libgcc
> tzdata-europe coreutils sed"
> RDEPENDS_${PN}-ptest += "libgcc"
> RDEPENDS_${PN} = "libgcc"
> RDEPENDS_${PN}-ptest += "libgcc"
> RDEPENDS_${PN}-ptest += "libgcc"
>

There are two issues here, one is where dependency is missing which
this solution will address
however, there could be another problem, where libgcc_s is lazily
loaded during pthread_exit and
application is not using root user which many daemons do where they
use less privileged user to run
and it would fail in the exact same manner. I also see few other uses
of libgcc_s.so being dlopened in
nptl unwind code and libbacktrace in glibc. so even if you were to do
one of above you won't solve the
problem. in fact the part this will solve can simply be solved by
adding libgcc_s as rdep for libc6
and then if we still get failures of such kind then we know its the
second problem since we would have
taken care of the first issue with rdep. Its fine if we want to be
surgical, but it might be over-optimization