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:[EMAIL PROTECTED] > Sent: Thursday, 29 January 2004 8:11 PM > To: [EMAIL PROTECTED] > Cc: '[EMAIL PROTECTED]' > 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>
diff9c-b.out
Description: Binary data
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
