Compiling libpq with VC6

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