This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: std thread,mutex,cv and static linking with GCC
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Szabolcs Nagy <nsz at port70 dot net>
- Cc: Damian Lezama <Damian dot Lezama at riverbed dot com>, "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>
- Date: Sun, 16 Nov 2014 14:32:17 +0000
- Subject: Re: std thread,mutex,cv and static linking with GCC
- Authentication-results: sourceware.org; auth=none
- References: <CD78AB7CA98A4D429F16233047F72EA8A775F3 at sfo1exc-mbxp10 dot nbttech dot com> <CAH6eHdQyuE5GpcR+g4A7cTkZX5mrdm04OXYcw-swxT382QVFGA at mail dot gmail dot com> <20141116010444 dot GB10829 at port70 dot net>
On 16 November 2014 01:04, Szabolcs Nagy wrote:
> * Jonathan Wakely <jwakely.gcc@gmail.com> [2014-10-22 18:10:07 +0100]:
>> On 22 October 2014 16:40, Damian Lezama wrote:
>> > Hi,
>> >
>> > I was getting random crashes when using thread, mutex, and cv and statically linking my project. Some of the libraries I link against use pthread, so I narrowed the issue down to this test:
>> >
>> > I statically link a simple test that uses thread, mutex, and cv like this: "g++ --std=c++11 -pthread -static test.cc" and I get this when I run it:
>> >
>> > terminate called after throwing an instance of 'std::system_error'
>> > what(): Enable multithreading to use std::thread: Operation not permitted
>> > Aborted
>> >
>> > Everything works fine if I don't use -static, the problem is specific to static linking. If in my test I use pthread directly to create a thread, then it runs and creating an std::thread also works, but the test crashes when using the cv. My theory is that the linker is being lazy (weak references? optimization?) and the pthread stuff std needs is not included in the binary unless referenced somewhere else. In real projects this is quite dangerous because having dependencies that use most of the pthread stuff makes these crashes rare (I caught this problem with a stress test).
>> >
>> > Any ideas? Is this s bug in the library?
>>
>> Yes, your theory is basically correct.
>>
>> Some GNU/Linux distributions (at least Fedora and Red Hat and its
>> clones) have some custom modifications to libpthread.a that ensures
>> linking statically works. I don't remember the details.
>>
>> An alternative that might help is to use something like
>> -Wl,--whole-archive -lpthread -Wl,--no-whole-archive to link in
>> everything from libpthread.
>>
>> Finally, I believe the problem is solved in the current GCC trunk (at
>> least on GNU/Linux) by a change I made to std::thread that adds an
>> explicit dependency on pthread_create, which should force libpthread
>> to be linked to. I think that might have been backported to the Debian
>> and/or Ubuntu packages for GCC 4.8 and 4.9.
>
> sorry, i'm late to this but fixing std::thread is not enough,
> the weak alias magic in libgcc/gthr-posix.h is not guaranteed to work
>
> there are several bugs here:
>
> 1) fallback code (unknown posix systems) should assume threaded
> application (that's the safest bet)
>
> 2) determining threadedness with weak alias magic is broken for dynamic
> loading and static linking as well (dlopened library can pull in pthread
> dependency at runtime, and the prescence of one symbol says nothing
> about other symbols with static linking)
>
> 3) using symbols through weak aliases at runtime is wrong with static
> linking (it just happens to work by chance with the redhat libpthread.a
> has a single .o hack)
>
> see this analysis for more details and crashing example code:
>
> http://www.openwall.com/lists/musl/2014/10/18/5
I agree, but these issues with gthr-posix.h should probably be
discussed on the main GCC list, as that header is not owned by
libstdc++ and needs wider involvement for any changes.