Re: Issues with MinGW W64

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: "Johann 'Myrkraverk' Oskarsson" <johann(at)2ndquadrant(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Issues with MinGW W64
Date: 2012-05-29 16:42:53
Message-ID: CA+TgmobAhaJN9sMZmnw6RbrrjOXALSbQLsh+2m2btWEv1D3C5A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.
>
> #ifndef __ERRCODE_DEFINED_MS
> #define __ERRCODE_DEFINED_MS
> typedef int errcode;
> #endif

Eep. Maybe this is not directly relevant, but I guess my first
question is: why is MinGW doing that? It seems like pretty bad form
to go around defining identifiers that user code might be using for
other purposes. We could fix this in our code by, say, changing
errcode to pgerrcode everywhere, but that would be fairly invasive,
and I don't in general want to start putting "pg" in front of every
identifier we use just in case the operating system happens to want to
grab that symbol unannounced for some unrelated purpose.

> 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. Just as the
operating system shouldn't define random symbols that might be in use
by us, we should not be defining, or redefining, symbols that may be
provided by the operating system.

pgstat() might not be the best choice of name, though, because we've
got a file pgstat.c which does something unrelated.

> There are series of redefined macros from the MinGW W64 CRT.
>
> In pg_config_os:
>
> warning: "_WIN32_WINNT" redefined [enabled by default]
> warning: "fseeko" redefined [enabled by default]
> warning: "ftello" redefined [enabled by default]
> warning: "EMSGSIZE" redefined [enabled by default]
> warning: "EAFNOSUPPORT" redefined [enabled by default]
> warning: "EWOULDBLOCK" redefined [enabled by default]
> warning: "ECONNRESET" redefined [enabled by default]
> warning: "EINPROGRESS" redefined [enabled by default]
> warning: "ENOBUFS" redefined [enabled by default]
> warning: "EPROTONOSUPPORT" redefined [enabled by default]
> warning: "ECONNREFUSED" redefined [enabled by default]
> warning: "EOPNOTSUPP" redefined [enabled by default]
>
> In port.h:
>
> warning: "popen" redefined [enabled by default]
> warning: "pclose" redefined [enabled by default]
>
> 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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2012-05-29 16:47:50 Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)
Previous Message Tom Lane 2012-05-29 16:35:57 Re: Bogus nestloop rows estimate in 8.4.7