Thread: conflicting gettimeofday with MinGW

conflicting gettimeofday with MinGW

From
"Zeugswetter Andreas ADI SD"
Date:
mingw-runtime-3.10 introduced a gettimeofday declaration in sys/time.h
that is not compatible with port.h.
(current is mingw-runtime-3.12)

int __cdecl gettimeofday(struct timeval *__restrict__,         void *__restrict__  /*    tzp (unused) */);

The problem was already reported by Marc Lepage on June 26, 2006 shortly
after the mingw-runtime release,
(He reported back that it was a MinGW installation issue. But it is a
version issue.).

Now, we could probably make a case that MinGW needs to use "struct
timezone" instead of void,
but that change alone still does not make pg compile, because of the
"#define TIMEZONE_GLOBAL timezone"
in port.h.

Any opinions on how to proceed ?

Andreas


Re: conflicting gettimeofday with MinGW

From
Magnus Hagander
Date:
On Wed, Apr 11, 2007 at 01:45:28PM +0200, Zeugswetter Andreas ADI SD wrote:
> 
> mingw-runtime-3.10 introduced a gettimeofday declaration in sys/time.h
> that is not compatible with port.h.
> (current is mingw-runtime-3.12)
> 
> int __cdecl gettimeofday(struct timeval *__restrict__,
>              void *__restrict__  /*    tzp (unused) */);
> 
> The problem was already reported by Marc Lepage on June 26, 2006 shortly
> after the mingw-runtime release,
> (He reported back that it was a MinGW installation issue. But it is a
> version issue.).
> 
> Now, we could probably make a case that MinGW needs to use "struct
> timezone" instead of void,
> but that change alone still does not make pg compile, because of the
> "#define TIMEZONE_GLOBAL timezone"
> in port.h.
> 
> Any opinions on how to proceed ?

There doesn't happen to be a #define you can set to make mingw backwards
compatible with itself and not define that header?

We don't use gettimeofday() from them anyway, we use the one in
libpgport...

//Magnus



Re: conflicting gettimeofday with MinGW

From
Andrew Dunstan
Date:
Zeugswetter Andreas ADI SD wrote:
> mingw-runtime-3.10 introduced a gettimeofday declaration in sys/time.h
> that is not compatible with port.h.
> (current is mingw-runtime-3.12)
>
> int __cdecl gettimeofday(struct timeval *__restrict__,
>              void *__restrict__  /*    tzp (unused) */);
>
> The problem was already reported by Marc Lepage on June 26, 2006 shortly
> after the mingw-runtime release,
> (He reported back that it was a MinGW installation issue. But it is a
> version issue.).
>
> Now, we could probably make a case that MinGW needs to use "struct
> timezone" instead of void,
> but that change alone still does not make pg compile, because of the
> "#define TIMEZONE_GLOBAL timezone"
> in port.h.
>
> Any opinions on how to proceed ?
>
>
>   

I don't see 3.10 on the download page at http://www.mingw.org/download.shtml

The current release is apparently 3.9.

cheers

andrew



Re: conflicting gettimeofday with MinGW

From
"Zeugswetter Andreas ADI SD"
Date:
That page is ages out of date. The intended sync is apparently broken.
The current download area is on sourceforge
http://sf.net/project/showfiles.php?group_id=2435

Andreas

> > mingw-runtime-3.10 introduced a gettimeofday declaration in
> sys/time.h
> > that is not compatible with port.h.
> > (current is mingw-runtime-3.12)
> >
> > int __cdecl gettimeofday(struct timeval *__restrict__,
> >              void *__restrict__  /*    tzp (unused) */);
> >
> > The problem was already reported by Marc Lepage on June 26, 2006
> > shortly after the mingw-runtime release, (He reported back
> that it was
> > a MinGW installation issue. But it is a version issue.).
> >
> > Now, we could probably make a case that MinGW needs to use "struct
> > timezone" instead of void, but that change alone still does
> not make
> > pg compile, because of the "#define TIMEZONE_GLOBAL timezone"
> > in port.h.
> >
> > Any opinions on how to proceed ?
> >
> >
> >
>
> I don't see 3.10 on the download page at
> http://www.mingw.org/download.shtml


Re: conflicting gettimeofday with MinGW

From
Andrew Dunstan
Date:
Zeugswetter Andreas ADI SD wrote:
> That page is ages out of date. The intended sync is apparently broken.
> The current download area is on sourceforge
> http://sf.net/project/showfiles.php?group_id=2435
>
>   

*sigh*

And what is in 3.12, which is apparently the current version?

cheers

andrew


Re: conflicting gettimeofday with MinGW

From
"Zeugswetter Andreas ADI SD"
Date:
> > That page is ages out of date. The intended sync is
> apparently broken.
> > The current download area is on sourceforge
> > http://sf.net/project/showfiles.php?group_id=2435
> >
> >
>
> *sigh*
>
> And what is in 3.12, which is apparently the current version?

Sorry that was implied. sys/time.h did not change between 3.10 and 3.12.
There is no #define to remove the declaration.

In cvs the file is marked as dead and gives a reference to cygwin's
w32api.
Maybe the answer is to simply note that the mingw-runtime binary from
sourceforge above 3.9 has a broken sys/time.h (it is not the file from
cygwin but the dead one from cvs).

Andreas


Re: conflicting gettimeofday with MinGW

From
Magnus Hagander
Date:
On Wed, Apr 11, 2007 at 06:17:19PM +0200, Zeugswetter Andreas ADI SD wrote:
> 
> > > That page is ages out of date. The intended sync is 
> > apparently broken.
> > > The current download area is on sourceforge
> > > http://sf.net/project/showfiles.php?group_id=2435
> > >
> > >   
> > 
> > *sigh*
> > 
> > And what is in 3.12, which is apparently the current version?
> 
> Sorry that was implied. sys/time.h did not change between 3.10 and 3.12.
> There is no #define to remove the declaration.
> 
> In cvs the file is marked as dead and gives a reference to cygwin's
> w32api.
> Maybe the answer is to simply note that the mingw-runtime binary from
> sourceforge above 3.9 has a broken sys/time.h (it is not the file from
> cygwin but the dead one from cvs). 

I think that soudns reasonable. Something for the mingw FAQ. Care to
provide bruce with a patch?

//Magnus



Re: conflicting gettimeofday with MinGW

From
Andrew Dunstan
Date:
Magnus Hagander wrote:
> On Wed, Apr 11, 2007 at 06:17:19PM +0200, Zeugswetter Andreas ADI SD wrote:
>   
>>>> That page is ages out of date. The intended sync is 
>>>>         
>>> apparently broken.
>>>       
>>>> The current download area is on sourceforge
>>>> http://sf.net/project/showfiles.php?group_id=2435
>>>>
>>>>   
>>>>         
>>> *sigh*
>>>
>>> And what is in 3.12, which is apparently the current version?
>>>       
>> Sorry that was implied. sys/time.h did not change between 3.10 and 3.12.
>> There is no #define to remove the declaration.
>>
>> In cvs the file is marked as dead and gives a reference to cygwin's
>> w32api.
>> Maybe the answer is to simply note that the mingw-runtime binary from
>> sourceforge above 3.9 has a broken sys/time.h (it is not the file from
>> cygwin but the dead one from cvs). 
>>     
>
> I think that soudns reasonable. Something for the mingw FAQ. Care to
> provide bruce with a patch?
>
>   

No, that means that we can't build with currently released Mingw, AIUI. 
I think the solution is probably to rename our replacement gettimeofday 
and add a #define to translate the calls. That's pretty much what we've 
done in other cases, and has seemed to be a more robust strategy than 
supplying replacements for standard library routines with routines of 
the same name.

cheers

andrew




Re: conflicting gettimeofday with MinGW

From
Magnus Hagander
Date:
Andrew Dunstan wrote:
>>> In cvs the file is marked as dead and gives a reference to cygwin's
>>> w32api.
>>> Maybe the answer is to simply note that the mingw-runtime binary from
>>> sourceforge above 3.9 has a broken sys/time.h (it is not the file from
>>> cygwin but the dead one from cvs).     
>>
>> I think that soudns reasonable. Something for the mingw FAQ. Care to
>> provide bruce with a patch?
>>
>>   
> 
> No, that means that we can't build with currently released Mingw, AIUI.
> I think the solution is probably to rename our replacement gettimeofday
> and add a #define to translate the calls. That's pretty much what we've
> done in other cases, and has seemed to be a more robust strategy than
> supplying replacements for standard library routines with routines of
> the same name.

But if I read you right, they're removing it in the next version? That
would indicate that they included it by mistake?

(But sure, in general that's not a bad idea)

//Magnus