Re: Is there a way to build PostgreSQL client libraries with MinGW

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, XiaoboGu <guxiaobo1982(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Is there a way to build PostgreSQL client libraries with MinGW
Date: 2011-01-21 10:24:02
Message-ID: AANLkTi=AwssKV7xTyWrztrggfht693vQcSQWrcbTY2Pd@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On Fri, Jan 21, 2011 at 04:06, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
>
> On 01/20/2011 09:52 PM, Robert Haas wrote:
>>
>> On Thu, Jan 20, 2011 at 10:17 AM, XiaoboGu<guxiaobo1982(at)gmail(dot)com>  wrote:
>>>
>>> Hi,
>>>        We are using R to work with 64bit PostgreSQL client libraries, and
>>> to avoid compiler compatibility issues the R development community
>>> suggest
>>> using the same compiler for both the main application and dlls. So do you
>>> have any experience to build libpq.dll using MinGW 64 bit. Thanks.
>>
>> According to the documentation, it's not supported.
>>
>> http://www.postgresql.org/docs/current/static/install-win32.html
>>
>> "Building using MinGW or Cygwin uses the normal build system, see
>> Chapter 15 and the specific notes in Section 15.8.5 and Section
>> 15.8.2. These builds cannot generate 64-bit binaries. Cygwin is not
>> recommended and should only be used for older versions of Windows
>> where the native build does not work, such as Windows 98. MinGW is
>> only recommended if you are building other modules using it. The
>> official binaries are built using Visual Studio."
>
> That advice needs to be taken with a grain or two of salt. First, while you
> probably should not use Cygwin postgres as a production server, it is still
> the best way to run psql on Windows that I know of. And second, the stuff

Yeah, I agree for psql the client tool (though it used to suck badly
if you were in a non-english locale, but they may have fixed that).
But not for PostgreSQL the full product. I guess we could add a
sentence about the client side, but it needs to be clear that the
non-sucky part only applies to the client.

> about not being able to generate 64-bit binaries with Mingw is no longer
> true (that's why it's no longer called Mingw32), although it is true that
> nobody I know has yet tried to do so. It's on my long TODO list, and well
> worth doing. (Relying on one compiler is the techno equivalent of
> monolingualism, which my sister's bumper sticker used to tell me is a
> curable condition.)

It's true from the perspective of *postgresql* - you can't use those
compiler to generate 64-bit binaries of PostgreSQL. And it's referring
to "these builds", not the compiler itself.

And I'm certainly not going to stand in the way of somebody adding
build support for it if they (you or others) want to spend time on it
- that patch should just include an update to that documentation
paragraph, of course.

Personally, I'm going to put what time I can put into "windows build
system updates" into making us work with VS 2010 because I find that
more important - but that's just me personally.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Bernd Helmle 2011-01-21 14:55:53 Re: Psql malloc error on Git master
Previous Message Kunwar Anjani Tyagi 2011-01-21 07:07:19 Regular issues faced on postgres 8.1

Browse pgsql-hackers by date

  From Date Subject
Next Message Itagaki Takahiro 2011-01-21 10:48:29 Re: SQL/MED - file_fdw
Previous Message Itagaki Takahiro 2011-01-21 10:13:32 Re: How to know killed by pg_terminate_backend