śr., 13 lis 2019 o 23:37 Khem Raj <[email protected]> napisał(a): > > On Wed, Nov 13, 2019 at 7:50 AM Ross Burton <[email protected]> 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 > [email protected] > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
