0

I have a timer program which uses clock_gettime. This requires -lpthread option to compile successfully or else it gets undefined reference to 'clock_gettime' error.

As so far I explored that we can generate preprocessor warning messages with #warning and check if the include is present by #if __has_include("<pthread.h>"). But checking those does not really check if clock_gettime function is defined.

Just curious if I can make a custom message to warn people at compile time or preprocessing time who compiled without it to include -lpthread option.

I am using MinGW on Windows.

Cerlancism
  • 2,803
  • 5
  • 14
  • 20

1 Answers1

2

I have a timer program which uses clock_gettime. This requires -lpthread option to compile successfully or else it gets undefined reference to clock_gettime error.

clock_gettime requires -lrt, see man clock_gettime. -lpthread just happens to depend on that library.

-lpthread linker option should never be used because it is not sufficient. The correct way to compile and link multi-threaded applications is to use -pthread compiler and linker option. The compiler option defines the required macros, the linker option links the correct library.

Just curious if I can make a custom message to warn people at compile time or preprocessing time who compiled without it to include -lpthread option.

-lrt is a linker option. When object files are compiled separately from linking, the linker options are not a part of the compiler command line and hence aren't available at that stage. There is link-time code generation, however, the compilers don't normally export linker options as macros for the code being compiled to inspect.

Maxim Egorushkin
  • 131,725
  • 17
  • 180
  • 271
  • POSIX documents `-lpthread`. The `-pthread` is a historical GCC curiousity and is not needed; special macros have not bee required for threads to work for decades. – R.. GitHub STOP HELPING ICE Nov 20 '19 at 18:57
  • 1
    @R.. Linux doesn't claim to be POSIX compliant, neither does MinGW on Windows, neither does gcc. I am not sure what relevance that POSIX documentation has. The gcc documentation is pretty clear with regards to threading. – Maxim Egorushkin Nov 20 '19 at 19:02
  • GNU documentation has a lot of GNU folks' opinions in it. There is no technical reason to need `-pthread` since around 2000-ish. – R.. GitHub STOP HELPING ICE Nov 20 '19 at 19:05
  • @R.. `-pthread` compiler option defines `_REENTRANT` macro on Linux, on Solaris it defined `_MT`, if I remember correctly. If code depends on those macros you have no other option but to use `-pthread`. IMO, there is no good reason to ever use `-lpthread`. I am not sure why you advocate it. – Maxim Egorushkin Nov 20 '19 at 19:08
  • 1
    `_REENTRANT` is a LinuxThreads thing from the late 90s. *Your code* was never supposed to depend on it (as it's in the reserved namespace). It was used by the glibc/LinuxThreads headers from that era, and it's a long-gone thing of the past from when threads were treated as a weird optional add-on. I "advocate" `-lpthread` because it's the [documented standard way](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html) to ensure that the pthread interfaces are available, whereas `-pthread` was a crufty hack to make broken pthread implementations work in the 90s. – R.. GitHub STOP HELPING ICE Nov 20 '19 at 19:11
  • @R.. boost library depends on these macros, for example. In a single-threaded application there may be no point in using reference counter atomic increments for smart pointers because they are considerably more expensive. Your claim that the code is not supposed to depend on those is not practical. – Maxim Egorushkin Nov 20 '19 at 19:17
  • 1
    I am sorry, POSIX documentation doesn't override particular product documentation. `gcc` is pretty clear on what compiler options are needed to compile multi-threaded applications. And it is up-to-date documentation. – Maxim Egorushkin Nov 20 '19 at 19:19
  • Boost is wrong to do that, for many reasons, independent of it being in the reserved namespace and not a macro for application code to use/inspect. Library code that *does not know whether it's going to be used in a multithreaded environment* will be compiled without it defined, and then the code will be broken when it gets used. Compile-time omission of locks is a broken practice from the 90s. You need a runtime predicate to do it correctly. – R.. GitHub STOP HELPING ICE Nov 20 '19 at 19:19
  • _Boost is wrong to do that_. That is too strong of a statement. IMO, your claims are too purist and are not practical. – Maxim Egorushkin Nov 20 '19 at 19:21
  • Insisting on not generating broken code by default is hardly "purist". – R.. GitHub STOP HELPING ICE Nov 20 '19 at 19:22
  • @R.. Your claim that if code uses `_REENTRANT` it is broken is again too purist. You are just dismissing any evidence that contradicts your beliefs. – Maxim Egorushkin Nov 20 '19 at 19:24
  • No, I have consistent reasons for it all. You're not introducing new "evidence". – R.. GitHub STOP HELPING ICE Nov 20 '19 at 19:30
  • -lrt does not seem to work with MinGW, I can't find much information about -lrt when using MinGW on Windows. – Cerlancism Nov 21 '19 at 07:36