This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: silent breakage without -pthread


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]