Re: [PATCHES] [HACKERS] cygwin build failure
Reini Urban [EMAIL PROTECTED] writes: I'm just testing a new build from CVS with atttached patch. Patch applied. src/interfaces/ecpg/preproc: the .y and *.l files need to be touched and the generated .c/.h recompiled. They are outdated, at least on CVS. They don't exist in CVS. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] cygwin build failure
Hi,
Related to the definition of __DLL_IMPORT below, the cygwin port of
glib/gmodule just does the following:
#define G_MODULE_IMPORT extern
#ifdef G_PLATFORM_WIN32
# define G_MODULE_EXPORT __declspec(dllexport)
#else /* !G_PLATFORM_WIN32 */
# define G_MODULE_EXPORT
#endif /* !G_PLATFORM_WIN32 */
Also, it doesn't make any distinction whether you are building a DLL or not.
The following example has been tested and it works (I've done the
example without gmodule, as we wouldn't want to use that within
postgresql anyways):
dll.h:
extern void foo();
dll.c:
#include dll.h
__declspec(dllexport) void foo() {
return;
}
main.c:
#include dll.h
int main(int argc, char **argv) {
foo();
return 0;
}
This is with recent GCC (3.3.3 on my system), but it probably also works
with older GCC versions.
Don't know if this information is useful in simplying things...
Maarten
Reini Urban wrote:
#ifdef BUILDING_DLL
# ifndef __GNUC__
# define __DLL_IMPORT __declspec(dllimport)
# else
# define __DLL_IMPORT __attribute__((dllimport)) extern
# endif
#else
# define __DLL_IMPORT
#endif
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] cygwin build failure
Tom Lane schrieb: Dunno about the optarg business; it sounds like a DLLIMPORT is needed someplace, but maybe that is a bug in the Cygwin headers rather than our bug? No, that's no bug, just diagnostic messages with the new linker. gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g pg_dump.o common.o pg_dump_sort.o pg_backup_archiver.o pg_backup_db.o pg_backup_custom.o pg_backup_files.o pg_backup_null.o pg_backup_tar.o dumputils.o ../../../src/backend/parser/keywords.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/usr/local/lib -lpgport -lcrypt -o pg_dump.exe ... Info: resolving _optarg by linking to __imp__optarg (auto-import) Info: resolving _optind by linking to __imp__optind (auto-import) collect2: ld returned 1 exit status make[3]: *** [pg_dump] Error 1 I'll check how to get rid of that if you want to get rid of it without grep -v :) But I don't think that is is easily possible to turn off these purely diagnostic messages, without cluttering the source with those __DLL_IMPORT declarations. And I found no easy ld cmdline override solution. But I'll backcheck. #ifdef BUILDING_DLL # ifndef __GNUC__ # define __DLL_IMPORT __declspec(dllimport) # else # define __DLL_IMPORT __attribute__((dllimport)) extern # endif #else # define __DLL_IMPORT #endif -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] cygwin build failure
Reini Urban schrieb: Tom Lane schrieb: Dunno about the optarg business; it sounds like a DLLIMPORT is needed someplace, but maybe that is a bug in the Cygwin headers rather than our bug? No, that's no bug, just diagnostic messages with the new linker. gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g pg_dump.o common.o pg_dump_sort.o pg_backup_archiver.o pg_backup_db.o pg_backup_custom.o pg_backup_files.o pg_backup_null.o pg_backup_tar.o dumputils.o ../../../src/backend/parser/keywords.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/usr/local/lib -lpgport -lcrypt -o pg_dump.exe ... Info: resolving _optarg by linking to __imp__optarg (auto-import) Info: resolving _optind by linking to __imp__optind (auto-import) collect2: ld returned 1 exit status make[3]: *** [pg_dump] Error 1 I'll check how to get rid of that if you want to get rid of it without grep -v :) But I don't think that is is easily possible to turn off these purely diagnostic messages, without cluttering the source with those __DLL_IMPORT declarations. And I found no easy ld cmdline override solution. But I'll backcheck. ok, i'm sure now. there's no way to ignore those diagnostics on the ld side. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(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
Re: [HACKERS] cygwin build failure
Reini Urban wrote: ... Info: resolving _optarg by linking to __imp__optarg (auto-import) Info: resolving _optind by linking to __imp__optind (auto-import) ok, i'm sure now. there's no way to ignore those diagnostics on the ld side. It's a minor annoyance at worst. Not worth spending effort on. The issue in these lines is the important one: ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g pg_dump.o common.o pg_dump_sort.o pg_backup_archiver.o pg_backup_db.o pg_backup_custom.o pg_backup_files.o pg_backup_null.o pg_backup_tar.o dumputils.o ../../../src/backend/parser/keywords.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/usr/local/lib -lpgport -lz -lreadline -lcrypt -o pg_dump.exe ../../../src/port/libpgport.a(pgstrcasecmp.o)(.text+0x1b0): In function `pg_tolower': /home/adunstan/pgbf/root/HEAD/pgsql.4040/src/port/pgstrcasecmp.c:119: multiple definition of `_pg_tolower' ../../../src/interfaces/libpq/libpq.a(dqgds00145.o)(.text+0x0): first defined here cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] cygwin build failure
Andrew Dunstan wrote: Reini Urban wrote: ... Info: resolving _optarg by linking to __imp__optarg (auto-import) Info: resolving _optind by linking to __imp__optind (auto-import) ok, i'm sure now. there's no way to ignore those diagnostics on the ld side. It's a minor annoyance at worst. Not worth spending effort on. The issue in these lines is the important one: ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g pg_dump.o common.o pg_dump_sort.o pg_backup_archiver.o pg_backup_db.o pg_backup_custom.o pg_backup_files.o pg_backup_null.o pg_backup_tar.o dumputils.o ../../../src/backend/parser/keywords.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/usr/local/lib -lpgport -lz -lreadline -lcrypt -o pg_dump.exe ../../../src/port/libpgport.a(pgstrcasecmp.o)(.text+0x1b0): In function `pg_tolower': /home/adunstan/pgbf/root/HEAD/pgsql.4040/src/port/pgstrcasecmp.c:119: multiple definition of `_pg_tolower' ../../../src/interfaces/libpq/libpq.a(dqgds00145.o)(.text+0x0): first defined here Agreed. What could be the solution? I know it is caused by calling pg_strcasecmp in exec.c. I think I see it now. I added this to pg_dump/Makefile: # Not sure why MinGW needs this but it prevents a link failure # of duplicate definitions for pg_tolower(). 2004-10-06 ifeq ($(PORTNAME), win32) EXTRA_OBJS += $(top_builddir)/src/port/exec.o endif Now, the big question is if you remove this from the Makefile, does Cygwin compile OK, and if not, why does that fail? I am thinking we need to run ranlib on Cygwin to fix this properly. My BSD ranlib manual page has: --- ranlib [-v|-V] archive DESCRIPTION ranlib generates an index to the contents of an archive, and stores it in the archive. The index lists each symbol defined by a member of an archive that is a relocatable object file. An archive with such an index speeds up linking to the li- brary, and allows routines in the library to call each other without regard to their placement in the archive. The GNU ranlib program is another form of GNU ar; running ranlib is completely equivalent to executing `ar -s'. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] cygwin build failure
I am all wrong on the following. It turns out we need a special linker flag on Cygwin to allow the linker to link to the first available symbol in the library (like Unix), and MinGW has a similar flag that we can use to prevent the pg_dump/Makefile hack on MinGW too! Working on a patch now. --- Bruce Momjian wrote: Andrew Dunstan wrote: Reini Urban wrote: ... Info: resolving _optarg by linking to __imp__optarg (auto-import) Info: resolving _optind by linking to __imp__optind (auto-import) ok, i'm sure now. there's no way to ignore those diagnostics on the ld side. It's a minor annoyance at worst. Not worth spending effort on. The issue in these lines is the important one: ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g pg_dump.o common.o pg_dump_sort.o pg_backup_archiver.o pg_backup_db.o pg_backup_custom.o pg_backup_files.o pg_backup_null.o pg_backup_tar.o dumputils.o ../../../src/backend/parser/keywords.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/usr/local/lib -lpgport -lz -lreadline -lcrypt -o pg_dump.exe ../../../src/port/libpgport.a(pgstrcasecmp.o)(.text+0x1b0): In function `pg_tolower': /home/adunstan/pgbf/root/HEAD/pgsql.4040/src/port/pgstrcasecmp.c:119: multiple definition of `_pg_tolower' ../../../src/interfaces/libpq/libpq.a(dqgds00145.o)(.text+0x0): first defined here Agreed. What could be the solution? I know it is caused by calling pg_strcasecmp in exec.c. I think I see it now. I added this to pg_dump/Makefile: # Not sure why MinGW needs this but it prevents a link failure # of duplicate definitions for pg_tolower(). 2004-10-06 ifeq ($(PORTNAME), win32) EXTRA_OBJS += $(top_builddir)/src/port/exec.o endif Now, the big question is if you remove this from the Makefile, does Cygwin compile OK, and if not, why does that fail? I am thinking we need to run ranlib on Cygwin to fix this properly. My BSD ranlib manual page has: --- ranlib [-v|-V] archive DESCRIPTION ranlib generates an index to the contents of an archive, and stores it in the archive. The index lists each symbol defined by a member of an archive that is a relocatable object file. An archive with such an index speeds up linking to the li- brary, and allows routines in the library to call each other without regard to their placement in the archive. The GNU ranlib program is another form of GNU ar; running ranlib is completely equivalent to executing `ar -s'. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] cygwin build failure
OK, Andrew found the proper flag so Cygwin and MinGW linking will find the first matching library symbol (like Unix) and not error out because of multiple definitions. I have applied the following patch and removed the pg_dump Makefile hack we had before. --- Bruce Momjian wrote: I am all wrong on the following. It turns out we need a special linker flag on Cygwin to allow the linker to link to the first available symbol in the library (like Unix), and MinGW has a similar flag that we can use to prevent the pg_dump/Makefile hack on MinGW too! Working on a patch now. --- Bruce Momjian wrote: Andrew Dunstan wrote: Reini Urban wrote: ... Info: resolving _optarg by linking to __imp__optarg (auto-import) Info: resolving _optind by linking to __imp__optind (auto-import) ok, i'm sure now. there's no way to ignore those diagnostics on the ld side. It's a minor annoyance at worst. Not worth spending effort on. The issue in these lines is the important one: ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g pg_dump.o common.o pg_dump_sort.o pg_backup_archiver.o pg_backup_db.o pg_backup_custom.o pg_backup_files.o pg_backup_null.o pg_backup_tar.o dumputils.o ../../../src/backend/parser/keywords.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/usr/local/lib -lpgport -lz -lreadline -lcrypt -o pg_dump.exe ../../../src/port/libpgport.a(pgstrcasecmp.o)(.text+0x1b0): In function `pg_tolower': /home/adunstan/pgbf/root/HEAD/pgsql.4040/src/port/pgstrcasecmp.c:119: multiple definition of `_pg_tolower' ../../../src/interfaces/libpq/libpq.a(dqgds00145.o)(.text+0x0): first defined here Agreed. What could be the solution? I know it is caused by calling pg_strcasecmp in exec.c. I think I see it now. I added this to pg_dump/Makefile: # Not sure why MinGW needs this but it prevents a link failure # of duplicate definitions for pg_tolower(). 2004-10-06 ifeq ($(PORTNAME), win32) EXTRA_OBJS += $(top_builddir)/src/port/exec.o endif Now, the big question is if you remove this from the Makefile, does Cygwin compile OK, and if not, why does that fail? I am thinking we need to run ranlib on Cygwin to fix this properly. My BSD ranlib manual page has: --- ranlib [-v|-V] archive DESCRIPTION ranlib generates an index to the contents of an archive, and stores it in the archive. The index lists each symbol defined by a member of an archive that is a relocatable object file. An archive with such an index speeds up linking to the li- brary, and allows routines in the library to call each other without regard to their placement in the archive. The GNU ranlib program is another form of GNU ar; running ranlib is completely equivalent to executing `ar -s'. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 Index: src/bin/pg_dump/Makefile === RCS file: /cvsroot/pgsql/src/bin/pg_dump/Makefile,v retrieving revision 1.57 diff -c -c -r1.57 Makefile *** src/bin/pg_dump/Makefile7 Oct 2004 13:45:48 - 1.57 --- src/bin/pg_dump/Makefile8 Nov 2004 04:56:52 - *** *** 22,33 EXTRA_OBJS = $(top_builddir)/src/backend/parser/keywords.o - # Not sure why MinGW needs this but it prevents a link failure - # of duplicate definitions for pg_tolower(). 2004-10-06 - ifeq ($(PORTNAME), win32) - EXTRA_OBJS += $(top_builddir)/src/port/exec.o -
Re: [HACKERS] cygwin build failure
Bruce Momjian schrieb: OK, Andrew found the proper flag so Cygwin and MinGW linking will find the first matching library symbol (like Unix) and not error out because of multiple definitions. I have applied the following patch and removed the pg_dump Makefile hack we had before. --- Bruce Momjian wrote: I am all wrong on the following. It turns out we need a special linker flag on Cygwin to allow the linker to link to the first available symbol in the library (like Unix), and MinGW has a similar flag that we can use to prevent the pg_dump/Makefile hack on MinGW too! Working on a patch now. --- Bruce Momjian wrote: Andrew Dunstan wrote: Reini Urban wrote: ... Info: resolving _optarg by linking to __imp__optarg (auto-import) Info: resolving _optind by linking to __imp__optind (auto-import) ok, i'm sure now. there's no way to ignore those diagnostics on the ld side. It's a minor annoyance at worst. Not worth spending effort on. The issue in these lines is the important one: ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g pg_dump.o common.o pg_dump_sort.o pg_backup_archiver.o pg_backup_db.o pg_backup_custom.o pg_backup_files.o pg_backup_null.o pg_backup_tar.o dumputils.o ../../../src/backend/parser/keywords.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/usr/local/lib -lpgport -lz -lreadline -lcrypt -o pg_dump.exe ../../../src/port/libpgport.a(pgstrcasecmp.o)(.text+0x1b0): In function `pg_tolower': /home/adunstan/pgbf/root/HEAD/pgsql.4040/src/port/pgstrcasecmp.c:119: multiple definition of `_pg_tolower' ../../../src/interfaces/libpq/libpq.a(dqgds00145.o)(.text+0x0): first defined here Agreed. What could be the solution? I know it is caused by calling pg_strcasecmp in exec.c. I think I see it now. I added this to pg_dump/Makefile: # Not sure why MinGW needs this but it prevents a link failure # of duplicate definitions for pg_tolower(). 2004-10-06 ifeq ($(PORTNAME), win32) EXTRA_OBJS += $(top_builddir)/src/port/exec.o endif Now, the big question is if you remove this from the Makefile, does Cygwin compile OK, and if not, why does that fail? I am thinking we need to run ranlib on Cygwin to fix this properly. My BSD ranlib manual page has: --- ranlib [-v|-V] archive DESCRIPTION ranlib generates an index to the contents of an archive, and stores it in the archive. The index lists each symbol defined by a member of an archive that is a relocatable object file. An archive with such an index speeds up linking to the li- brary, and allows routines in the library to call each other without regard to their placement in the archive. The GNU ranlib program is another form of GNU ar; running ranlib is completely equivalent to executing `ar -s'. Index: src/bin/pg_dump/Makefile === RCS file: /cvsroot/pgsql/src/bin/pg_dump/Makefile,v retrieving revision 1.57 diff -c -c -r1.57 Makefile *** src/bin/pg_dump/Makefile 7 Oct 2004 13:45:48 - 1.57 --- src/bin/pg_dump/Makefile 8 Nov 2004 04:56:52 - *** *** 22,33 EXTRA_OBJS = $(top_builddir)/src/backend/parser/keywords.o - # Not sure why MinGW needs this but it prevents a link failure - # of duplicate definitions for pg_tolower(). 2004-10-06 - ifeq ($(PORTNAME), win32) - EXTRA_OBJS += $(top_builddir)/src/port/exec.o - endif - all: submake-libpq submake-libpgport submake-backend pg_dump pg_restore pg_dumpall pg_dump: pg_dump.o common.o pg_dump_sort.o $(OBJS) $(libpq_builddir)/libpq.a --- 22,27 Index: src/template/cygwin === RCS file: /cvsroot/pgsql/src/template/cygwin,v retrieving revision 1.4 diff -c -c -r1.4 cygwin *** src/template/cygwin 9 Oct 2003 14:40:36 - 1.4 --- src/template/cygwin 8 Nov 2004 04:56:55 - *** *** 1 --- 1,5 SRCH_LIB=/usr/local/lib + # This is required to link pg_dump because it finds pg_toupper() in + # libpq and pgport + LDFLAGS=-Wl,--allow-multiple-definition + Index: src/template/win32 === RCS file: /cvsroot/pgsql/src/template/win32,v retrieving revision 1.2 diff -c -c -r1.2 win32 *** src/template/win32 9 Oct 2003 03:20:34 - 1.2 --- src/template/win32 8 Nov 2004 04:56:56 - *** *** 0 --- 1,4 + # This is required to link pg_dump because it finds pg_toupper() in + # libpq and pgport + LDFLAGS=-Wl,--allow-multiple-definition + While we are here you could also add
[HACKERS] cygwin build failure
As requested by Reini I set up a Cygwin buildfarm client, and immediately got this build failure: gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g pg_dump.o common.o pg_dump_sort.o pg_backup_archiver.o pg_backup_db.o pg_backup_custom.o pg_backup_files.o pg_backup_null.o pg_backup_tar.o dumputils.o ../../../src/backend/parser/keywords.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/usr/local/lib -lpgport -lcrypt -o pg_dump.exe ../../../src/port/libpgport.a(pgstrcasecmp.o)(.text+0x1b0): In function `pg_tolower': /home/adunstan/pgbf/root/HEAD/pgsql.3200/src/port/pgstrcasecmp.c:119: multiple definition of `_pg_tolower' ../../../src/interfaces/libpq/libpq.a(dshcs00145.o)(.text+0x0): first defined here Info: resolving _optarg by linking to __imp__optarg (auto-import) Info: resolving _optind by linking to __imp__optind (auto-import) collect2: ld returned 1 exit status make[3]: *** [pg_dump] Error 1 see http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gibbondt=2004-11-06%2018:11:58 (Is it possible to get rid of those Info lines?) cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] cygwin build failure
Andrew Dunstan wrote: As requested by Reini I set up a Cygwin buildfarm client, and immediately got this build failure: gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g pg_dump.o common.o pg_dump_sort.o pg_backup_archiver.o pg_backup_db.o pg_backup_custom.o pg_backup_files.o pg_backup_null.o pg_backup_tar.o dumputils.o ../../../src/backend/parser/keywords.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/usr/local/lib -lpgport -lcrypt -o pg_dump.exe ../../../src/port/libpgport.a(pgstrcasecmp.o)(.text+0x1b0): In function `pg_tolower': /home/adunstan/pgbf/root/HEAD/pgsql.3200/src/port/pgstrcasecmp.c:119: multiple definition of `_pg_tolower' ../../../src/interfaces/libpq/libpq.a(dshcs00145.o)(.text+0x0): first defined here Info: resolving _optarg by linking to __imp__optarg (auto-import) Info: resolving _optind by linking to __imp__optind (auto-import) collect2: ld returned 1 exit status make[3]: *** [pg_dump] Error 1 see http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gibbondt=2004-11-06%2018:11:58 The _pg_tolower problem started when I changed exec.c to use the more standard pg_strcasecmp rather than stricmp. I am confused why this caused a problem however because libpgport has pg_tolower because it has pgstrcasecmp.c. Any ideas? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] cygwin build failure
Bruce Momjian [EMAIL PROTECTED] writes: Andrew Dunstan wrote: /home/adunstan/pgbf/root/HEAD/pgsql.3200/src/port/pgstrcasecmp.c:119: multiple definition of `_pg_tolower' The _pg_tolower problem started when I changed exec.c to use the more standard pg_strcasecmp rather than stricmp. Since it's in an #ifdef WIN32 section, there's probably no harm in changing it back. Dunno about the optarg business; it sounds like a DLLIMPORT is needed someplace, but maybe that is a bug in the Cygwin headers rather than our bug? regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
