Date: Tue, 24 Nov 2020 04:57:31 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 251112] Compiling C++ with asan fails by default because libclang_rt.asan-x86_64.so uses symbol pthread_attr_get_np but doesn't link to libpthread.so Message-ID: <bug-251112-227-x6XPRUOAtJ@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-251112-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251112 --- Comment #9 from Andrew Stitcher <astitcher@apache.org> --- (In reply to Konstantin Belousov from comment #8) I think I understand the libpthread/libc interaction a bit better now: It seems that the only way to get pthread_create() is to actually link libpthread. So any executable that actually has multiple threads will necessarily have libpthread linked in. This is what I was missing before when you were talking about pthread stubs - that is no stub for pthread_create() in libc. It looks like there are stubs (weak symbols) in libc for the other relevant pthread symbols used in libclang_rt.asan (even the ones that are documented to require linking with -lpthread) so I think it would make sense to have a stub for pthread_attr_get_np() which returns the ESRCH error (this is the documented return if it cannot find the thread id which I think is necessarily the case if there are no threads!). In the case of libclang_rt.asan I think if it did get called somehow - which looks to be impossible - the return value is checked and should abort the run. -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-251112-227-x6XPRUOAtJ>