Skip site navigation (1) Skip section navigation (2)

Re: [PATCHES] libpq build problem with <io.h> on MS VC++

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,Andrew Francis <locust(at)familyhealth(dot)com(dot)au>,pgsql-hackers-win32(at)postgresql(dot)org,PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [PATCHES] libpq build problem with <io.h> on MS VC++
Date: 2004-08-17 14:34:32
Message-ID: 4172.1092753272@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers-win32pgsql-patches
Andreas Pflug <pgadmin(at)pse-consulting(dot)de> writes:
>> Back on track: if rename() does exist under Windows then my idea is
>> unreliable.  Any other thoughts?  How about #including <io.h> in port.h
>> (for Windows only of course) before we #define these things?

> Probably won't work, because pgrename and rename do not have the same 
> definition/linkage.

So?  The compiler would see something like

	extern linkage_spec rename(...);

	extern int pgrename(...);

	#define rename  pgrename

so the conflict of linkage spec shouldn't bother anything.

> I posted the attached patch 4 days ago, with the comment
> "The attached patch will redefine unlink and rename only if FRONTEND is 
> not defined.".

> I still believe this a good way to fix it.

The conflict would still exist.  AFAICS it's pure chance that it's
not affecting any backend modules at the moment.

			regards, tom lane

In response to

pgsql-patches by date

Next:From: Bruce MomjianDate: 2004-08-17 14:44:20
Subject: Re: libpq build problem with <io.h> on MS VC++
Previous:From: Mark Cave-AylandDate: 2004-08-17 14:33:49
Subject: Re: [PATCHES] GUC variables invisible to contrib/ modules

pgsql-hackers-win32 by date

Next:From: Aleksander KmetecDate: 2004-08-17 14:39:40
Subject: initdb & locale weirdness
Previous:From: Fabien COELHODate: 2004-08-17 14:34:21
Subject: tablespace and sequences?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group