Thread: Compiling libpq with VC6
libpq currently doesn't compile with vc6. The reason is a conflict of prototypes for rename and unlink, which happens when fe-lobj.c includes io.h. The attached patch will redefine unlink and rename only if FRONTEND is not defined. Regards, Andreas Index: port.h =================================================================== RCS file: /projects/cvsroot/pgsql-server/src/include/port.h,v retrieving revision 1.52 diff -u -r1.52 port.h --- port.h 12 Aug 2004 18:32:43 -0000 1.52 +++ port.h 13 Aug 2004 15:58:19 -0000 @@ -141,7 +141,7 @@ extern int pclose_check(FILE *stream); -#if defined(WIN32) || defined(__CYGWIN__) +#if (defined(WIN32) || defined(__CYGWIN__)) && !defined(FRONTEND) /* * Win32 doesn't have reliable rename/unlink during concurrent access, * and we need special code to do symlinks.
The problem with this approach is that it has us using the non-reliable libc rename/unlink rather than our own in libpq. I have already applied a fix that allows the code to compile cleanly. --------------------------------------------------------------------------- Andreas Pflug wrote: > libpq currently doesn't compile with vc6. The reason is a conflict of > prototypes for rename and unlink, which happens when fe-lobj.c includes > io.h. > > The attached patch will redefine unlink and rename only if FRONTEND is > not defined. > > Regards, > Andreas > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian wrote: > The problem with this approach is that it has us using the non-reliable > libc rename/unlink rather than our own in libpq. Not really. The backend will still use the reliable pg_ functions. Frontends continue to use the libc functions, which are totally sufficient in non-concurrent access situations. Regards, Andreas
Andreas Pflug wrote: > Bruce Momjian wrote: > > The problem with this approach is that it has us using the non-reliable > > libc rename/unlink rather than our own in libpq. > > Not really. The backend will still use the reliable pg_ functions. > Frontends continue to use the libc functions, which are totally > sufficient in non-concurrent access situations. I would like to keep full Unix semantics for these functions even in libpq, if possible. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Andreas Pflug wrote:
>> Not really. The backend will still use the reliable pg_ functions.
>> Frontends continue to use the libc functions, which are totally
>> sufficient in non-concurrent access situations.
> I would like to keep full Unix semantics for these functions even in
> libpq, if possible.
libpq doesn't use either rename or unlink AFAIK. However, if we make
the patch be something involving #ifdef FRONTEND, then it will affect
other code that might want to use those.
One thing that hasn't been real clear to me is why this only affects
fe-lobj.c, when we have many other files that include <io.h> after
including postgres.h.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > >>Andreas Pflug wrote: >> >>>Not really. The backend will still use the reliable pg_ functions. >>>Frontends continue to use the libc functions, which are totally >>>sufficient in non-concurrent access situations. > > >>I would like to keep full Unix semantics for these functions even in >>libpq, if possible. > libpq doesn't use either rename or unlink AFAIK. However, if we make > the patch be something involving #ifdef FRONTEND, then it will affect > other code that might want to use those. > > One thing that hasn't been real clear to me is why this only affects > fe-lobj.c, when we have many other files that include <io.h> after > including postgres.h. Quite simple: mingw includes do *not* conflict. Only a minority of tools is object to VC6 compilation, ultimately only libpq is needed. Regards, Andreas
Andreas Pflug wrote: > Tom Lane wrote: > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > >>Andreas Pflug wrote: > >> > >>>Not really. The backend will still use the reliable pg_ functions. > >>>Frontends continue to use the libc functions, which are totally > >>>sufficient in non-concurrent access situations. > > > > > >>I would like to keep full Unix semantics for these functions even in > >>libpq, if possible. > > > libpq doesn't use either rename or unlink AFAIK. However, if we make > > the patch be something involving #ifdef FRONTEND, then it will affect > > other code that might want to use those. > > > > One thing that hasn't been real clear to me is why this only affects > > fe-lobj.c, when we have many other files that include <io.h> after > > including postgres.h. > > Quite simple: mingw includes do *not* conflict. > Only a minority of tools is object to VC6 compilation, ultimately only > libpq is needed. True, only MSVC conflicted. Maybe no one has compiled anything but libpq using MSVC, particularly psql. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Andreas Pflug <pgadmin@pse-consulting.de> writes:
>> One thing that hasn't been real clear to me is why this only affects
>> fe-lobj.c, when we have many other files that include <io.h> after
>> including postgres.h.
> Quite simple: mingw includes do *not* conflict.
> Only a minority of tools is object to VC6 compilation, ultimately only
> libpq is needed.
Hm. Given that we now support a native Windows port, do we care about
building libpq with VC6 anymore? Why wouldn't you just use the library
as built with mingw?
If we were moving in the direction of making the whole project buildable
with VC6, that would be one thing; but as far as I know that is
explicitly not part of the plan. So why should we continue to support a
partially-baked port when we have a full port?
regards, tom lane
Tom Lane wrote: > > Hm. Given that we now support a native Windows port, do we care about > building libpq with VC6 anymore? Yes please! I just tried: I renamed libpq.a to libpq.lib. pgAdmin links with that, but will crash. Regards, Andreas
Tom Lane wrote: > Andreas Pflug <pgadmin@pse-consulting.de> writes: > >> One thing that hasn't been real clear to me is why this only affects > >> fe-lobj.c, when we have many other files that include <io.h> after > >> including postgres.h. > > > Quite simple: mingw includes do *not* conflict. > > Only a minority of tools is object to VC6 compilation, ultimately only > > libpq is needed. > > Hm. Given that we now support a native Windows port, do we care about > building libpq with VC6 anymore? Why wouldn't you just use the library > as built with mingw? > > If we were moving in the direction of making the whole project buildable > with VC6, that would be one thing; but as far as I know that is > explicitly not part of the plan. So why should we continue to support a > partially-baked port when we have a full port? VC seems broken only in the very minor way of io.h. I don't know of any other issues. Doesn't seem like enough of a reason to abandon the build environment. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073