Re: Issues with MinGW W64

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "Johann 'Myrkraverk' Oskarsson" <johann(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Issues with MinGW W64
Date: 2012-05-29 18:19:52
Message-ID: 15750.1338315592@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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)"?

>> 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?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-05-29 18:38:03 Re: pg_upgrade libraries check
Previous Message Bruce Momjian 2012-05-29 18:09:44 Re: pg_upgrade libraries check