Date: Sat, 31 Aug 2019 11:52:36 +0000 From: bugzilla-noreply@freebsd.org To: threads@FreeBSD.org Subject: [Bug 150959] [libc] Stub pthread_once in libc should call _libc_once Message-ID: <bug-150959-13406-pKBxbZEr5B@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-150959-13406@https.bugs.freebsd.org/bugzilla/> References: <bug-150959-13406@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D150959 andrew@tao11.riddles.org.uk changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrew@tao11.riddles.org.uk --- Comment #5 from andrew@tao11.riddles.org.uk --- The current stub implementation of pthread_once now fails with an error ret= urn, which does not seem much of an improvement. In particular, it causes code that is static-linked with openssl to segfault unless libthr is linked into the process (the fact that openssl has inadequ= ate error checks is a separate issue). I've been told in another bug thread that the only reason to have pthread s= tubs at all is to allow for libraries that might be dynamically loaded into eith= er a threaded or unthreaded process. It seems to me that such libraries would be very likely to want to use pthread_once, and very unlikely to be able to co= pe with it failing (it has no normal reason to fail). Accordingly, libc should provide either a pthread_once stub that actually w= orks (interoperably with the real implementation in case libthr gets pulled in later), or it should not provide the symbol at all, forcing libraries that = want to use it to pull in libthr themselves. see also https://twitter.com/RhodiumToad/status/1165523338481061888 --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-150959-13406-pKBxbZEr5B>