Page MenuHome GnuPG

Declaration of 'struct timespec' in npth-1.6 conflicts with some versions of MinGW
Testing, NormalPublic

Description

Latest versions of mingw.org's MinGW do define struct timespec in the system headers, but don't define __MINGW64_VERSION_MAJOR.
This causes compilation errors in npth-1.6.
A patch to fix that is attached.

Event Timeline

gniibe triaged this task as Normal priority.
gniibe added a subscriber: gniibe.

Please specify the version of MinGW, which you are using. (We use Mingw-w64 for GnuPG Project.)

Does the following patch help? (It works for Mingw-w64.)

@@ -39,12 +39,12 @@ struct msghdr;
 
 /* The mingw-w64 headers define timespec.  For older compilers we keep
    our replacement.  */
-#ifndef __MINGW64_VERSION_MAJOR
+#ifndef _TIMESPEC_DEFINED
 struct timespec {
   long tv_sec;                 /* seconds */
   long tv_nsec;                /* nanoseconds */
 };
-#endif /*__MINGW64_VERSION_MAJOR */
+#endif /* _TIMESPEC_DEFINED */
 
 
 #ifndef ETIMEDOUT

The version of MinGW is 5.4.x, the latest one. It is available from https://osdn.net/projects/mingw/releases.
MinGW64 is a fork of the above (original) MinGW. They have unfortunately diverged, thus the need to have these changes.

The patch you proposed doesn't work for me, because _TIMESPEC_DEFINED is the macro used by MinGW64 headers. mingw.org's headers use a different macro. To avoid having two macros, I preferred to test the value of __MINGW32_MAJOR_VERSION, because MinGW64 freeze the value on the old v3.x (and switched to MINGW64_VERSION or somesuch), whereas mingw.org is still bumping it as it releases newer versions.

Thank you. I understand the situation by looking at mingwrt-5.4.2-mingw32-src.tar.xz.

I prefer not to complicate things in the header file, by adding MINGW64_VERSION and __MINGW32_MAJOR_VERSION.

Possibly, it's better to check by configure and to generate a part of npth.h.
In this case, we can use gnulib's a part of gl_CHECK_TYPE_STRUCT_TIMESPEC, specifically, (TIME_H_DEFINES_STRUCT_TIMESPEC) substitution, I suppose.

Considering again, I think that just removing the definition of the struct timespec in npth.h is the best approach, given the situation, it's been there for MINGW64 and it's now in original MinGW.

Considering again, I think that just removing the definition of the struct timespec in npth.h is the best approach, given the situation, it's been there for MINGW64 and it's now in original MinGW.

Definitely OK, thanks.

Pushed the change removing the definition.

It was the T2202 in 2017, when I touched the lines. At that time, I looked at the code of vlc, libcdio, and Pthread-w32.

Today, I examined those too. For the record, I write my research results.

vlc does: the way of configure (simpler one than I suggested above, just AC_CHECK_TYPES([struct timespec],,,[#include <time.h>]))

libcdio does: #if defined(__MINGW32__) && !defined(__MINGW64_VERSION_MAJOR) && !defined(__struct_timespec_defined)

pthread-win32 does quite complicated:

#if defined __MINGW64__ || _MSC_VER >= 1900
/* These are known to define struct timespec, when <time.h> has been
 * #included, but may not, (probably don't), follow the convention of
 * defining __struct_timespec_defined, as adopted by MinGW.org; for
 * these cases, we unconditionally assume that struct timespec has
 * been defined, otherwise, if MinGW.org's criterion has not been
 * satisfied...
 */
#elif ! defined __struct_timespec_defined
#  ifndef _TIMESPEC_DEFINED
#  define _TIMESPEC_DEFINED
struct timespec
{ /* ...we fall back on this explicit definition.

Well, I learned that how code evolves.

I think that our approach of just removing is valid as of today in 2022, practical and good today.

gniibe changed the task status from Open to Testing.Mar 24 2022, 2:11 AM

Indeed, different versions of MinGW use different symbols to guard the declaration, and using those symbols in not future-proof enough, IME.
Removing the declaration is definitely the best solution.

gniibe added a project: Restricted Project.May 10 2022, 7:31 AM
werner removed a project: Restricted Project.Thu, Sep 22, 11:05 AM