Re: Issues with MinGW W64

From: "Johann 'Myrkraverk' Oskarsson" <johann(at)2ndquadrant(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Issues with MinGW W64
Date: 2012-05-31 12:15:57
Message-ID: khn7w1.x5khn7w1.4nqw.v94y.gnus@asuka.myrkraverk.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, May 29, 2012 at 9:04 AM, Johann 'Myrkraverk' Oskarsson
>> <johann(at)2ndquadrant(dot)com> wrote:
>>> The header file crtdefs.h in MinGW typedefs errcode which conflicts
>>> with Postgres' elog.h.
>
>> Eep. Maybe this is not directly relevant, but I guess my first
>> question is: why is MinGW doing that?
>
> I concur with Robert here: your first step should be to push back on
> the MinGW developers about this nonstandard intrusion on application
> namespace. We've been using errcode() as a function name since 2003,
> and it's never been a problem before on any platform, including
> previous versions of MinGW.

I have contacted the MinGW W64 team on this.

> If they won't change it, then we could consider some other hack, but
> that should really be the first attempt.

>>> MinGW W64's sys/stat.h #defines stat to be _stati64 and there is
>>> subsequently a compilation error in port.h:
>>>
>>> note: expected 'struct _stati64 *' but argument is of type 'struct
>>> stat *' error: conflicting types for 'pgwin32_safestat'
>
>> In this case, I really think we ought to change all backend calls
>> that hit stat() to use something like pgstat() instead.
>
> I disagree with this conclusion. That'd be an unnecessarily
> nonstandard notation, which all existing and future developers would
> have to learn. I'd rather work around this in port.h if at all
> possible. I'm not quite sure why the existing code fails, though ---
> is there a conflict between "#define stat" and "#define stat(a,b)"?

I wouldn't know, the compiler is GCC 4.6.3 here (any 4.5+ will do I
think) so all the usal GCC macro magic should be working.

Is this something to discuss with the MinGW W64 team?

>>> There are series of redefined macros from the MinGW W64 CRT.
>>> ...
>>> And possibly some more. Do we need these redefines?
>
>> We probably need them somewhere, or they wouldn't have been added.
>> But maybe we don't need them on the exact platform you're using.
>
> Can we deal with this by just wrapping each #define in #ifndef?

I'll take a look and make sure the #defines end up with the same
values. If so I'll attach a patch for this.

--
Johann Oskarsson http://www.2ndquadrant.com/ |[]
PostgreSQL Development, 24x7 Support, Training and Services --+--
|
Blog: http://my.opera.com/myrkraverk/blog/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-05-31 12:16:17 Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)
Previous Message Robert Haas 2012-05-31 12:07:55 Re: FailedAssertion("!(PrivateRefCount[i] == 0)", File: "bufmgr.c", Line: 1741