Thread: Re: Request for supported platforms
> -----Original Message----- > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > Sent: 26 October 2002 03:17 > To: PostgreSQL-development > Cc: Thomas Lockhart; Tom Lane > Subject: [HACKERS] Request for supported platforms > > > Folks. start sending in those plaform reports, OS name and > version number please. CYGWIN_NT-5.1 PC9 1.3.10(0.51/3/2) 2002-02-25 11:14 i686 unknown Make check failed with the normal spurious errors. Make installcheck also failed on horology, copy2 and domain - see attached output. The clocks changed here on Saturday night, so I guess that shouldn't have caused the first error (or should the docs be updated?). The second 2 errors are both with copys - related to the problem with the listen() backlog queue in the parallel test perhaps? Regards, Dave.
Attachment
> -----Original Message-----
> From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
> Sent: 26 October 2002 03:17
> To: PostgreSQL-development
> Cc: Thomas Lockhart; Tom Lane
> Subject: [HACKERS] Request for supported platforms
>
>
> Folks. start sending in those plaform reports, OS name and
> version number please.
>
Windows XP Professional SP1
Client build fails :-(
Regards, Dave.
C:\cygwin\usr\local\src\postgresql-7.3b3\src>nmake /f win32.mak
Microsoft (R) Program Maintenance Utility Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
cd include if not exist pg_config.h copy pg_config.h.win32 pg_config.h 1 file(s) copied. cd ..
cd interfaces\libpq nmake /f win32.mak
Microsoft (R) Program Maintenance Utility Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
Building the Win32 static library...
if not exist ".\Release/" mkdir ".\Release" cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nma04188.
dllist.c cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nmb04188.
md5.c cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nmc04188.
wchar.c cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nmd04188.
encnames.c cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nme04188.
win32.c
fe-auth.c
fe-connect.c
fe-exec.c
fe-lobj.c
fe-misc.c
fe-print.c
fe-secure.c
pqexpbuffer.c link.exe -lib @C:\DOCUME~1\dpage\LOCALS~1\Temp\nmf04188. cl.exe
@C:\DOCUME~1\dpage\LOCALS~1\Temp\nmg04188.
libpqdll.c rc.exe /l 0x409 /fo".\Release\libpq.res" libpq.rc link.exe
@C:\DOCUME~1\dpage\LOCALS~1\Temp\nmh04188. Creating library .\Release\libpqdll.lib and object
.\Release\libpqdll.exp cd ..\..\bin\psql nmake /f win32.mak
Microsoft (R) Program Maintenance Utility Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
if not exist ".\Release/" mkdir ".\Release"
NMAKE : fatal error U1073: don't know how to make '..\..\utils\getopt.c'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual
Studio\VC98\bin\N
MAKE.EXE"' : return code '0x2'
Stop.
C:\cygwin\usr\local\src\postgresql-7.3b3\src>
Dave,
Thanks for the heads up...
On Mon, Oct 28, 2002 at 10:31:00AM -0000, Dave Page wrote:
> > -----Original Message-----
> > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
> > Sent: 26 October 2002 03:17
> > Subject: [HACKERS] Request for supported platforms
> >
> > Folks. start sending in those plaform reports, OS name and
> > version number please.
>
> CYGWIN_NT-5.1 PC9 1.3.10(0.51/3/2) 2002-02-25 11:14 i686 unknown
^^^^^^
Please try with Cygwin 1.3.14-1 while I attempt to deal with at least
the following Cygwin build issues with PostgreSQL CVS as of today at
about 7:00 AM EST:
1. pg_config.h.in HAVE_FSEEKO ifdef:
make[4]: Entering directory `/home/jt/src/pgsql/src/backend/access/common'
gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include -DBUILDING_DLL -c -o heaptuple.o
heaptuple.c
In file included from ../../../../src/include/c.h:56,
from ../../../../src/include/postgres.h:48,
from heaptuple.c:21:
/usr/include/stdio.h:207: parse error before `('
2. Cygwin bison limit exceeded:
make[4]: Entering directory `/home/jt/src/pgsql/src/interfaces/ecpg/preproc'
[snip]
bison -y -d preproc.y
preproc.y:5560: fatal error: maximum table size (32767) exceeded
> Make check failed with the normal spurious errors.
I would stick with make installcheck due to the Cygwin (i.e., Windows)
backlog issue.
> Make installcheck also failed on horology, copy2 and domain - see
> attached output.
>
> The clocks changed here on Saturday night, so I guess that shouldn't
> have caused the first error (or should the docs be updated?).
>
> The second 2 errors are both with copys - related to the problem with
> the listen() backlog queue in the parallel test perhaps?
I haven't looked into the above yet due to the build problems. Any help
regarding these issues is gratefully appreciated.
Thanks,
Jason
> -----Original Message----- > From: Jason Tishler [mailto:jason@tishler.net] > Sent: 28 October 2002 13:33 > To: Dave Page > Cc: Bruce Momjian; PostgreSQL-development; Thomas Lockhart; > Tom Lane; Pgsql-Cygwin > Subject: Re: [HACKERS] Request for supported platforms > > > Dave, > > Thanks for the heads up... > > On Mon, Oct 28, 2002 at 10:31:00AM -0000, Dave Page wrote: > > > -----Original Message----- > > > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > > > Sent: 26 October 2002 03:17 > > > Subject: [HACKERS] Request for supported platforms > > > > > > Folks. start sending in those plaform reports, OS name and > > > version number please. > > > > CYGWIN_NT-5.1 PC9 1.3.10(0.51/3/2) 2002-02-25 11:14 i686 unknown > ^^^^^^ > > Please try with Cygwin 1.3.14-1 while I attempt to deal with > at least the following Cygwin build issues with PostgreSQL > CVS as of today at about 7:00 AM EST: Ok, but this is going to take a while as few of the mirrors seem to have this release yet. I also need to download a new set of everything for reasons I won't go into. Is there actually a reason for this though or are you just trying to keep me busy? :-) It can't be a good thing for us to require that people upgrade to the latest release of their OS. > 2. Cygwin bison limit exceeded: > > make[4]: Entering directory > `/home/jt/src/pgsql/src/interfaces/ecpg/preproc' > [snip] > bison -y -d preproc.y > preproc.y:5560: fatal error: maximum table size (32767) exceeded I believe a new bison is required now. Don't know much about it other than ecpg hit some limit or other and much discussion followed. Iirc, it's only an issue when compiling from CVS, not a tarball. Regards, Dave.
>> Make installcheck also failed on horology, copy2 and domain - see
>> attached output.
>>
>> The clocks changed here on Saturday night, so I guess that shouldn't
>> have caused the first error (or should the docs be updated?).
Horology failures are normal for a day or so on either side of a DST
change --- see the "regression tests interpretation" docs. I have
no time right now to examine the other diffs.
regards, tom lane
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: 28 October 2002 15:53 > To: Jason Tishler > Cc: Dave Page; Bruce Momjian; PostgreSQL-development; Thomas > Lockhart; Pgsql-Cygwin > Subject: Re: [HACKERS] Request for supported platforms > > > >> Make installcheck also failed on horology, copy2 and domain - see > >> attached output. > >> > >> The clocks changed here on Saturday night, so I guess that > shouldn't > >> have caused the first error (or should the docs be updated?). > > Horology failures are normal for a day or so on either side > of a DST change --- see the "regression tests interpretation" > docs. I have no time right now to examine the other diffs. The docs say: ==== Some of the queries in the timestamp test will fail if you run the test on the day of a daylight-savings time changeover, or the day before or after one. ==== Clocks changed at midnight Saturday so I figured a Monday morning run should be OK. Do they actually change on Sunday at 00:00:00 I wonder? I'll try again tomorrow. Regards, Dave.
Dave, On Mon, Oct 28, 2002 at 02:56:01PM -0000, Dave Page wrote: > > -----Original Message----- > > From: Jason Tishler [mailto:jason@tishler.net] > > Sent: 28 October 2002 13:33 > > Subject: Re: [HACKERS] Request for supported platforms > > > > Please try with Cygwin 1.3.14-1 while I attempt to deal with at > > least the following Cygwin build issues with PostgreSQL CVS as of > > today at about 7:00 AM EST: > > Ok, but this is going to take a while as few of the mirrors seem to > have this release yet. I also need to download a new set of everything > for reasons I won't go into. My WAG is that you will be able to upgrade your Cygwin installation before I fix the Cygwin build issues. :,) > Is there actually a reason for this though or are you just trying to > keep me busy? :-) It can't be a good thing for us to require that > people upgrade to the latest release of their OS. Agreed, but sometimes a new Cygwin release fixes some problems and breaks others... > > 2. Cygwin bison limit exceeded: > > > > make[4]: Entering directory > > `/home/jt/src/pgsql/src/interfaces/ecpg/preproc' > > [snip] > > bison -y -d preproc.y > > preproc.y:5560: fatal error: maximum table size (32767) exceeded > > I believe a new bison is required now. Don't know much about it other > than ecpg hit some limit or other and much discussion followed. Iirc, > it's only an issue when compiling from CVS, not a tarball. The above should help save me some time. Thanks, Jason
On Mon, 2002-10-28 at 10:20, Jason Tishler wrote: > > > 2. Cygwin bison limit exceeded: > > > > > > make[4]: Entering directory > > > `/home/jt/src/pgsql/src/interfaces/ecpg/preproc' > > > [snip] > > > bison -y -d preproc.y > > > preproc.y:5560: fatal error: maximum table size (32767) exceeded > > > > I believe a new bison is required now. Don't know much about it other > > than ecpg hit some limit or other and much discussion followed. Iirc, > > it's only an issue when compiling from CVS, not a tarball. > > The above should help save me some time. 1.50 of Bison fixed the issue, 1.75 works as well (current public release). Just my $.02. > > Thanks, > Jason > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
"Dave Page" <dpage@vale-housing.co.uk> writes:
>> Horology failures are normal for a day or so on either side
>> of a DST change --- see the "regression tests interpretation"
>> docs. I have no time right now to examine the other diffs.
> The docs say:
> Some of the queries in the timestamp test will fail if you run the test
> on
> the day of a daylight-savings time changeover, or the day before or
> after
> one.
> Clocks changed at midnight Saturday so I figured a Monday morning run
> should be OK. Do they actually change on Sunday at 00:00:00 I wonder?
> I'll try again tomorrow.
In the US, DST changes occur at 02:00 Sunday, so the affected queries
actually fail starting at 00:00 Sunday and ending 00:00 Tuesday ---
but that's local time in PST8PDT. The docs are vague because your local
time might vary considerably from that ...
regards, tom lane
Dave,
On Mon, Oct 28, 2002 at 11:20:16AM -0500, Jason Tishler wrote:
> On Mon, Oct 28, 2002 at 02:56:01PM -0000, Dave Page wrote:
> > Ok, but this is going to take a while as few of the mirrors seem to
> > have this release yet. I also need to download a new set of everything
> > for reasons I won't go into.
>
> My WAG is that you will be able to upgrade your Cygwin installation
> before I fix the Cygwin build issues. :,)
I guess my WAG was wrong... :,)
Under the following platform:
$ uname -a
CYGWIN_NT-5.0 TISHLERJASON 1.3.14(0.62/3/2) 2002-10-23 14:47 i686 unknown
all make installcheck tests pass except for horology. However, the
horology failure is to be expected due to the recent time change.
Unfortunately, there are some Cygwin build issues that I need to
address:
1. Cygwin bison needs to be upgraded from 1.35 to 1.75 (i.e., 1.50+) to
process src/interfaces/ecpg/preproc/preproc.y successfully. I will post
to the Cygwin mailing list asking the maintainer for this upgrade.
2. The following fseeko/ftello ifdef in src/include/pg_config.h.in:
#ifndef HAVE_FSEEKO
#define fseeko(a, b, c) fseek((a), (b), (c))
#define ftello(a) ftell((a))
#endif
conflicts with the following Cygwin /usr/include/stdio.h entries:
int _EXFUN(fseeko, (FILE *, off_t, int));
off_t _EXFUN(ftello, ( FILE *));
Unfortunately, I'm not sure what is the best way to solve this one yet.
Any suggestions would be appreciated.
Thanks,
Jason
> -----Original Message----- > From: Jason Tishler [mailto:jason@tishler.net] > Sent: 28 October 2002 20:42 > To: Dave Page > Cc: Bruce Momjian; PostgreSQL-development; Thomas Lockhart; > Tom Lane; Pgsql-Cygwin > Subject: Re: [HACKERS] Request for supported platforms > > > Dave, > > On Mon, Oct 28, 2002 at 11:20:16AM -0500, Jason Tishler wrote: > > > > My WAG is that you will be able to upgrade your Cygwin installation > > before I fix the Cygwin build issues. :,) > > I guess my WAG was wrong... :,) I've been meaning to ask this for a while - what exactly is a WAG? :-) > 1. Cygwin bison needs to be upgraded from 1.35 to 1.75 (i.e., > 1.50+) to process src/interfaces/ecpg/preproc/preproc.y > successfully. I will post to the Cygwin mailing list asking > the maintainer for this upgrade. OK. This shouldn't stop a release though I assume, only a build from CVS. > 2. The following fseeko/ftello ifdef in src/include/pg_config.h.in: > > #ifndef HAVE_FSEEKO > #define fseeko(a, b, c) fseek((a), (b), (c)) > #define ftello(a) ftell((a)) > #endif > > conflicts with the following Cygwin /usr/include/stdio.h entries: > > int _EXFUN(fseeko, (FILE *, off_t, int)); > off_t _EXFUN(ftello, ( FILE *)); > > Unfortunately, I'm not sure what is the best way to solve > this one yet. Any suggestions would be appreciated. Yes, I'm seeing errors with this on my updated Cygwin very early in the build. I did think it was my hacked about installation, but I guess not! Unfortunately though, I don't know the answer either, but I guess the change was in Cygwin as I didn't see it before you asked me to upgrade. Regards, Dave.
On Mon, 2002-10-28 at 14:58, Dave Page wrote: > > > > > > > My WAG is that you will be able to upgrade your Cygwin installation > > > before I fix the Cygwin build issues. :,) > > > > I guess my WAG was wrong... :,) > > I've been meaning to ask this for a while - what exactly is a WAG? :-) Wild-A**ed-Guess, I would presume. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Are you compiling from CVS or from a released tarball? The bison
requirement was recently raised to bison 1.5 or above (1.75 was recently
released also.) This is an issue only when compiling from CVS, since
the bison stuff is preprocessed for released tarballs. So you might
want to try the just release beta3.
On Mon, 2002-10-28 at 08:32, Jason Tishler wrote:
> Dave,
>
> Thanks for the heads up...
>
> On Mon, Oct 28, 2002 at 10:31:00AM -0000, Dave Page wrote:
> > > -----Original Message-----
> > > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
> > > Sent: 26 October 2002 03:17
> > > Subject: [HACKERS] Request for supported platforms
> > >
> > > Folks. start sending in those plaform reports, OS name and
> > > version number please.
> >
> > CYGWIN_NT-5.1 PC9 1.3.10(0.51/3/2) 2002-02-25 11:14 i686 unknown
> ^^^^^^
>
> Please try with Cygwin 1.3.14-1 while I attempt to deal with at least
> the following Cygwin build issues with PostgreSQL CVS as of today at
> about 7:00 AM EST:
>
> 1. pg_config.h.in HAVE_FSEEKO ifdef:
>
> make[4]: Entering directory `/home/jt/src/pgsql/src/backend/access/common'
> gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include -DBUILDING_DLL -c -o
heaptuple.oheaptuple.c
> In file included from ../../../../src/include/c.h:56,
> from ../../../../src/include/postgres.h:48,
> from heaptuple.c:21:
> /usr/include/stdio.h:207: parse error before `('
>
> 2. Cygwin bison limit exceeded:
>
> make[4]: Entering directory `/home/jt/src/pgsql/src/interfaces/ecpg/preproc'
> [snip]
> bison -y -d preproc.y
> preproc.y:5560: fatal error: maximum table size (32767) exceeded
>
> > Make check failed with the normal spurious errors.
>
> I would stick with make installcheck due to the Cygwin (i.e., Windows)
> backlog issue.
>
> > Make installcheck also failed on horology, copy2 and domain - see
> > attached output.
> >
> > The clocks changed here on Saturday night, so I guess that shouldn't
> > have caused the first error (or should the docs be updated?).
> >
> > The second 2 errors are both with copys - related to the problem with
> > the listen() backlog queue in the parallel test perhaps?
>
> I haven't looked into the above yet due to the build problems. Any help
> regarding these issues is gratefully appreciated.
>
> Thanks,
> Jason
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
I have updated CVS and re-added getopt.c, now in /port, and updated win32.mak. That should help. --------------------------------------------------------------------------- Dave Page wrote: > > > > -----Original Message----- > > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > > Sent: 26 October 2002 03:17 > > To: PostgreSQL-development > > Cc: Thomas Lockhart; Tom Lane > > Subject: [HACKERS] Request for supported platforms > > > > > > Folks. start sending in those plaform reports, OS name and > > version number please. > > > > Windows XP Professional SP1 > > Client build fails :-( > > Regards, Dave. > > C:\cygwin\usr\local\src\postgresql-7.3b3\src>nmake /f win32.mak > > Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 > Copyright (C) Microsoft Corp 1988-1998. All rights reserved. > > cd include > if not exist pg_config.h copy pg_config.h.win32 pg_config.h > 1 file(s) copied. > cd .. > cd interfaces\libpq > nmake /f win32.mak > > Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 > Copyright (C) Microsoft Corp 1988-1998. All rights reserved. > > Building the Win32 static library... > > if not exist ".\Release/" mkdir ".\Release" > cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nma04188. > dllist.c > cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nmb04188. > md5.c > cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nmc04188. > wchar.c > cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nmd04188. > encnames.c > cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nme04188. > win32.c > fe-auth.c > fe-connect.c > fe-exec.c > fe-lobj.c > fe-misc.c > fe-print.c > fe-secure.c > pqexpbuffer.c > link.exe -lib @C:\DOCUME~1\dpage\LOCALS~1\Temp\nmf04188. > cl.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nmg04188. > libpqdll.c > rc.exe /l 0x409 /fo".\Release\libpq.res" libpq.rc > link.exe @C:\DOCUME~1\dpage\LOCALS~1\Temp\nmh04188. > Creating library .\Release\libpqdll.lib and object > .\Release\libpqdll.exp > cd ..\..\bin\psql > nmake /f win32.mak > > Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 > Copyright (C) Microsoft Corp 1988-1998. All rights reserved. > > if not exist ".\Release/" mkdir ".\Release" > NMAKE : fatal error U1073: don't know how to make '..\..\utils\getopt.c' > Stop. > NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual > Studio\VC98\bin\N > MAKE.EXE"' : return code '0x2' > Stop. > > C:\cygwin\usr\local\src\postgresql-7.3b3\src> > -- 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
> -----Original Message----- > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > Sent: 29 October 2002 04:24 > To: Dave Page > Cc: PostgreSQL-development; Thomas Lockhart; Tom Lane > Subject: Re: [HACKERS] Request for supported platforms > > > > I have updated CVS and re-added getopt.c, now in /port, and > updated win32.mak. That should help. Thanks. Unfortunately not quite there though: print.c(1038) : warning C4013: 'pclose' undefined; assuming extern returning int describe.c tab-complete.c describe.c(1462) : warning C4761: integral size mismatch in argument; conversion supplied mbprint.c link.exe @.\nmc01556. print.obj : error LNK2001: unresolved external symbol _pclose .\Release\psql.exe : fatal error LNK1120: 1 unresolved externals NMAKE : fatal error U1077: 'link.exe' : return code '0x460' Stop. NMAKE : fatal error U1077: '"c:\Program Files\Microsoft Visual Studio\VC98\bin\nmake.exe"' : return code '0x2' Stop. Any ideas? Regards, Dave.
Dave,
On Mon, Oct 28, 2002 at 08:58:12PM -0000, Dave Page wrote:
> > -----Original Message-----
> > From: Jason Tishler [mailto:jason@tishler.net]
> > Sent: 28 October 2002 20:42
> > Subject: Re: [HACKERS] Request for supported platforms
> >
> > On Mon, Oct 28, 2002 at 11:20:16AM -0500, Jason Tishler wrote:
> > > My WAG is that you will be able to upgrade your Cygwin
> > > installation before I fix the Cygwin build issues. :,)
> >
> > I guess my WAG was wrong... :,)
>
> I've been meaning to ask this for a while - what exactly is a WAG? :-)
Larry was kind enough to answer this one for me. :,)
> > 1. Cygwin bison needs to be upgraded from 1.35 to 1.75 (i.e.,
> > 1.50+) to process src/interfaces/ecpg/preproc/preproc.y
> > successfully. I will post to the Cygwin mailing list asking
> > the maintainer for this upgrade.
>
> OK. This shouldn't stop a release though I assume, only a build from
> CVS.
Yes. Nevertheless, I have posted my request:
http://cygwin.com/ml/cygwin/2002-10/msg01740.html
> > 2. The following fseeko/ftello ifdef in src/include/pg_config.h.in:
> >
> > #ifndef HAVE_FSEEKO
> > #define fseeko(a, b, c) fseek((a), (b), (c))
> > #define ftello(a) ftell((a))
> > #endif
> >
> > conflicts with the following Cygwin /usr/include/stdio.h entries:
> >
> > int _EXFUN(fseeko, (FILE *, off_t, int));
> > off_t _EXFUN(ftello, ( FILE *));
> >
> > Unfortunately, I'm not sure what is the best way to solve
> > this one yet. Any suggestions would be appreciated.
I found a solution to the above which will hopefully find its way into
the next Cygwin release:
http://cygwin.com/ml/cygwin-patches/2002-q4/msg00042.html
> Yes, I'm seeing errors with this on my updated Cygwin very early in
> the build. I did think it was my hacked about installation, but I
> guess not!
A quick and *dirty* fix for this problem is to temporarily delete the
above two entries from your stdio.h file.
Jason
Matthew, On Mon, Oct 28, 2002 at 10:50:40PM -0500, Matthew T. O'Connor wrote: > Are you compiling from CVS or from a released tarball? CVS. > The bison requirement was recently raised to bison 1.5 or above (1.75 > was recently released also.) This is an issue only when compiling > from CVS, since the bison stuff is preprocessed for released tarballs. > So you might want to try the just release beta3. Thanks for the above, but see my recent, related posts (if interested). Jason
> -----Original Message----- > From: Jason Tishler [mailto:jason@tishler.net] > Sent: 29 October 2002 14:48 > To: Dave Page > Cc: Bruce Momjian; PostgreSQL-development; Thomas Lockhart; > Tom Lane; Pgsql-Cygwin > Subject: Re: [HACKERS] Request for supported platforms > > > I found a solution to the above which will hopefully find its way > into the next Cygwin release: > > http://cygwin.com/ml/cygwin-patches/2002-q4/msg00042.html > > > Yes, I'm seeing errors with this on my updated Cygwin very early in > > the build. I did think it was my hacked about installation, but I > > guess not! > > A quick and *dirty* fix for this problem is to temporarily delete the > above two entries from your stdio.h file. Hi Jason, All regression tests pass with the above hack on: CYGWIN_NT-5.1 PC9 1.3.14(0.62/3/2) 2002-10-24 10:48 i686 unknown Hackers: As the Cygwin release that is actively supported is the binary distribution that Jason builds, I would think this is OK to be listed as supported if no-one disagrees... Regards, Dave.
Dave, On Tue, Oct 29, 2002 at 04:57:58PM -0000, Dave Page wrote: > All regression tests pass with the above hack on: > > CYGWIN_NT-5.1 PC9 1.3.14(0.62/3/2) 2002-10-24 10:48 i686 unknown Thanks for the above. > Hackers: As the Cygwin release that is actively supported is the > binary distribution that Jason builds, I would think this is OK to be > listed as supported if no-one disagrees... Umm... Should I disagree? :,) Jason
I kept Dave and Jason's name on the report. Ports list updated: http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html --------------------------------------------------------------------------- Dave Page wrote: > > > > -----Original Message----- > > From: Jason Tishler [mailto:jason@tishler.net] > > Sent: 29 October 2002 14:48 > > To: Dave Page > > Cc: Bruce Momjian; PostgreSQL-development; Thomas Lockhart; > > Tom Lane; Pgsql-Cygwin > > Subject: Re: [HACKERS] Request for supported platforms > > > > > > I found a solution to the above which will hopefully find its way > > into the next Cygwin release: > > > > http://cygwin.com/ml/cygwin-patches/2002-q4/msg00042.html > > > > > Yes, I'm seeing errors with this on my updated Cygwin very early in > > > the build. I did think it was my hacked about installation, but I > > > guess not! > > > > A quick and *dirty* fix for this problem is to temporarily delete the > > above two entries from your stdio.h file. > > Hi Jason, > > All regression tests pass with the above hack on: > > CYGWIN_NT-5.1 PC9 1.3.14(0.62/3/2) 2002-10-24 10:48 i686 unknown > > Hackers: As the Cygwin release that is actively supported is the binary > distribution that Jason builds, I would think this is OK to be listed as > supported if no-one disagrees... > > Regards, Dave. > -- 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
Attached is a diff to fix the pclose problem. It turns out there was code in there to make popen/pclose be _popen/_pclose, but it was only in common.c, even in 7.2.3 (print.c). Not sure how it would compile in the past with that. Maybe it didn't. Anyway, this is committed and should _help_ with the compile. --------------------------------------------------------------------------- Dave Page wrote: > > > > -----Original Message----- > > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > > Sent: 29 October 2002 04:24 > > To: Dave Page > > Cc: PostgreSQL-development; Thomas Lockhart; Tom Lane > > Subject: Re: [HACKERS] Request for supported platforms > > > > > > > > I have updated CVS and re-added getopt.c, now in /port, and > > updated win32.mak. That should help. > > Thanks. Unfortunately not quite there though: > > print.c(1038) : warning C4013: 'pclose' undefined; assuming extern > returning int > > describe.c > tab-complete.c > describe.c(1462) : warning C4761: integral size mismatch in argument; > conversion supplied > mbprint.c > link.exe @.\nmc01556. > print.obj : error LNK2001: unresolved external symbol _pclose > .\Release\psql.exe : fatal error LNK1120: 1 unresolved externals > NMAKE : fatal error U1077: 'link.exe' : return code '0x460' > Stop. > NMAKE : fatal error U1077: '"c:\Program Files\Microsoft Visual > Studio\VC98\bin\nmake.exe"' : return code '0x2' > Stop. > > Any ideas? > > Regards, Dave. > -- 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/psql/common.c =================================================================== RCS file: /cvsroot/pgsql-server/src/bin/psql/common.c,v retrieving revision 1.50 diff -c -c -r1.50 common.c *** src/bin/psql/common.c 24 Oct 2002 01:33:50 -0000 1.50 --- src/bin/psql/common.c 29 Oct 2002 19:15:38 -0000 *************** *** 6,12 **** * $Header: /cvsroot/pgsql-server/src/bin/psql/common.c,v 1.50 2002/10/24 01:33:50 momjian Exp $ */ #include "postgres_fe.h" - #include "common.h" #include <errno.h> --- 6,11 ---- *************** *** 27,35 **** #ifndef WIN32 #include <sys/ioctl.h> /* for ioctl() */ - #else - #define popen(x,y) _popen(x,y) - #define pclose(x) _pclose(x) #endif #ifdef HAVE_TERMIOS_H --- 26,31 ---- Index: src/bin/psql/common.h =================================================================== RCS file: /cvsroot/pgsql-server/src/bin/psql/common.h,v retrieving revision 1.20 diff -c -c -r1.20 common.h *** src/bin/psql/common.h 23 Oct 2002 19:23:56 -0000 1.20 --- src/bin/psql/common.h 29 Oct 2002 19:15:38 -0000 *************** *** 42,45 **** --- 42,51 ---- /* sprompt.h */ extern char *simple_prompt(const char *prompt, int maxlen, bool echo); + /* Used for all Win32 popen/pclose calls */ + #ifdef WIN32 + #define popen(x,y) _popen(x,y) + #define pclose(x) _pclose(x) + #endif + #endif /* COMMON_H */
> -----Original Message----- > From: Jason Tishler [mailto:jason@tishler.net] > Sent: 29 October 2002 18:58 > To: Dave Page > Cc: Bruce Momjian; PostgreSQL-development; Thomas Lockhart; > Tom Lane; Pgsql-Cygwin > Subject: Re: [HACKERS] Request for supported platforms > > > Hackers: As the Cygwin release that is actively supported is the > > binary distribution that Jason builds, I would think this > is OK to be > > listed as supported if no-one disagrees... > > Umm... Should I disagree? :,) > Entirely up to you - you do the build :-). I'm just pointing out that the line wrt to Cygwin is generally "use the standard package", so if we stick to that, as long as you build it OK, most people needn't worry 'bout hacking stdio.h. Regards, Dave.
> -----Original Message----- > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > Sent: 29 October 2002 19:34 > To: Dave Page > Cc: PostgreSQL-development; Thomas Lockhart; Tom Lane > Subject: Re: [HACKERS] Request for supported platforms > > > > Attached is a diff to fix the pclose problem. It turns out > there was code in there to make popen/pclose be > _popen/_pclose, but it was only in common.c, even in 7.2.3 > (print.c). Not sure how it would compile in the past with > that. Maybe it didn't. Anyway, this is committed and should > _help_ with the compile. Thanks Bruce, builds fine now. Actually, I'm sure it did just a few weeks ago - We've been developing pgAdmin III in C++ using libpq on Windows, Linux and FreeBSD for a few weeks now and we've been using the CVS code. Regards, Dave
Dave,
On Tue, Oct 29, 2002 at 09:00:20PM -0000, Dave Page wrote:
> > -----Original Message-----
> > From: Jason Tishler [mailto:jason@tishler.net]
> > Sent: 29 October 2002 18:58
> >
> > > Hackers: As the Cygwin release that is actively supported is the
> > > binary distribution that Jason builds, I would think this is OK to
> > > be listed as supported if no-one disagrees...
^^^^^^^^^
*********
> > Umm... Should I disagree? :,)
>
> Entirely up to you - you do the build :-).
I was meekly trying to voice my concern about who supplies the "support"
mentioned above.
> I'm just pointing out that the line wrt to Cygwin is generally "use
> the standard package", so if we stick to that, as long as you build it
> OK, most people needn't worry 'bout hacking stdio.h.
If my patch gets accepted, then the stdio.h hack won't be necessary for
anyone (after the next Cygwin release).
Jason
Dave Page writes: > Hackers: As the Cygwin release that is actively supported is the binary > distribution that Jason builds, I would think this is OK to be listed as > supported if no-one disagrees... I disagree. We document as supported those platforms that build out of the box, not those that build somehow, somewhere, by someone. Rather than advocating methods to manually edit your system headers we should try to find out what the problem really is, such as by analyzing config.log. -- Peter Eisentraut peter_e@gmx.net
Peter,
On Wed, Oct 30, 2002 at 07:36:40PM +0100, Peter Eisentraut wrote:
> Dave Page writes:
> > Hackers: As the Cygwin release that is actively supported is the
> > binary distribution that Jason builds, I would think this is OK to
> > be listed as supported if no-one disagrees...
>
> I disagree. We document as supported those platforms that build out
> of the box, not those that build somehow, somewhere, by someone.
>
> Rather than advocating methods to manually edit your system headers we
> should try to find out what the problem really is, such as by
> analyzing config.log.
Did you miss the following?
http://archives.postgresql.org/pgsql-hackers/2002-10/msg01303.php
As you can see, I have already performed root cause analysis of theses
problems *and* have taken the proper steps to ensure that PostgreSQL
builds OOTB under Cygwin (after the next Cygwin release).
Jason
> -----Original Message----- > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > Sent: 05 November 2002 03:18 > To: Sean Chittenden > Cc: Tom Lane; Larry Rosenman; PostgreSQL-development > Subject: Re: [HACKERS] Request for supported platforms > > > > Ports list updated: > > > http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-pla > tforms.html Hi Bruce, I noticed that you haven't updated the entry for Win32 native client-only. That builds OK now thanks to your fixes. Regards, Dave.
Dave Page wrote: > > > > -----Original Message----- > > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > > Sent: 05 November 2002 03:18 > > To: Sean Chittenden > > Cc: Tom Lane; Larry Rosenman; PostgreSQL-development > > Subject: Re: [HACKERS] Request for supported platforms > > > > > > > > Ports list updated: > > > > > > http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-pla > > tforms.html > > Hi Bruce, > > I noticed that you haven't updated the entry for Win32 native > client-only. That builds OK now thanks to your fixes. Thanks. Updated. -- 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
Ports list updated: http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html --------------------------------------------------------------------------- Dave Page wrote: > > > > -----Original Message----- > > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > > Sent: 05 November 2002 03:18 > > To: Sean Chittenden > > Cc: Tom Lane; Larry Rosenman; PostgreSQL-development > > Subject: Re: [HACKERS] Request for supported platforms > > > > > > > > Ports list updated: > > > > > > http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-pla > > tforms.html > > Hi Bruce, > > I noticed that you haven't updated the entry for Win32 native > client-only. That builds OK now thanks to your fixes. > > Regards, Dave. > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > -- 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
This post is just for closure -- both of the issues below have been resolved: On Tue, Oct 29, 2002 at 09:47:35AM -0500, Jason Tishler wrote: > > > 1. Cygwin bison needs to be upgraded from 1.35 to 1.75 (i.e., > > > 1.50+) to process src/interfaces/ecpg/preproc/preproc.y > > > successfully. I will post to the Cygwin mailing list asking the > > > maintainer for this upgrade. > > > > OK. This shouldn't stop a release though I assume, only a build from > > CVS. > > Yes. Nevertheless, I have posted my request: > > http://cygwin.com/ml/cygwin/2002-10/msg01740.html http://cygwin.com/ml/cygwin-announce/2002-10/msg00016.html > > > 2. The following fseeko/ftello ifdef in src/include/pg_config.h.in: > > > > > > #ifndef HAVE_FSEEKO > > > #define fseeko(a, b, c) fseek((a), (b), (c)) > > > #define ftello(a) ftell((a)) > > > #endif > > > > > > conflicts with the following Cygwin /usr/include/stdio.h entries: > > > > > > int _EXFUN(fseeko, (FILE *, off_t, int)); > > > off_t _EXFUN(ftello, ( FILE *)); > > > > > > Unfortunately, I'm not sure what is the best way to solve this one > > > yet. Any suggestions would be appreciated. > > I found a solution to the above which will hopefully find its way into > the next Cygwin release: > > http://cygwin.com/ml/cygwin-patches/2002-q4/msg00042.html http://cygwin.com/ml/cygwin-patches/2002-q4/msg00089.html Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6