On Wed, Nov 13, 2019 at 7:50 AM Ross Burton <ross.bur...@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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core