[Mingw-users] mingw error: redefinition of 'struct timespec'

[G]

Hi,

I'm using the latest MinGW in Windows 7/32 bit, and my development environment is Eclipse Kepler.

I have two portable C/C++ projects that seamlessly build&run the SAME code on Visual Studio 2010 and Eclipse Kepler/Linux 12.04.

One of the projects builds&runs with no error also in Eclipse with MinGW toolchain in Windows.

But another project, created on the same architecture gives me the following errors at build wih Eclipse+MinGW:

1 c:\mingw\include\parts\time.h:65:8: error: redefinition of 'struct timespec'


2 c:\mingw\include\pthread.h:320:8: error: previous definition of 'struct timespec'


I have seen that this is an error already referenced in postings on stackoverflow and elsewhere but I don't really know what the solution would be, without making changes in my source code files. Am I doing a MinGW configuration error?

I appreciate your help.

[Gisle Vanem]

1 c:\mingw\include\parts\time.h:65:8: error: redefinition of 'struct timespec'
2 c:\mingw\include\pthread.h:320:8: error: previous definition of 'struct timespec'
I have seen that this is an error already referenced in postings on stackoverflow and elsewhere but I don't really know
what the solution would be, without making changes in my source code files.

Easy. Add '-DHAVE_STRUCT_TIMESPEC' to your CFLAGS.
--
--gv

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
MinGW-***@lists.sourceforge.net

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-***@lists.sourceforge.net?subject=unsubscribe

[Keith Marshall]

Post by Gisle Vanem

1 c:\mingw\include\parts\time.h:65:8: error: redefinition of 'struct timespec'
2 c:\mingw\include\pthread.h:320:8: error: previous definition of 'struct timespec'
I have seen that this is an error already referenced in postings on
stackoverflow and elsewhere ...

Be careful with advice posted on StackOverflow ... it's often posted by
reputation seekers with absolutely no knowledge or experience of the
actual platform in question, so best treated with grave suspicion.

Post by Gisle Vanem

but I don't really know what the solution would be, without making
changes in my source code files.

This results from a misfeature of upstream pthreads-win32 -- it makes no
inherent allowance for the possibility that the compiler suite, (on
which it depends), may add its own definition of struct timespec, as we
have done in mingwrt-3.21.1.

Post by Gisle Vanem
Easy. Add '-DHAVE_STRUCT_TIMESPEC' to your CFLAGS.

Be careful if you adopt this apparently simple "solution"; unless you
also rebuild the pthreads-win32 libraries, with identically the same
addition to CFLAGS, you will have an incompatibility between the
understanding of struct timespec within libpthread.a, (and its
derivatives), ... effectively:

struct timespec
{
__time32_t tv_sec;
__int32 tv_nsec;
};

and the implementation within mingwrt-3.21.1 ... effectively (required
to accommodate the brain damage of MSVCR80.DLL and later):

struct timespec
{
__time64_t tv_sec;
__int32 tv_nsec;
};

If you neglect that discrepancy, and your application calls any of the
pthreads-win32 functions which require a struct timespec * parameter,
then your application will exhibit undefined behaviour.

FWIW, I've been exploring various issues within the pthreads-win32
implementation, over the past week or so. The upstream project conveys
a strong impression of abandonment, so we may wish to adopt and fork it,
but before I do that, and after I've developed a better understanding of
the issues, I will attempt to contact the maintainer of the original
project, and I may then wish to discuss the subject further, here.

[Gisle Vanem]

Post by Keith Marshall
If you neglect that discrepancy, and your application calls any of the
pthreads-win32 functions which require a struct timespec * parameter,
then your application will exhibit undefined behaviour.

Look in PtW32 sources who this struct is used. Specifically how '*abstime'
is filled (I have v2.9.1 here). So since 'tv_sec' there is 32-bit, Pthread
programs could have problems in the year 2036. I assume you have fixed
PtW32 till then :-)
--
--gv

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
MinGW-***@lists.sourceforge.net

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-***@lists.sourceforge.net?subject=unsubscribe

[Keith Marshall]

Post by Gisle Vanem

Post by Keith Marshall
If you neglect that discrepancy, and your application calls any of the
pthreads-win32 functions which require a struct timespec * parameter,
then your application will exhibit undefined behaviour.

Look in PtW32 sources who this struct is used. Specifically how '*abstime'
is filled (I have v2.9.1 here). So since 'tv_sec' there is 32-bit, Pthread
programs could have problems in the year 2036. I assume you have fixed
PtW32 till then :-)

You appear to be missing the point, (actually several related points),
entirely:--

1) HAVE_STRUCT_TIMESPEC is a configuration time macro; it has no
business appearing in any installed header, such as <pthread.h>
which might be considered as a system header, (or otherwise).

2) At libpthread.a build time, HAVE_STRUCT_TIMESPEC is undefined,
by default, for a mingw32 target build; there is no configure
time discovery, to automatically correct this anomaly.

3) If a user installs pthreads-win32 from an on-line resource, in
preference to building it themselves, then it's likely that the
library will have an inbuilt assumption that tv_sec is 32-bit.

4) When this same user builds a client application, and works around
the HAVE_STRUCT_TIMESPEC issue, by forcibly defining it, then the
user's client application will, (if using mingwrt-3.21.1 or later),
construct timespec structures with 64-bit tv_sec; if these are
then passed by reference, to any libpthread.a function, then the
tv_sec and tv_nsec values may be misinterpreted within the library
code; the outcome is unpredictable, and hence undefined.

5) That <pthread.h> defines struct timespec itself is a violation of
POSIX.1. It should be defined in <sched.h>, (which then makes it
indirectly visible, when <pthread.h> is included). However, the
POSIX.1 requirement for <sched.h> is that it shall define struct
timespec *exactly* as it is defined by <time.h> ... admittedly a
thorny issue for a windows implementation, where the platform
vendor doesn't define this structure in *any* header, AFAIK. In
this case, the pthreads-win32 implementation really shouldn't
implement any function which refers to struct timespec, *unless*
configuration time discovery shows it to be defined in a third
party header (for exclusive use with a third party compiler suite)
such as MinGW.org's.

[Eli Zaretskii]

Date: Sun, 11 Oct 2015 08:24:25 +0000
1 c:\mingw\include\parts\time.h:65:8: error: redefinition of 'struct timespec'
2 c:\mingw\include\pthread.h:320:8: error: previous definition of 'struct
timespec'

A misfeature of the ported pthreads, I agree with Keith.

My personal solution is (assuming you don't really need pthreads in
that project) to rename the pthreads headers, so they "don't exist" as
far as the configuration scripts are concerned.

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
MinGW-***@lists.sourceforge.net

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-***@lists.sourceforge.net?subject=unsubscribe

[Keith Marshall]

Post by Eli Zaretskii
My personal solution is (assuming you don't really need pthreads in
that project) to rename the pthreads headers, so they "don't exist" as
far as the configuration scripts are concerned.

A reasonable approach, but kind of begs the question ... if the project
doesn't need pthreads, why would its configuration script(s) check for
<pthread.h>? (Unless, of course, it can use pthreads if supported, or
some alternative fall-back otherwise ... in which case lack of any such
alternative support could be something of a show-stopper).

[Eli Zaretskii]

Date: Sun, 11 Oct 2015 17:56:36 +0100

Post by Eli Zaretskii
My personal solution is (assuming you don't really need pthreads in
that project) to rename the pthreads headers, so they "don't exist" as
far as the configuration scripts are concerned.

A reasonable approach, but kind of begs the question ... if the project
doesn't need pthreads, why would its configuration script(s) check for
<pthread.h>?

Because the standard GNU configure tests "know" this is one place
where 'struct timespec' is declared.

(Unless, of course, it can use pthreads if supported, or some
alternative fall-back otherwise ... in which case lack of any such
alternative support could be something of a show-stopper).

No, most such packages don't use pthreads (or any threads), they just
need the struct declaration.

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
MinGW-***@lists.sourceforge.net

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-***@lists.sourceforge.net?subject=unsubscribe

[Keith Marshall]

Post by Eli Zaretskii

Date: Sun, 11 Oct 2015 17:56:36 +0100

Post by Eli Zaretskii
My personal solution is (assuming you don't really need pthreads in
that project) to rename the pthreads headers, so they "don't exist" as
far as the configuration scripts are concerned.

A reasonable approach, but kind of begs the question ... if the project
doesn't need pthreads, why would its configuration script(s) check for
<pthread.h>?

Because the standard GNU configure tests "know" this is one place
where 'struct timespec' is declared.

Ah. Okay, thanks for that clarification, but (being pedantic) should it
not rather look to <sched.h>, since that is where POSIX.1 requires
struct timespec to be defined? (Of course, that definition would then
propagate through <pthread.h>, which is required to expose all of the
definitions within <sched.h> anyway, but selecting the outer header is
nothing short of blatant namespace pollution, especially since the
preferred origin for struct timespec is <time.h> in the first place).

Post by Eli Zaretskii

(Unless, of course, it can use pthreads if supported, or some
alternative fall-back otherwise ... in which case lack of any such
alternative support could be something of a show-stopper).

No, most such packages don't use pthreads (or any threads), they just
need the struct declaration.

In which case, they should favour <time.h> as its provider ... yes, I do
know that mingwrt-3.21 was broken in this respect, but that has been
corrected in mingwrt-3.21.1. Any preference to elect for inclusion of
<pthread.h>, rather than <time.h>, if that's what it actually does just
for struct timespec, seems to me like it may be a misfeature of GNU
autoconf.

[Keith Marshall]

Post by Keith Marshall

Post by Eli Zaretskii

Date: Sun, 11 Oct 2015 17:56:36 +0100

Post by Eli Zaretskii
My personal solution is (assuming you don't really need pthreads in
that project) to rename the pthreads headers, so they "don't exist" as
far as the configuration scripts are concerned.

A reasonable approach, but kind of begs the question ... if the project
doesn't need pthreads, why would its configuration script(s) check for
<pthread.h>?

Because the standard GNU configure tests "know" this is one place
where 'struct timespec' is declared.

...

Post by Eli Zaretskii
No, most such packages don't use pthreads (or any threads), they just
need the struct declaration.

In which case, they should favour <time.h> as its provider ... yes, I do
know that mingwrt-3.21 was broken in this respect, but that has been
corrected in mingwrt-3.21.1. Any preference to elect for inclusion of
<pthread.h>, rather than <time.h>, if that's what it actually does just
for struct timespec, seems to me like it may be a misfeature of GNU
autoconf.

Reality, however, is rather more encouraging ... autoconf isn't so lame.
This minimal configure script:

$ cat configure.ac
AC_INIT
AC_CHECK_MEMBERS([struct timespec.tv_sec])

when run thus:

$ autoconf
$ ./configure --build=linux --host=mingw32
checking for mingw32-gcc... mingw32-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether mingw32-gcc accepts -g... yes
checking for mingw32-gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... mingw32-gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for struct timespec.tv_sec... yes

successfully detects that struct timespec is defined, *without* ever
looking for <pthread.h>:

$ grep pthread config.log

is completely silent, indicating absolutely no reference whatsoever, to
anything even remotely related to pthreads, so if GNU projects *are*
looking to <pthread.h> for the definition of struct timespec, it is
because individual project maintainers have specified it thus ... quite
inappropriately, IMO.

[Eli Zaretskii]

Date: Sun, 11 Oct 2015 19:29:27 +0100
Reality, however, is rather more encouraging ... autoconf isn't so lame.
[...]
checking for unistd.h... yes
checking for struct timespec.tv_sec... yes
successfully detects that struct timespec is defined, *without* ever

I know ;-) See

http://lists.gnu.org/archive/html/bug-gnulib/2015-01/msg00042.html

so if GNU projects *are* looking to <pthread.h> for the definition
of struct timespec, it is because individual project maintainers
have specified it thus ... quite inappropriately, IMO.

Yes, there's that as well. Also, packages that are not maintained
very actively come with old versions of Autoconf macros.

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
MinGW-***@lists.sourceforge.net

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-***@lists.sourceforge.net?subject=unsubscribe

[Keith Marshall]

Post by Eli Zaretskii

From: Keith Marshall
Date: Sun, 11 Oct 2015 19:29:27 +0100
Reality, however, is rather more encouraging ... autoconf isn't so lame.
[...]
checking for unistd.h... yes
checking for struct timespec.tv_sec... yes
successfully detects that struct timespec is defined, *without* ever

I know ;-) See
http://lists.gnu.org/archive/html/bug-gnulib/2015-01/msg00042.html

Yes. We both know the story behind that. It was my oversight in
mingwrt-3.21, and I fixed it in 3.21.1. The gnulib folks might wish to
reconsider their need for that patch, (unless they wish to continue to
support a runtime library version which we consider to be defunct).

[Eli Zaretskii]

Date: Sun, 11 Oct 2015 18:58:40 +0100

Post by Eli Zaretskii

Post by Keith Marshall
A reasonable approach, but kind of begs the question ... if the project
doesn't need pthreads, why would its configuration script(s) check for
<pthread.h>?

Because the standard GNU configure tests "know" this is one place
where 'struct timespec' is declared.

Ah. Okay, thanks for that clarification, but (being pedantic) should it
not rather look to <sched.h>, since that is where POSIX.1 requires
struct timespec to be defined? (Of course, that definition would then
propagate through <pthread.h>, which is required to expose all of the
definitions within <sched.h> anyway, but selecting the outer header is
nothing short of blatant namespace pollution, especially since the
preferred origin for struct timespec is <time.h> in the first place).

They do try pthread.h, and pthread.h indeed includes sched.h.

Post by Eli Zaretskii
No, most such packages don't use pthreads (or any threads), they just
need the struct declaration.

In which case, they should favour <time.h> as its provider ... yes, I do
know that mingwrt-3.21 was broken in this respect, but that has been
corrected in mingwrt-3.21.1. Any preference to elect for inclusion of
<pthread.h>, rather than <time.h>, if that's what it actually does just
for struct timespec, seems to me like it may be a misfeature of GNU
autoconf.

Autoconf tends to produce very complex scripts, as you well know.
While it's true that time.h (and sys/time.h) are tried before
pthread.h, I'm quite sure I've seen semi-buggy packages that sometimes
have it the other way around, especially in nested configure scripts,
or even just hard-code use of struct timespec by #ifdef HAVE_PTHREAD_H.
It's a mess...

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
MinGW-***@lists.sourceforge.net

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-***@lists.sourceforge.net?subject=unsubscribe

[Keith Marshall]

Post by Eli Zaretskii
Autoconf tends to produce very complex scripts, as you well know.

Sure; just like the the a.out or a.exe produced by GCC is a complex
format, at least for a human to interpret. I tend to view autoconf much
like a compiler, and inspect its generated configure script only for the
purpose of debugging ... the human readable form of this configure
script is configure.ac, plus any other sources it includes.

[G]

Hi Gisle (Vanem),

Your hint solved my problem!

Many thanks for your help, as well as for the contributions of Keith Marshall and Eli Zaretskii