Re: [pgsql-hackers-win32] Proposed dirmod.c fix for Win32

For application to HEAD, pending community review (rationale provided below
in previous message; no responses hopefully indicates agreement :-)

Following application, dirmod.c must be moved to src/backend/port/win32 (ie.
add to src/backend/port/win32, and remove from src/port).

[changes to configure.in are essentially only the removal of
AC_LIBOBJ(dirmod); other changes to configure.in appear in a previous patch
and yet to be applied]

Please note that dirmod.c has recently been changed to work under cygwin,
along side of the existing win32/mingw implementation, however does not
currently appear, afaics, to be included during a cygwin build. This patch
does not address this deficiency.

Cheers,
Claudio

> -----Original Message-----
> From: Claudio Natoli [mailto:claudio(dot)natoli(at)memetrics(dot)com]
> Sent: Thursday, 29 January 2004 8:11 PM
> To: pgsql-hackers(at)postgresql(dot)org
> Cc: 'pgsql-hackers-win32(at)postgresql(dot)org'
> Subject: [pgsql-hackers-win32] Proposed dirmod.c fix for Win32
>
>
>
> The current version of dirmod.c causes a compilation failure
> under MingW:
>
> ../../../src/port/libpgport.a(dirmod.o.b)(.text+0xe1): In function
> `pgrename':
> e:/cygwin/opt/diff8c/pgsql/src/port/dirmod.c:38: undefined
> reference to
> `errstart'
> ../../../src/port/libpgport.a(dirmod.o.b)(.text+0xef):e:/cygwi
> n/opt/diff8c/p
> gsql/src/port/dirmod.c:38: undefined reference to `elog_finish'
>
> and so on.
>
> [dirmod.c provides replacements for unlink + rename under Win32. These
> functions are currently only ever used by the backend code, and by
> pg_resetxlog]
>
> One solution is, obviously, to drop the elog calls...
>
> A somewhat better solution is to move dirmod.c into
> src/backend/port(/win32?), and just compile dirmod.c directly into the
> backend. pg_resetxlog could then use dirmod.c just as it
> currently uses
> pg_crc.c (refer to Makefile in pg_resetxlog directory). One additional
> requirement would be for pg_resetxlog to be considered a
> FRONTEND component.
>
> Does anyone take issue with this (and/or is it advisable to
> add -DFRONTEND
> to pg_resetxlog Makefile; seems ok to me), or have a better
> idea, before I
> go create/submit a patch?
>
> Cheers,
> Claudio

---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>

Claudio Natoli wrote:
>
> For application to HEAD, pending community review (rationale provided below
> in previous message; no responses hopefully indicates agreement :-)
>
> Following application, dirmod.c must be moved to src/backend/port/win32 (ie.
> add to src/backend/port/win32, and remove from src/port).

backend/port is for port files _only_ used by the backend. If you look
at libpq, you will see crypt() used by the backend and in
Makefile/libpq, with special compile flags.

I have fixed dirmod.c in CVS so it uses the same logic as crypt. Please
review and tell me how you like it.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Claudio Natoli wrote:
>
> For application to HEAD, pending community review (rationale provided below
> in previous message; no responses hopefully indicates agreement :-)
>
> Following application, dirmod.c must be moved to src/backend/port/win32 (ie.
> add to src/backend/port/win32, and remove from src/port).
>
> [changes to configure.in are essentially only the removal of
> AC_LIBOBJ(dirmod); other changes to configure.in appear in a previous patch
> and yet to be applied]

I made more adjustments to configure/configure.in, attached, that should
have this working fine now.

> Please note that dirmod.c has recently been changed to work under cygwin,
> along side of the existing win32/mingw implementation, however does not
> currently appear, afaics, to be included during a cygwin build. This patch
> does not address this deficiency.

OK, I have addressed the cygwin issue in this patch.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073