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.] > > Ideas? I posted some ideas in the last paragraph of http://gcc.gnu.org/ml/libstdc++/2012-05/msg00085.html 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
