Обсуждение: 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.opg_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=gibbon&dt=2004-11-06%2018:11:58 (Is it possible to get rid of those Info lines?) cheers andrew
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.opg_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=gibbon&dt=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 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, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> 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
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.odumputils.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/
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/
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.opg_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
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.opg_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# ofduplicate definitions for pg_tolower(). 2004-10-06ifeq ($(PORTNAME), win32)EXTRA_OBJS += $(top_builddir)/src/port/exec.oendif 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 indexlists 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 calleach 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 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, Pennsylvania19073
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.opg_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 > 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 > > ---------------------------(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 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, Pennsylvania19073
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.opg_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.odumputils.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 > > 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 > > > > ---------------------------(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 > 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 > > ---------------------------(end of broadcast)--------------------------- > TIP 8: explain analyze is your friend > -- 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 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 -0000 1.57 --- src/bin/pg_dump/Makefile 8 Nov 2004 04:56:52 -0000 *************** *** 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 -0000 1.4 --- src/template/cygwin 8 Nov 2004 04:56:55 -0000 *************** *** 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 -0000 1.2 --- src/template/win32 8 Nov 2004 04:56:56 -0000 *************** *** 0 **** --- 1,4 ---- + # This is required to link pg_dump because it finds pg_toupper() in + # libpq and pgport + LDFLAGS="-Wl,--allow-multiple-definition" +
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.opg_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 -0000 1.57 > --- src/bin/pg_dump/Makefile 8 Nov 2004 04:56:52 -0000 > *************** > *** 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 -0000 1.4 > --- src/template/cygwin 8 Nov 2004 04:56:55 -0000 > *************** > *** 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 -0000 1.2 > --- src/template/win32 8 Nov 2004 04:56:56 -0000 > *************** > *** 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 -Wl,--enable-auto-import to disable the diagnostics Andrew complained about on the buildfarm. Without ld prints this Info: message. I was wrong in my previous mail. Charles Wilson came up with this hint to prevent from printing this diagnostic. http://cygwin.com/ml/cygwin/2004-11/msg00287.html # This is required to link pg_dump because it finds pg_toupper() in # libpq and pgport LDFLAGS="-Wl,--allow-multiple-definition -Wl,--enable-auto-import" # --enable-auto-import gets rid of a diagnostics linker message LDFLAGS_SL="-Wl,--enable-auto-import" FYI: The ranlib step is not needed on win32 platforms. I'm just testing a new build from CVS with atttached patch. My latest builds from two weeks ago could only survive MAX_CONNECTIONS=2. shmget() just crashes with more connections. Before beta1 I could handle up 50 connections. But it could also be that shmget is not correctly resolved or overwritten with 0x0. Maybe I should turn off bittorrent, emule, mysql and apache... Bruce, you apparently lost my pg_ctl service starter patch from http://archives.postgresql.org/pgsql-patches/2004-10/msg00300.php It's not applied and not in the http://momjian.postgresql.org/cgi-bin/pgpatches queue I'm also playing with more port.h patches, having better differences between WIN32 and __CYGWIN__. 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. pgc.c tries to include "config.h" which is now "pg_config.h" contrib/pg_autovacuum CPPFLAG override problem: $ make gcc -g -fno-strict-aliasing pg_autovacuum.o -L../../src/interfaces/libpq -lpq -L../../src/port -Wl,--allow-multiple-definition -Wl,--enable-auto-import -L/usr/local/lib -lpgport -lintl -lssl -lcrypto -lz -lreadline -lcrypt -lresolv -o pg_autovacuum fails with undefined references to `_DLNewElem' ... -I$(srcdir) apparently missing. hmm (scratching my head) make -p # `override' directive (from `../../src/makefiles/pgxs.mk', line 70) CPPFLAGS := -I../../src/interfaces/libpq -I. -I../../src/include # default COMPILE.C = $(COMPILE.cc) # default COMPILE.c = $(CC) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c %.o: %.c # commands to execute (built-in): $(COMPILE.c) $(OUTPUT_OPTION) $< hmm, looks very very strange. The others build just fine, also with the c.o defaults. $ make --version GNU Make 3.80 maybe I should try the make debugger ("remake") -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ Index: contrib/spi/Makefile =================================================================== RCS file: /projects/cvsroot/pgsql/contrib/spi/Makefile,v retrieving revision 1.24 diff -u -b -r1.24 Makefile --- contrib/spi/Makefile 20 Aug 2004 20:13:08 -0000 1.24 +++ contrib/spi/Makefile 8 Nov 2004 05:34:53 -0000 @@ -1,4 +1,4 @@ -# $PostgreSQL: pgsql/contrib/spi/Makefile,v 1.24 2004/08/20 20:13:08 momjian Exp $ +# $PostgreSQL: pgsql-server/contrib/spi/Makefile,v 1.24 2004/08/20 20:13:08 momjian Exp $ MODULES = autoinc insert_username moddatetime refint timetravel DATA_built = $(addsuffix .sql, $(MODULES)) @@ -17,3 +17,5 @@ include $(top_builddir)/src/Makefile.global include $(top_srcdir)/contrib/contrib-global.mk endif + +SHLIB_LINK += -L$(top_builddir)/src/port -lpgport Index: src/bin/pg_ctl/pg_ctl.c =================================================================== RCS file: /projects/cvsroot/pgsql/src/bin/pg_ctl/pg_ctl.c,v retrieving revision 1.45 diff -u -b -r1.45 pg_ctl.c --- src/bin/pg_ctl/pg_ctl.c 4 Nov 2004 22:25:12 -0000 1.45 +++ src/bin/pg_ctl/pg_ctl.c 8 Nov 2004 05:35:21 -0000 @@ -22,6 +22,7 @@ #include "getopt_long.h" #if defined(__CYGWIN__) +#include <sys/cygwin.h> #include <windows.h> /* Cygwin defines WIN32 in windows.h, but we don't want it. */ #undef WIN32 @@ -820,6 +821,9 @@ { static char cmdLine[MAXPGPATH]; int ret; +#ifdef __CYGWIN__ + static char buf[MAXPGPATH]; +#endif if (registration) { @@ -839,6 +843,11 @@ exit(1); } } +#ifdef __CYGWIN__ + /* need to convert to windows path */ + cygwin_conv_to_full_win32_path (cmdLine, buf); + strcpy(cmdLine, buf); +#endif if (registration) { Index: src/interfaces/libpq/Makefile =================================================================== RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/Makefile,v retrieving revision 1.120 diff -u -b -r1.120 Makefile --- src/interfaces/libpq/Makefile 16 Oct 2004 22:52:49 -0000 1.120 +++ src/interfaces/libpq/Makefile 8 Nov 2004 05:35:28 -0000 @@ -31,6 +31,10 @@ md5.o ip.o wchar.o encnames.o noblock.o pgstrcasecmp.o thread.o \ $(filter crypt.o getaddrinfo.o inet_aton.o open.o snprintf.o strerror.o, $(LIBOBJS)) +ifeq ($(PORTNAME), cygwin) +override shlib = cyg$(NAME)$(DLSUFFIX) +endif + ifeq ($(PORTNAME), win32) OBJS += win32.o libpqrc.o libpqrc.o : libpq.rc Index: src/template/cygwin =================================================================== RCS file: /projects/cvsroot/pgsql/src/template/cygwin,v retrieving revision 1.4 diff -u -b -r1.4 cygwin --- src/template/cygwin 9 Oct 2003 14:40:36 -0000 1.4 +++ src/template/cygwin 8 Nov 2004 06:59:51 -0000 @@ -1 +1,6 @@ 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 -Wl,--enable-auto-import" +# --enable-auto-import gets rid of a diagnostics linker message +LDFLAGS_SL="-Wl,--enable-auto-import" Index: src/include/port.h =================================================================== RCS file: /projects/cvsroot/pgsql/src/include/port.h,v retrieving revision 1.65 diff -u -b -r1.65 port.h --- src/include/port.h 6 Nov 2004 01:16:14 -0000 1.65 +++ src/include/port.h 8 Nov 2004 07:00:42 -0000 @@ -72,12 +72,17 @@ extern int find_other_exec(const char *argv0, const char *target, const char *versionstr, char *retpath); -#if defined(WIN32) || defined(__CYGWIN__) -#define EXE ".exe" -#define DEVNULL "nul" +#if defined(WIN32) && !defined(__CYGWIN__) +# define EXE ".exe" +# define DEVNULL "nul" #else -#define EXE "" -#define DEVNULL "/dev/null" +# if defined(__CYGWIN__) +# define EXE ".exe" +# define DEVNULL "/dev/null" +# else +# define EXE "" +# define DEVNULL "/dev/null" +# endif #endif /* @@ -89,13 +94,13 @@ * See the "Notes" section about quotes at: * http://home.earthlink.net/~rlively/MANUALS/COMMANDS/C/CMD.HTM */ -#ifdef WIN32 +#if defined(WIN32) && !defined(__CYGWIN__) #define SYSTEMQUOTE "\"" #else #define SYSTEMQUOTE "" #endif -#ifdef WIN32 +#if defined(WIN32) && !defined(__CYGWIN__) #define HOMEDIR "USERPROFILE" #else #define HOMEDIR "HOME" @@ -164,8 +169,9 @@ * Cygwin has its own symlinks which work on Win95/98/ME where * junction points don't, so use it instead. We have no way of * knowing what type of system Cygwin binaries will be run on. + * Note: Some CYGWIN includes might #define WIN32. */ -#ifdef WIN32 +#if defined(WIN32) && !defined(__CYGWIN__) extern int pgsymlink(const char *oldpath, const char *newpath); #define symlink(oldpath, newpath) pgsymlink(oldpath, newpath) #endif @@ -174,7 +180,7 @@ extern bool rmtree(char *path, bool rmtopdir); -#ifdef WIN32 +#if defined(WIN32) && !defined(__CYGWIN__) /* open() replacement to allow delete of held files */ #ifndef WIN32_CLIENT_ONLY @@ -267,7 +273,7 @@ /* thread.h */ extern char *pqStrerror(int errnum, char *strerrbuf, size_t buflen); -#ifndef WIN32 +#if !defined(WIN32) || defined(__CYGWIN__) extern int pqGetpwuid(uid_t uid, struct passwd * resultbuf, char *buffer, size_t buflen, struct passwd ** result); #endif
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
Reini Urban <rurban@x-ray.at> 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