From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6364 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: gthread_once Date: Sat, 18 Oct 2014 20:14:30 +0200 Message-ID: <20141018181430.GC16659@port70.net> References: <20141018101813.GB16659@port70.net> <20141018154518.GE32028@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1413656088 12782 80.91.229.3 (18 Oct 2014 18:14:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 18 Oct 2014 18:14:48 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6377-gllmg-musl=m.gmane.org@lists.openwall.com Sat Oct 18 20:14:43 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XfYWZ-0003qr-5v for gllmg-musl@plane.gmane.org; Sat, 18 Oct 2014 20:14:43 +0200 Original-Received: (qmail 29723 invoked by uid 550); 18 Oct 2014 18:14:42 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 29715 invoked from network); 18 Oct 2014 18:14:42 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20141018154518.GE32028@brightrain.aerifal.cx> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:6364 Archived-At: * Rich Felker [2014-10-18 11:45:18 -0400]: > > If I understand the explanation of what's going on correctly, it's a > huge bug in libstdc++, and exactly the same as the one that's known > (and that we've discussed on IRC, etc.) many times in libxml2: > > https://bugzilla.gnome.org/show_bug.cgi?id=704904 > > It looks to me like gcc is expecting dynamic-linking-like and/or > bloatware-libpthread-like behavior, where if any one of the pthread > symbols has a definition, they all do. This is definitely NOT the case > with static linking, especially with musl. It's also not the case with > glibc, though they have more indirect dependencies that cause a large > portion (but not all) of libpthread to be pulled in when you use any > one part, and some distros (at least Redhat ones, IIRC) link their > libpthread.a with a hack to merge all the modules into one giant .o > file inside the .a precisely to work around bugs like this. > > If I'm correct, just removing all the weak attributes from the > gthr-posix.h stuff should fix the bug. yes this is the bug it turns out gthr-posix.h decides if there are threads if pthread_cancel is present (weak ref is non-null) (on glibc it checks pthread_key_create and on bionic it checks pthread_create) if there is no pthread_cancel then libstdc++ will assume no threads and __gthread calls fail (eg iostream locks are skipped, in call_once a system_error is thrown) if there is pthread_cancel then a __gthread_something call will call pthread_something and if that is otherwise unreferenced it will crash (in case of static linking) example that crases here whit -static: #include #include int (*f)(pthread_t) = pthread_cancel; int main() { std::cout << ""; } possible workaround: create a .o that references all pthread_* functions and link it into your app (this is the bloatware-libpthread solution until libstdc++ is fixed)