Closed GoogleCodeExporter closed 9 years ago
Can you clarify a bit more what problem this is solving? Is it that timespec
is already defined in mingw64 -- but not mingw32?
Original comment by csilv...@gmail.com
on 12 Nov 2011 at 5:30
Yes, that is exactly the problem. Mingw64 defines it in sys/types.h like this:
#ifndef _TIMESPEC_DEFINED
#define _TIMESPEC_DEFINED
struct timespec {
time_t tvsec;
long tv_nsec;
};
struct itimerspec {
struct timespec it_interval;
struct timespec it_value;
};
#endif
The macro _TIMESPEC_DEFINED is enabled by default. This gives a compile error
by default with mingw64. This doesn't occur with mingw.org compiler.
In case you are unaware there is two mingw compilers. The mingw.org group which
is 32 bit and the mingw-w64 compiler which is both 32 and 64 bit.
Original comment by cwil...@vigilantsw.com
on 12 Nov 2011 at 12:29
So shouldn't we do the same thing? That is, instead of testing for
+#ifndef __MINGW64_VERSION_MAJOR
should we just check for
#ifndef _TIMESPEC_DEFINED
?
Original comment by csilv...@gmail.com
on 15 Nov 2011 at 2:18
Original comment by csilv...@gmail.com
on 15 Nov 2011 at 2:20
Sure. My question to you is, do you want your version of timespec or
mingw-w64's version? The types seem slightly different. ie. int/long for the
fields.
Original comment by cwil...@vigilantsw.com
on 16 Nov 2011 at 1:48
I think the way it works is that mingw64 will use its own definition, and
everyone else will use the one in port.cc (with int for the fields, I guess)?
In theory this should work ok; we don't use the timespec for anything fancy.
I just submitted a change to svn that uses the __MINGW64_VERSION_MAJOR check.
I can't test on mingw64, but it's a simple enough change it's hopefully right
(*knock on wood*). Feel free to give svn-trunk perftools a whirl and see if it
resolves the issues for you.
Original comment by csilv...@gmail.com
on 16 Nov 2011 at 9:24
This should hopefully be fixed in perftools 1.9, just released. Feel free to
reopen if it's not.
Original comment by csilv...@gmail.com
on 23 Dec 2011 at 12:50
Original issue reported on code.google.com by
cwil...@vigilantsw.com
on 11 Nov 2011 at 9:37