[OE-core] pthreads should rdepend on libgcc

[Bartosz Golaszewski]

śr., 13 lis 2019 o 23:37 Khem Raj <raj.khem at gmail.com> napisał(a):
>
> 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

So can I submit such a patch then?

Bart

> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core