This is the mail archive of the
mailing list for the GCC project.
Re: silent breakage without -pthread
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Miles Bader <miles at gnu dot org>
- Cc: gcc-help at gcc dot gnu dot org
- Date: Tue, 29 Jan 2013 10:17:47 +0000
- Subject: Re: silent breakage without -pthread
- References: <firstname.lastname@example.org>
On 29 January 2013 06:49, Miles Bader wrote:
> I just spent a bunch of time debugging some multi-threaded code that
> used to work, but had started failing in odd ways.
> It turned out the problem was that I wasn't using the gcc -pthread
> option; it had worked previously because a random library's pkg-config
> generated included -pthread, but I had changed the library mix to omit
> that library.
> The threading interface I was using was std::thread. Without -pthread,
> threads kinda-sorta worked, but e.g. mutexes were nops!
> Now, the requirement for -pthread is well-known, and maybe requiring the
> option is the practical thigng to do (I dunno), but now that gcc
> includes its own standard threading facility, I wonder if it might be a
> good idea if things at least failed more obviously when -pthread was
> inadvertently omitted...
> [I _already knew_ about the requirement for -pthread, and I imagine the
> debugging experience would have been even more miserable for someone
> who's just starting to use threads... Even looking at a disassembly of
> my functions, there were appropriate calls to the mutex lock/unlock
> functions...that just didn't do anything.]
I posted some ideas in the last paragraph of
If the std::thread code was in a separate libstdc++11.so which was
linked to libpthread.so then it wouldn't be possible to link to
std::thread symbols without getting libpthread.so