https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58929
--- Comment #10 from Victor Mataré <mat...@fh-aachen.de> --- (In reply to Jonathan Wakely from comment #9) > The GNU libc has no-op stubs for several pthread functions. I think that is > done so that single threaded programs which don't actually need those > functions can still link to libraries that have references to those > functions. > > They don't block because they're not for use in multithreaded programs. If > you need the real versions you need to link to libpthread. OK, thanks for the clarification. But I feel I need to point out that that's just a huge WTF. How is a C++ dev supposed to know from the standard docs they work with all day that a condition_variable has any relation to libpthread? Least of all if you're used to getting linker errors if you're missing an implementation. I've read up on it a little bit and I can understand the rationale for having no-op mutex-related stuff because that doesn't break behavior in single-threaded code. But wait conditions are supposed to (mostly) block, single-threaded or not. A no-op stub is a severe breach of protocol there because no one expects to get "spurious" wakeups at 100% CPU. Just think about something like this happening in a real-time system. Maybe this should rather be a glibc bug. Any opinions on that?
