Thread
-
Last call?
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-10-25T04:29:38Z
Hi. I believe we are still shooting for a Nov 1 release, though without reports of successful regression tests on more platforms I'm not sure we can do that. I know that at least some of those listed below are the active development platforms for some contributors, so those are probably covered but I need confirmation. So, if you have a platform you have tested or plan to have tested in the next few days please speak up. Now. Or at least Soon :) Here are the ones on the "currently supported" list (let me know if you have something running on another platform. Any Ultrix people out there still?): _ AIX 4.1.x-4.2 _ BSDi _ FreeBSD 2.2.x-3.x _ NetBSD 1.3 _ NetBSD 1.3 NS32532 _ NetBSD 1.3 Sparc _ NetBSD 1.3 VAX _ DGUX 5.4R4.11 m88k _ HPUX 10.20 _ IRIX 6.x _ Digital 4.0 _ linux 2.0.x Alpha x linux 2.0.x x86 _ linux 2.0.x Sparc x mklinux PPC750 _ SCO _ Solaris x86 _ Solaris 2.5.1-2.6 x86 _ SunOS 4.1.4 Sparc x SVR4 MIPS _ SVR4 4.4 m88k x Unixware x86 x Windows NT The porting info goes into the Admin Guide in the docs. I plan to freeze that one last, a few days before release to give Bruce et al a chance to polish the installation and release notes. The other docs will need to freeze earlier to give me a chance to generate hardcopy for v6.4. So the freeze schedule will be (again assuming a Nov 1 release, and I'm probably not giving myself enough time): Oct 26: freeze Programmer's Guide and Developer's Guide Oct 27: freeze User's Guide and reference pages Oct 28: freeze Admin Guide Oct 29-30: finish hardcopy, generate html I will be out of town Oct 31-Nov 1, so need to finish a day or two early. As it is, I should have frozen some docs by now to get this stuff done. So, if you have anything else to contribute or update for docs, SEND IT IN NOW. Or at least let me know it is coming soon. Or it will have to wait for v6.5... TIA - Tom -
Re: [DOCS] Last call?
Bruce Momjian <maillist@candle.pha.pa.us> — 1998-10-25T05:17:54Z
> Here are the ones on the "currently supported" list (let me know if you > have something running on another platform. Any Ultrix people out there > still?): Change: > _ BSDi to > _ BSDI 3.x and 4.0 Also, the Windows NT item is of much interest. Can we report this as working, and have a binary of 6.4 built at the time of the 6.4 release, November 1? (I am CC'ing the NT person.) -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
-
Re: [DOCS] Last call?
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-10-25T14:21:19Z
> Change: > > _ BSDi > to > > _ BSDI 3.x and 4.0 The underscores meant that I don't know if the platform has been regression tested yet. Exes meant I did. I was assuming that you had already done BSDI (isn't that you're development platform?) and was hoping to get a report from you saying to put an "x" for that one. So the only platforms I've marked as being confirmed are NT, Unixware, SVR4, mklinux, and linux. But I know there are others which are already working, I'm just not certain exactly which ones... - Tom -
Re: [HACKERS] Re: [DOCS] Last call?
Terry Mackintosh <terry@terrym.com> — 1998-10-25T15:32:51Z
Hi Tom and all I did not know what the '_' and 'x' meant the first time, as I recall the one for 'Linux ix86' had an '_', or unknown, I can do this for you, should I grab the Bata2 or the latest snapshot? On Sun, 25 Oct 1998, Thomas G. Lockhart wrote: > > Change: > > > _ BSDi > > to > > > _ BSDI 3.x and 4.0 > > The underscores meant that I don't know if the platform has been > regression tested yet. Exes meant I did. I was assuming that you had > already done BSDI (isn't that you're development platform?) and was > hoping to get a report from you saying to put an "x" for that one. > > So the only platforms I've marked as being confirmed are NT, Unixware, > SVR4, mklinux, and linux. But I know there are others which are already > working, I'm just not certain exactly which ones... > > - Tom > Terry Mackintosh <terry@terrym.com> http://www.terrym.com sysadmin/owner Please! No MIME encoded or HTML mail, unless needed. Proudly powered by R H Linux 4.2, Apache 1.3, PHP 3, PostgreSQL 6.3 ------------------------------------------------------------------- Success Is A Choice ... book by Rick Patino, get it, read it!
-
Re: [HACKERS] Re: [DOCS] Last call?
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-10-25T16:09:57Z
> I did not know what the '_' and 'x' meant the first time, as I recall > the one for 'Linux ix86' had an '_', or unknown Thanks Terry, but I've already got that one done (it's my development platform). The Linux Alpha and Sparc need testing, which is probably what you remember seeing... - Tom -
Re: [DOCS] Last call?
Bruce Momjian <maillist@candle.pha.pa.us> — 1998-10-25T16:44:37Z
> > Change: > > > _ BSDi > > to > > > _ BSDI 3.x and 4.0 > > The underscores meant that I don't know if the platform has been > regression tested yet. Exes meant I did. I was assuming that you had > already done BSDI (isn't that you're development platform?) and was > hoping to get a report from you saying to put an "x" for that one. > > So the only platforms I've marked as being confirmed are NT, Unixware, > SVR4, mklinux, and linux. But I know there are others which are already > working, I'm just not certain exactly which ones... Oh, sorry. Put an X for BSDI. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
-
Re: Last call?
Brook Milligan <brook@trillium.nmsu.edu> — 1998-10-25T17:29:51Z
Here are the ones on the "currently supported" list (let me know if you have something running on another platform. Any Ultrix people out there still?): x NetBSD 1.3.2/i386 I'm running on NetBSD 1.3.2/i386 and as of yesterday the regressions all passed. I'm trying to redo them every few days to make sure nothing creeps in so this should be a supported platform. Cheers, Brook
-
Re: Last call?
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-10-25T17:33:54Z
> x NetBSD 1.3.2/i386 > I'm running on NetBSD 1.3.2/i386 and as of yesterday the regressions > all passed. I'm trying to redo them every few days to make sure > nothing creeps in so this should be a supported platform. This is exactly what makes it a supported platform :) - Tom -
Re: [HACKERS] Re: [DOCS] Last call?
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-10-25T18:07:59Z
> > 'Linux ix86' had an '_', or unknown > Thanks Terry, but I've already got that one done But Oliver was asking about glibc2 vs libc5. Do you happen to have a glibc machine (RH 5.x?) available? If so we could use a direct report of success since I'm still running RH4.2/libc5 for development... - Tom -
RE: [HACKERS] Re: [DOCS] Last call?
Taral <taral@mail.utexas.edu> — 1998-10-25T18:15:15Z
I compiled it on RH 5.1... no problems. Taral > -----Original Message----- > From: owner-pgsql-hackers@postgreSQL.org > [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Thomas G. > Lockhart > Sent: Sunday, October 25, 1998 12:08 PM > To: Terry Mackintosh; PostgreSQL-development > Subject: Re: [HACKERS] Re: [DOCS] Last call? > > > > > 'Linux ix86' had an '_', or unknown > > Thanks Terry, but I've already got that one done > > But Oliver was asking about glibc2 vs libc5. Do you happen to have a > glibc machine (RH 5.x?) available? If so we could use a direct report of > success since I'm still running RH4.2/libc5 for development... > > - Tom >
-
Re: [HACKERS] Re: [DOCS] Last call?
Egon Schmid <eschmid@stuttgart.netsurf.de> — 1998-10-25T18:19:39Z
I'm sure Oliver runs a libc6 system. He is one of the debian core developers. -Egon On Sun, 25 Oct 1998, Thomas G. Lockhart wrote: > > > 'Linux ix86' had an '_', or unknown > > Thanks Terry, but I've already got that one done > > But Oliver was asking about glibc2 vs libc5. Do you happen to have a > glibc machine (RH 5.x?) available? If so we could use a direct report of > success since I'm still running RH4.2/libc5 for development... > > - Tom > >
-
Re: [HACKERS] Re: [DOCS] Last call?
Terry Mackintosh <terry@terrym.com> — 1998-10-25T18:26:45Z
Hi Tom Nope, RH4.2/libc5, same as you. Still waiting for the dust to settle on the glibc thing:) On Sun, 25 Oct 1998, Thomas G. Lockhart wrote: > > > 'Linux ix86' had an '_', or unknown > > Thanks Terry, but I've already got that one done > > But Oliver was asking about glibc2 vs libc5. Do you happen to have a > glibc machine (RH 5.x?) available? If so we could use a direct report of > success since I'm still running RH4.2/libc5 for development... > > - Tom Terry Mackintosh <terry@terrym.com> http://www.terrym.com sysadmin/owner Please! No MIME encoded or HTML mail, unless needed. Proudly powered by R H Linux 4.2, Apache 1.3, PHP 3, PostgreSQL 6.3 ------------------------------------------------------------------- Success Is A Choice ... book by Rick Patino, get it, read it!
-
Re: [HACKERS] Re: [DOCS] Last call?
Egon Schmid <eschmid@stuttgart.netsurf.de> — 1998-10-25T18:26:51Z
I cannot believe, RH4.2 isn't a glibc2 system. -Egon On Sun, 25 Oct 1998, Terry Mackintosh wrote: > Hi Tom > > Nope, RH4.2/libc5, same as you. > Still waiting for the dust to settle on the glibc thing:) > > On Sun, 25 Oct 1998, Thomas G. Lockhart wrote: > > > > > 'Linux ix86' had an '_', or unknown > > > Thanks Terry, but I've already got that one done > > > > But Oliver was asking about glibc2 vs libc5. Do you happen to have a > > glibc machine (RH 5.x?) available? If so we could use a direct report of > > success since I'm still running RH4.2/libc5 for development... > > > > - Tom > > > Terry Mackintosh <terry@terrym.com> http://www.terrym.com > sysadmin/owner Please! No MIME encoded or HTML mail, unless needed. > > Proudly powered by R H Linux 4.2, Apache 1.3, PHP 3, PostgreSQL 6.3 > ------------------------------------------------------------------- > Success Is A Choice ... book by Rick Patino, get it, read it! > > >
-
Re: [HACKERS] Re: [DOCS] Last call?
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-10-25T22:58:12Z
> I compiled it on RH 5.1... no problems. OK. Just to be unambiguous, I'd prefer a statement that includes "... and passed all regression tests". It did, right? - Tom -
RE: [HACKERS] Re: [DOCS] Last call?
Taral <taral@mail.utexas.edu> — 1998-10-25T23:29:22Z
Err.. umm... Updated 10/25 17:05 CST. The following tests fail on my system (RH 5.1 - glibc): int2, int4: Different error format (Math result not representable is now Numerical result out of range) float8: Weird... one query that was supposed to fail returned a bunch of NaNs, another failed when it wasn't supposed to with an out of range error. geometry: The results are only approximately right... but only in the first sig. figure :( datetime: CDT/CST thing sanity_check: **backend aborts** random: Fails because it returns a value outside the 80-120 range misc: Rows out of order I'm afraid this one can't go as 'supported'. Sorry. Taral > -----Original Message----- > From: owner-pgsql-hackers@postgreSQL.org > [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Thomas G. > Lockhart > Sent: Sunday, October 25, 1998 4:58 PM > To: Taral > Cc: Terry Mackintosh; PostgreSQL-development > Subject: Re: [HACKERS] Re: [DOCS] Last call? > > > > I compiled it on RH 5.1... no problems. > > OK. Just to be unambiguous, I'd prefer a statement that includes "... > and passed all regression tests". It did, right? > > - Tom >
-
RE: [HACKERS] Re: [DOCS] Last call?
Taral <taral@mail.utexas.edu> — 1998-10-25T23:37:15Z
> sanity_check: **backend aborts** > random: Fails because it returns a value outside the 80-120 range > misc: Rows out of order All passed when I reinitialized the db. Taral
-
Re: [HACKERS] Re: [DOCS] Last call?
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-10-26T00:42:40Z
> > sanity_check: **backend aborts** > > random: Fails because it returns a value outside the 80-120 range > > misc: Rows out of order > All passed when I reinitialized the db. OK, good. btw, the random test will still occasionally fail, since a two or three sigma result will have values outside the 80-120 range. But rerunning should get something within range, usually. - Tom -
RE: [HACKERS] Re: [DOCS] Last call?
Taral <taral@mail.utexas.edu> — 1998-10-26T01:17:28Z
> > > sanity_check: **backend aborts** > > > random: Fails because it returns a value outside the 80-120 range > > > misc: Rows out of order Note that int2,int4,float8,geometry are still failing... Why is geometry sooo far out? Taral
-
Re: [HACKERS] Last call?
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-10-26T15:12:40Z
I still need reports on: > _ AIX 4.1.x-4.2 > _ FreeBSD 2.2.x-3.x > _ NetBSD 1.3 NS32532 > _ NetBSD 1.3 Sparc > _ NetBSD 1.3 VAX > _ DGUX 5.4R4.11 (m88k or ? we need a new maintainer) > _ IRIX 6.x (Andrew, are you available?) > _ Digital 4.0 > _ linux 2.0.x Alpha > _ SCO (Billy, can you confirm success now?) > _ Solaris x86 > _ Solaris 2.5.1-2.6 Sparc > _ SunOS 4.1.4 Sparc > _ SVR4 4.4 m88k (I have v6.3 "confirmed with patching". better now?) > x Windows NT Tatsuo, is your usual stable of machines available for reporting? It would be nice to get confirmation with that big-endian/little-endian mix. How should I list WindowsNT? I have "mostly working, check web site for patches" at the moment, but I don't know if we have more info available now. I would welcome confirming reports on other platforms too. - Tom -
Re: [HACKERS] Last call?
Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu> — 1998-10-26T15:45:12Z
On Mon, 26 Oct 1998, Thomas G. Lockhart wrote: > I still need reports on: > > > _ linux 2.0.x Alpha I have gotten it to compile successfully again (fixes to our old friend S_LOCK) and I should have a patch out in a few days (big test {at college} on Wedesday, so it will later in the week). Most of the regression tests are working, except the datetime ones (no, sorry, can't blame daylight savings this time, that is unless the year is all of a sudden 2136. :( ). I doubt I will have that working by Nov 2, as I have been trying for a few months with out success to find these bugs. I will post the patch and more detail on the datetime problems by the end of this week to the pgsql-{ports,hacker,patch} mailing lists. TTYAL. ---------------------------------------------------------------------------- | "For to me to live is Christ, and to die is gain." | | --- Philippians 1:21 (KJV) | ---------------------------------------------------------------------------- | Ryan Kirkpatrick | Boulder, Colorado | rkirkpat@nag.cs.colorado.edu | ---------------------------------------------------------------------------- | http://www-ugrad.cs.colorado.edu/~rkirkpat/ | ---------------------------------------------------------------------------- -
Re: [HACKERS] Last call?
Marc G. Fournier <scrappy@hub.org> — 1998-10-27T03:08:15Z
On Mon, 26 Oct 1998, Thomas G. Lockhart wrote: > I still need reports on: > > > _ AIX 4.1.x-4.2 Duane out there was going to do this one for us, assuming that he still had access to that machine... > > _ FreeBSD 2.2.x-3.x Building now... > > _ NetBSD 1.3 NS32532 > > _ NetBSD 1.3 Sparc > > _ NetBSD 1.3 VAX > > _ DGUX 5.4R4.11 (m88k or ? we need a new maintainer) > > _ IRIX 6.x (Andrew, are you available?) > > _ Digital 4.0 > > _ linux 2.0.x Alpha > > _ SCO (Billy, can you confirm success now?) > > _ Solaris x86 > > _ Solaris 2.5.1-2.6 Sparc Will rebuild and regress test both the x86/Sparc platforms for 2.6 during the day tomorrow... Marc G. Fournier Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org -
Re: [HACKERS] Last call?
Douglas W Babst <dbabst@tcgcs.com> — 1998-10-27T06:10:39Z
On Sun, 25 Oct 1998, Thomas G. Lockhart wrote: > _ linux 2.0.x Alpha Neither 6.4B2 nor the oct26 snapshot compile on my RH 5.0 Alpha Linux (2.0.30) computer. I don't have much time to work on it, but I can provide the gmake.log and access to the machine if it would help. Doug ------------------------------------------------------------------------ My views are actually owned by a small, strange, orange man from the planet zikalikzutorabibian who can only communicate by making cryptic oblong symbols in warm food. If you have problems with my views, please take them up with him. ------------------------------------------------------------------------ For Hire: Will write code/manage networks for obscene amounts of money. ------------------------------------------------------------------------ Doug Babst - Owner | P.O. Box 103 | (402) 463-3426 - Voice TCG Computer Services | Hastings, NE 68901 | (402) 463-1754 - Fax http://www.tcgcs.com | http://www.babst.org/~dbabst/resume
-
Re: Last call?
Tom Ivar Helbekkmo <tih@hamartun.priv.no> — 1998-10-27T19:41:34Z
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes: > _ NetBSD 1.3 We normally write NetBSD/i386 1.3 (or 1.3.2, the latest version). > _ NetBSD 1.3 Sparc I just ran the regression tests on NetBSD/sparc 1.3H, which is an interim (current) version between 1.3.2 and 1.4. All tests pass except float8, which generates the following extra error messages: barsoom:tih> diff -c expected/float8-NetBSD.out results/float8.out *** expected/float8-NetBSD.out Thu Oct 8 18:12:14 1998 --- results/float8.out Tue Oct 27 20:07:18 1998 *************** *** 213,219 **** --- 213,221 ---- QUERY: INSERT INTO FLOAT8_TBL(f1) VALUES ('-10e400'); ERROR: Bad float8 input format '-10e400' QUERY: INSERT INTO FLOAT8_TBL(f1) VALUES ('10e-400'); + ERROR: Bad float8 input format '10e-400' QUERY: INSERT INTO FLOAT8_TBL(f1) VALUES ('-10e-400'); + ERROR: Bad float8 input format '-10e-400' QUERY: DELETE FROM FLOAT8_TBL; QUERY: INSERT INTO FLOAT8_TBL(f1) VALUES ('0.0'); QUERY: INSERT INTO FLOAT8_TBL(f1) VALUES ('-34.84'); barsoom:tih> > _ NetBSD 1.3 VAX Unfortunately, I can't run the regression tests under NetBSD/vax, as my old VAX is having stability problems at the moment. Things were fine with 6.3, though, and since NetBSD/i386 and NetBSD/sparc both like 6.4BETA, it's extremely probable that NetBSD/vax will as well. -tih -- Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier" -
Re: Last call?
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-10-27T21:16:45Z
> I just ran the regression tests on NetBSD/sparc 1.3H, which is an > interim (current) version between 1.3.2 and 1.4. All tests pass > except float8, which generates the following extra error messages: OK, looks good... - Thomas -
Re: [HACKERS] Last call?
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-10-28T17:31:33Z
Would like to get reports running the Postgres v6.4beta on these remaining platforms in the next couple of days: > _ DGUX (needs a new maintainer) > _ IRIX 6.x (Andrew?) > _ Digital 4.0 > _ linux 2.0.x Alpha (needs some work; someone have patches?) > _ NetBSD 1.3 VAX (Tom H's machine is down; anyone else?) > _ SCO (Billy, have you had any luck with this?) > _ Solaris x86 (Marc?) > _ SunOS 4.1.4 Sparc (Tatsuo?) > _ SVR4 4.4 m88k TIA - Tom -
Re: [HACKERS] Last call?
Marc G. Fournier <scrappy@hub.org> — 1998-10-28T19:26:22Z
On Wed, 28 Oct 1998, Thomas G. Lockhart wrote: > Would like to get reports running the Postgres v6.4beta on these > remaining platforms in the next couple of days: > > > _ DGUX (needs a new maintainer) > > _ IRIX 6.x (Andrew?) > > _ Digital 4.0 > > _ linux 2.0.x Alpha (needs some work; someone have patches?) > > _ NetBSD 1.3 VAX (Tom H's machine is down; anyone else?) > > _ SCO (Billy, have you had any luck with this?) > > _ Solaris x86 (Marc?) sorry...yes...beautiful build and regression test... Marc G. Fournier Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org -
Re: [HACKERS] Last call?
Frank Ridderbusch <ridderbusch.pad@sni.de> — 1998-10-28T20:28:23Z
Hi, I just compiled beta4 on Solaris 7 (also known as 2.7) using egcs 1.1. Everything went very smoothly and regression tests were passed. Thomas G. Lockhart writes: > Would like to get reports running the Postgres v6.4beta on these > remaining platforms in the next couple of days: > > > _ DGUX (needs a new maintainer) > > _ IRIX 6.x (Andrew?) > > _ Digital 4.0 > > _ linux 2.0.x Alpha (needs some work; someone have patches?) > > _ NetBSD 1.3 VAX (Tom H's machine is down; anyone else?) > > _ SCO (Billy, have you had any luck with this?) > > _ Solaris x86 (Marc?) > > _ SunOS 4.1.4 Sparc (Tatsuo?) > > _ SVR4 4.4 m88k > > TIA > > - Tom > > MfG/Regards -- /==== Siemens AG / Ridderbusch / , ICP CS XS QM4 / /./ Heinz Nixdorf Ring /=== /,== ,===/ /,==, // 33106 Paderborn, Germany / // / / // / / \ Tel.: (49) 5251-8-15211 / / `==/\ / / / \ Email: ridderbusch.pad@sni.de Since I have taken all the Gates out of my computer, it finally works!! -
Re: [HACKERS] Last call?
Frank Ridderbusch <ridderbusch.pad@sni.de> — 1998-10-28T22:07:26Z
Hi, here are my results for building beta3 on MIPS SVR4. The regression tests are as good as they can be. There are a couple of changes necessary, which I've described in a little README, which I've appended below. Thomas G. Lockhart writes: > Would like to get reports running the Postgres v6.4beta on these > remaining platforms in the next couple of days: > > > _ DGUX (needs a new maintainer) > > _ IRIX 6.x (Andrew?) > > _ Digital 4.0 > > _ linux 2.0.x Alpha (needs some work; someone have patches?) > > _ NetBSD 1.3 VAX (Tom H's machine is down; anyone else?) > > _ SCO (Billy, have you had any luck with this?) > > _ Solaris x86 (Marc?) > > _ SunOS 4.1.4 Sparc (Tatsuo?) > > _ SVR4 4.4 m88k > > TIA > > - Tom > > Readme for building Postgresql 6.4 on Siemens RM Systems ======================================================== 1. Overview =========== This README describes the necessary steps to build the Postgresql database system on SINIX/Reliant UNIX. Reliant UNIX (previously called SINIX) is a SVR4 variant, which runs on Siemens RM400/RM600 servers. These servers use the MIPS R3000/R4400/R10000 family of processors. The following description is based on SINIX-P 5.42A10 running on a RM600-xx with 4 processors (both the machine and the operating system are pretty old, therefore your milage my vary on newer os versions). 2. Building =========== You can not use the GCC version for this platform (2.7.2.3 from ftp://ftp.mch.sni.de/sni/mr/pd/gnu). But you have to install it anyway, since the GCC cpp must be used during an intermediate step, when header files are produced. You have to use the Siemens C-compilations environment (I used CDS 1.1A00) for the actual compilation process. Reason is, that the postgresql backend is build with several 'ld -R' passes. The linker expects the symbols to be sorted in ELF object file, which this GCC port apparently does not do. Apart from flex, bison, you also need GNU awk. Awk is used in genbki.sh and the expression used in the shell script appears to be too complex for the system awk. Therefore install GNU awk and make sure, that this version is found before the system awk (ordering of PATH variable). I configured with ./configure --with-template=svr4 \ --prefix=/home/tools/pgsql-6.4 \ --with-includes=/home/tools/include \ --with-libraries=/home/tools/lib You might be tempted to run configure with the additional argument --with-CC='cc -W0' to activate the native C-compiler. However, when I did this, compilation stopped with this error message. cc -W0 -I../../../include -I../../../backend -I/home/tools/include -I../.. -c istrat.c -o istrat.o istrat.c 496: [error]: 2324 Undefined: 'F_OIDEQ' 2086 c1: errors: 1, warnings: 15 After that the following changes are necessary (the changes are explicitly listed, since the changes might not be compatible with other SVR4 platforms, which use the same files): o Add -lsocket before -lnsl in Makefile.global o edit Makefile.port and extend LDFLAGS with -lmutex, so that it like this LDFLAGS+= -lmutex -lc /usr/ucblib/libucb.a -LD-Blargedynsym And add a line to enable the native C-compiler CUSTOM_CC = cc -W0 -O2 o configure does not correctly reqognize the number of arguments for gettimeofday. Therefore 'undef' HAVE_GETTIMEOFDAY_2_ARGS. o These two patches are necessary to fix a compiler bug. In backend/utils/adt/date.c around line 179 change EncodeTimeSpan(tm, 0, DateStyle, buf); to EncodeTimeSpan(tm, 0.0, DateStyle, buf); and in backend/utils/adt/dt.c around line 349 and 359 change tm2datetime(&tt, 0, NULL, &dt); to tm2datetime(&tt, 0.0, NULL, &dt); Patches in diff -u form are appended below. o In src/backend/port/Makefile remove the 'strcasecmp.o'. 3. Restrictions =============== Connecting to the backend via unix domain sockets does not work and the 64bit data type is not supported. Otherwise the regression test shows no remarkable differences. 4. Patches ========== Please remove the first blank column, if you apply the patches. diff -u src/backend/utils/adt/date.c~ src/backend/utils/adt/date.c --- src/backend/utils/adt/date.c~ Wed Oct 28 20:43:42 1998 +++ src/backend/utils/adt/date.c Wed Oct 28 20:43:42 1998 @@ -176,7 +176,7 @@ else { reltime2tm(time, tm); - EncodeTimeSpan(tm, 0, DateStyle, buf); + EncodeTimeSpan(tm, 0.0, DateStyle, buf); } result = palloc(strlen(buf) + 1); diff -u src/backend/utils/adt/dt.c~ src/backend/utils/adt/dt.c --- src/backend/utils/adt/dt.c~ Wed Oct 28 20:45:42 1998 +++ src/backend/utils/adt/dt.c Wed Oct 28 20:45:42 1998 @@ -346,7 +346,7 @@ if (DATETIME_IS_CURRENT(dt)) { GetCurrentTime(&tt); - tm2datetime(&tt, 0, NULL, &dt); + tm2datetime(&tt, 0.0, NULL, &dt); dt = dt2local(dt, -CTimeZone); #ifdef DATEDEBUG @@ -356,7 +356,7 @@ else { /* if (DATETIME_IS_EPOCH(dt1)) */ GetEpochTime(&tt); - tm2datetime(&tt, 0, NULL, &dt); + tm2datetime(&tt, 0.0, NULL, &dt); #ifdef DATEDEBUG printf("SetDateTime- epoch time is %f\n", dt); #endif MfG/Regards -- /==== Siemens AG / Ridderbusch / , ICP CS XS QM4 / /./ Heinz Nixdorf Ring /=== /,== ,===/ /,==, // 33106 Paderborn, Germany / // / / // / / \ Tel.: (49) 5251-8-15211 / / `==/\ / / / \ Email: ridderbusch.pad@sni.de Since I have taken all the Gates out of my computer, it finally works!! -
Re: [HACKERS] Last call?
Tom Lane <tgl@sss.pgh.pa.us> — 1998-10-29T15:41:06Z
Frank Ridderbusch <ridderbusch.pad@sni.de> writes: > You might be tempted to run configure with the additional argument > --with-CC='cc -W0' to activate the native C-compiler. However, when I > did this, compilation stopped with this error message. > cc -W0 -I../../../include -I../../../backend -I/home/tools/include > -I../.. -c istrat.c -o istrat.o > istrat.c 496: [error]: 2324 Undefined: 'F_OIDEQ' > 2086 c1: errors: 1, warnings: 15 I believe that is the first symptom you'd see when configure chooses a cpp-from-stdin technique that doesn't actually work. We went around on that a couple of times in the past three or four days, and eventually changed the shell scripts so that they don't need cpp from stdin. So, with the current sources (or BETA4 when it's out) it might work to specify --with-CC; would you try it and let us know? This cpp mistake may also be the root of the apparent need to have gcc installed --- please check and see if that's still true. > After that the following changes are necessary (the changes are > explicitly listed, since the changes might not be compatible with > other SVR4 platforms, which use the same files): I think all of these config changes could be handled with a special Makefile.port for Siemens ... is that worth adding? > o configure does not correctly reqognize the number of arguments > for gettimeofday. Therefore 'undef' HAVE_GETTIMEOFDAY_2_ARGS. This should be fixed; can you look into it and see why configure is getting the wrong answer? Look at configure.in --- there is a small test program that the script tries to compile, and if there is no compile error then it assumes gettimeofday has two args. A first guess is that gettimeofday is not declared in sys/time.h on your machine. If we add wherever it is declared then perhaps the test will work. > o In src/backend/port/Makefile remove the 'strcasecmp.o'. Likewise, this should be fixable by improving configure's test to see whether the system has strcasecmp. regards, tom lane
-
Re: [HACKERS] Last call?
Frank Ridderbusch <ridderbusch.pad@sni.de> — 1998-10-29T21:41:25Z
Tom Lane writes: > Frank Ridderbusch <ridderbusch.pad@sni.de> writes: > > You might be tempted to run configure with the additional argument .... > > This cpp mistake may also be the root of the apparent need to have gcc > installed --- please check and see if that's still true. Once beta4 is ready I will definitely rebuild. > > After that the following changes are necessary (the changes are > > explicitly listed, since the changes might not be compatible with > > other SVR4 platforms, which use the same files): > > I think all of these config changes could be handled with a special > Makefile.port for Siemens ... is that worth adding? Well I'd say, this short before your expected release date, I wouldn't want to shake things up by adding another special Makefile.port with the possible iterations to get it right. And although I would like it to be otherwise, Siemens RM system have only a great market share in Germany. I think, if Pyramid Nile users and, I think NEC has/had a MIPS based SVR4, would speak up, then you should add a special MIPS based Makefile.port > > o configure does not correctly reqognize the number of arguments > > for gettimeofday. Therefore 'undef' HAVE_GETTIMEOFDAY_2_ARGS. > > This should be fixed; can you look into it and see why configure > is getting the wrong answer? Look at configure.in --- there is a > small test program that the script tries to compile, and if there > is no compile error then it assumes gettimeofday has two args. > A first guess is that gettimeofday is not declared in sys/time.h > on your machine. If we add wherever it is declared then perhaps > the test will work. As I say, my system is pretty old (still R3000) and ths os is just as old. And indeed the missing prototype in sys/time.h is the cause. Later OS version have it defined. Therefore I really see no need for changes here. > > o In src/backend/port/Makefile remove the 'strcasecmp.o'. > > Likewise, this should be fixable by improving configure's test > to see whether the system has strcasecmp. > > regards, tom lane Well, this problem is originally caused by the need to link against /usr/ucblib/libucb.a. Without libucb.a, I'm getting three undefined symbols strncasecmp commands/SUBSYS.o alloca bootstrap/SUBSYS.o strcasecmp commands/SUBSYS.o alloca is ok (GCC users have it build in). But strncasecmp and strcasecmp are defined in the same archive member in libucb.a. Therefore I get multiple defines if I link with strcasecmp.o from pgsql. Come to think of it, shouldn't configure check also for strncasecmp if it checks for strcasecmp? But apparently, since no one complains, it appears, that all other platforms do have strncasecmp and shouldn't also need strcasecmp. I general, I would say, leave the configure process as it is, once beta4 is available. I'm quite happy as it stand, with all the shortcommings of my dated hard- and software. Regards, Frank