Обсуждение: Postgres 7 on IRIX
Hi there. i am trying to install postgres on IRIX 6.5 . I
downloaded the tarball, configured it with
./configure --prefix=/usr/local/pgsql --with-perl
and then, when i tried to compile it:
ahernand@hafnio 215 % gmake
gmake -C utils all
gmake[1]: Entering directory
`/home/ahernand/programas/postgresql-7.0/src/utils'
/usr/freeware/bin/gcc -I../include -I../backend -U_NO_XOPEN4 -woff
1164,1171,1185,1195,1552 -Wl,-woff,15 -W l,-woff,84 -c -o version.o
version.c
gcc: cannot specify -o with -c or -S and multiple compilations
gmake[1]: *** [version.o] Error 1
gmake[1]: Leaving directory
`/home/ahernand/programas/postgresql-7.0/src/utils'
gmake: *** [all] Error 2
i know its the compiler... i have gcc-2.95.2 from freeware.sgi.com, so
dont know what could be wrong...
i tried to quit that "-o blabla.o" that appears in the compilation line,
but i couldnt find which file to change...
Am i missing something?
Does anybody had this problem?
Help will be apreciated...
Thanks in advance...
Alfredo
> i know its the compiler... i have gcc-2.95.2 from freeware.sgi.com, so
> dont know what could be wrong...
I've *never* worked on an SGI machine, but it appears to me that you are
getting the compiler flags for the standard SGI compiler mixed in with
the call to gcc. Did you run ./configure with any flags? Are you sure
that it correctly deduced the configuration of your system? Try posting
the config.* output files so we can see what happened...
- Thomas
It's the mips pro C compiler (courtesy Irix). I've been battling with it for 2 weeks now. Since the machines are new I've not been allowed to experiment with the O2s. My workaround is to get a PC and put Linux on it. Out here it's working great and it's taking everyone by storm (they want to put Linux on all machines now, even on the SUN/UltraSparc!). Probably removing mips pro might help, but I've not tried it. I've spoken to the person at freeware@sgi.com and he will put up PostgreSQL-7.0 (not 7.0.2) this month at his site. HTH, Indraneel On Tue, 15 Aug 2000, Hernandez Alvarez Alfredo wrote: > > Hi there. i am trying to install postgres on IRIX 6.5 . I > downloaded the tarball, configured it with > ./configure --prefix=/usr/local/pgsql --with-perl > > and then, when i tried to compile it: > > ahernand@hafnio 215 % gmake > gmake -C utils all > gmake[1]: Entering directory > `/home/ahernand/programas/postgresql-7.0/src/utils' > /usr/freeware/bin/gcc -I../include -I../backend -U_NO_XOPEN4 -woff > 1164,1171,1185,1195,1552 -Wl,-woff,15 -W l,-woff,84 -c -o version.o > version.c > gcc: cannot specify -o with -c or -S and multiple compilations > gmake[1]: *** [version.o] Error 1 > gmake[1]: Leaving directory > `/home/ahernand/programas/postgresql-7.0/src/utils' > gmake: *** [all] Error 2 > > i know its the compiler... i have gcc-2.95.2 from freeware.sgi.com, so > dont know what could be wrong... > i tried to quit that "-o blabla.o" that appears in the compilation line, > but i couldnt find which file to change... > > Am i missing something? > Does anybody had this problem? > > Help will be apreciated... > Thanks in advance... > > Alfredo > > > > > /************************************************************************. # Indraneel Majumdar ¡ E-mail: indraneel@123india.com # # Bioinformatics Unit (EMBNET node), ¡ URL: http://scorpius.iwarp.com # # Centre for DNA Fingerprinting and Diagnostics, # # Hyderabad, India - 500076 # `************************************************************************/
Thanks. I tried making a link from the cc to
/usr/freeware/bin/gcc... cant compile... I will try removing the mips
compiler...
On Thu, 17 Aug 2000, Indraneel Majumdar wrote:
> It's the mips pro C compiler (courtesy Irix). I've been battling with it
> for 2 weeks now. Since the machines are new I've not been allowed to
> experiment with the O2s. My workaround is to get a PC and put Linux on it.
> Out here it's working great and it's taking everyone by storm (they want
> to put Linux on all machines now, even on the SUN/UltraSparc!). Probably
Personally I prefer working with Linux too!
> removing mips pro might help, but I've not tried it. I've spoken to the
> person at freeware@sgi.com and he will put up PostgreSQL-7.0 (not 7.0.2)
> this month at his site.
>
Hope that tardist comes soon...
Greetings
Alfredo
> HTH, Indraneel
>
> On Tue, 15 Aug 2000, Hernandez Alvarez Alfredo wrote:
>
> >
> > ahernand@hafnio 215 % gmake
> > gmake -C utils all
> > gmake[1]: Entering directory
> > `/home/ahernand/programas/postgresql-7.0/src/utils'
> > /usr/freeware/bin/gcc -I../include -I../backend -U_NO_XOPEN4 -woff
> > 1164,1171,1185,1195,1552 -Wl,-woff,15 -W l,-woff,84 -c -o version.o
> > version.c
> > gcc: cannot specify -o with -c or -S and multiple compilations
> .........
Hernandez Alvarez Alfredo writes:
> Thanks. I tried making a link from the cc to
> /usr/freeware/bin/gcc... cant compile... I will try removing the mips
> compiler...
That won't help. Your problem is that configure has decided to use
the MIPSpro compiler and set the CFLAGS for that. gcc doesn't grok
them.
Try making another template file, e.g. template/irix6_gcc. Merge
template/irix5 and one or more of the _gcc templates. Then configure
with
./configure --with-template=irix6_gcc
For what it's worth I've just been building PostgreSQL 7.0.2 on IRIX
6.5.5m with the native MIPSpro 7.3 compilers. Both -n32 and -64
versions have been tried. -o32 is obsolescent and was not considered.
The -64 version gives 34 warnings about 64-bit pointers being stored
in 32-bit integers. That makes whatever is built unsafe IMHO. How
well does PostgreSQL build on Alpha and other 64-bit systems?
One worrying problem is that when optimized -O2 both -n32 and -64
versions failed regression tests such as oidjoins. An example is
SELECT oid, pg_aggregate.aggtransfn1
FROM pg_aggregate
WHERE pg_aggregate.aggtransfn1 != 0 AND
NOT EXISTS(SELECT * FROM pg_proc AS t1 WHERE t1.oid =
pg_aggregate.aggtransfn1);
ERROR: getattproperties: no attribute tuple 1255 -2
I have not investigated further. Compiling without optimization seems
okay.
So the current state of affairs is that it is built -n32 -g and passes
the regression tests. To do this I've done the following.
1) Created a new template/irix6 containing
This is picked up by "./configure --with-template=irix6" though
presumably the configure script could be updated.
Note that the LD entry gets overridden somewhere later. My kludge for
linker errors such as
ld -r -o SUBSYS.o heaptuple.o indextuple.o indexvalid.o printtup.o
scankey.o tupdesc.o
ld: FATAL 12 : Expecting o32 objects: heaptuple.o is n32.
is to export the environment variable "SGI_ABI=-n32".
2) After running configure, edit config.h to get around the accept bug
http://www.postgresql.org/mhonarc/pgsql-ports/2000-05/msg00042.html
3) Edit tests/regress/resultmap to add entries for IRIX.
Note that the geometry test still fails. I've eyeballed the
differences to be just due to FP precision but it needs to be checked
thoroughly.
(I will copy item (3) to pgsql-patches.)
--
Pete Forman -./\.- Disclaimer: This post is originated
Western Geophysical -./\.- by myself and does not represent
pete.forman@westgeo.com -./\.- the opinion of Baker Hughes or
http://www.crosswinds.net/~petef -./\.- its divisions.
Вложения
Pete Forman wrote:
>
> Hernandez Alvarez Alfredo writes:
> > Thanks. I tried making a link from the cc to
> > /usr/freeware/bin/gcc... cant compile... I will try removing the mips
> > compiler...
>
> That won't help. Your problem is that configure has decided to use
> the MIPSpro compiler and set the CFLAGS for that. gcc doesn't grok
> them.
>
> Try making another template file, e.g. template/irix6_gcc. Merge
> template/irix5 and one or more of the _gcc templates. Then configure
> with
>
> ./configure --with-template=irix6_gcc
>
> For what it's worth I've just been building PostgreSQL 7.0.2 on IRIX
> 6.5.5m with the native MIPSpro 7.3 compilers. Both -n32 and -64
> versions have been tried. -o32 is obsolescent and was not considered.
> The -64 version gives 34 warnings about 64-bit pointers being stored
> in 32-bit integers. That makes whatever is built unsafe IMHO. How
> well does PostgreSQL build on Alpha and other 64-bit systems?
For 7.0.x, Alpha builds require patches, which would probably help you
also. Tom Lane has rewritten the function manager (fmgr) interface, and
these patches are not necessary in the current development tree. You
might want to try that since we are probably approaching the beta test
period.
> One worrying problem is that when optimized -O2 both -n32 and -64
> versions failed regression tests such as oidjoins...
> I have not investigated further. Compiling without optimization seems
> okay.
This is probably a symptom of the unpatched 64-bit build...
- Thomas
Any chance you can test our current PostgreSQL version and let us know what needs changing for Irix? I think it will work better now. Content-Description: message body text > Hernandez Alvarez Alfredo writes: > > Thanks. I tried making a link from the cc to > > /usr/freeware/bin/gcc... cant compile... I will try removing the mips > > compiler... > > That won't help. Your problem is that configure has decided to use > the MIPSpro compiler and set the CFLAGS for that. gcc doesn't grok > them. > > Try making another template file, e.g. template/irix6_gcc. Merge > template/irix5 and one or more of the _gcc templates. Then configure > with > > ./configure --with-template=irix6_gcc > > > For what it's worth I've just been building PostgreSQL 7.0.2 on IRIX > 6.5.5m with the native MIPSpro 7.3 compilers. Both -n32 and -64 > versions have been tried. -o32 is obsolescent and was not considered. > > The -64 version gives 34 warnings about 64-bit pointers being stored > in 32-bit integers. That makes whatever is built unsafe IMHO. How > well does PostgreSQL build on Alpha and other 64-bit systems? > > One worrying problem is that when optimized -O2 both -n32 and -64 > versions failed regression tests such as oidjoins. An example is > > SELECT oid, pg_aggregate.aggtransfn1 > FROM pg_aggregate > WHERE pg_aggregate.aggtransfn1 != 0 AND > NOT EXISTS(SELECT * FROM pg_proc AS t1 WHERE t1.oid = > pg_aggregate.aggtransfn1); > ERROR: getattproperties: no attribute tuple 1255 -2 > > I have not investigated further. Compiling without optimization seems > okay. > > > So the current state of affairs is that it is built -n32 -g and passes > the regression tests. To do this I've done the following. > > 1) Created a new template/irix6 containing Content-Description: Template for IRIX 6.5 [ Attachment, skipping... ] Content-Description: message body text > > This is picked up by "./configure --with-template=irix6" though > presumably the configure script could be updated. > > Note that the LD entry gets overridden somewhere later. My kludge for > linker errors such as > > ld -r -o SUBSYS.o heaptuple.o indextuple.o indexvalid.o printtup.o > scankey.o tupdesc.o > ld: FATAL 12 : Expecting o32 objects: heaptuple.o is n32. > > is to export the environment variable "SGI_ABI=-n32". > > > 2) After running configure, edit config.h to get around the accept bug > http://www.postgresql.org/mhonarc/pgsql-ports/2000-05/msg00042.html > > > 3) Edit tests/regress/resultmap to add entries for IRIX. > Content-Description: New resultmap entries for IRIX 6 [ Attachment, skipping... ] Content-Description: message body and .signature > > Note that the geometry test still fails. I've eyeballed the > differences to be just due to FP precision but it needs to be checked > thoroughly. > > (I will copy item (3) to pgsql-patches.) > > -- > Pete Forman -./\.- Disclaimer: This post is originated > Western Geophysical -./\.- by myself and does not represent > pete.forman@westgeo.com -./\.- the opinion of Baker Hughes or > http://www.crosswinds.net/~petef -./\.- its divisions. -- Bruce Momjian | http://candle.pha.pa.us pgman@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
Sorry, I wasn't clear. The snapshot on our ftp site is the one to test. Content-Description: message body text > Hernandez Alvarez Alfredo writes: > > Thanks. I tried making a link from the cc to > > /usr/freeware/bin/gcc... cant compile... I will try removing the mips > > compiler... > > That won't help. Your problem is that configure has decided to use > the MIPSpro compiler and set the CFLAGS for that. gcc doesn't grok > them. > > Try making another template file, e.g. template/irix6_gcc. Merge > template/irix5 and one or more of the _gcc templates. Then configure > with > > ./configure --with-template=irix6_gcc > > > For what it's worth I've just been building PostgreSQL 7.0.2 on IRIX > 6.5.5m with the native MIPSpro 7.3 compilers. Both -n32 and -64 > versions have been tried. -o32 is obsolescent and was not considered. > > The -64 version gives 34 warnings about 64-bit pointers being stored > in 32-bit integers. That makes whatever is built unsafe IMHO. How > well does PostgreSQL build on Alpha and other 64-bit systems? > > One worrying problem is that when optimized -O2 both -n32 and -64 > versions failed regression tests such as oidjoins. An example is > > SELECT oid, pg_aggregate.aggtransfn1 > FROM pg_aggregate > WHERE pg_aggregate.aggtransfn1 != 0 AND > NOT EXISTS(SELECT * FROM pg_proc AS t1 WHERE t1.oid = > pg_aggregate.aggtransfn1); > ERROR: getattproperties: no attribute tuple 1255 -2 > > I have not investigated further. Compiling without optimization seems > okay. > > > So the current state of affairs is that it is built -n32 -g and passes > the regression tests. To do this I've done the following. > > 1) Created a new template/irix6 containing Content-Description: Template for IRIX 6.5 [ Attachment, skipping... ] Content-Description: message body text > > This is picked up by "./configure --with-template=irix6" though > presumably the configure script could be updated. > > Note that the LD entry gets overridden somewhere later. My kludge for > linker errors such as > > ld -r -o SUBSYS.o heaptuple.o indextuple.o indexvalid.o printtup.o > scankey.o tupdesc.o > ld: FATAL 12 : Expecting o32 objects: heaptuple.o is n32. > > is to export the environment variable "SGI_ABI=-n32". > > > 2) After running configure, edit config.h to get around the accept bug > http://www.postgresql.org/mhonarc/pgsql-ports/2000-05/msg00042.html > > > 3) Edit tests/regress/resultmap to add entries for IRIX. > Content-Description: New resultmap entries for IRIX 6 [ Attachment, skipping... ] Content-Description: message body and .signature > > Note that the geometry test still fails. I've eyeballed the > differences to be just due to FP precision but it needs to be checked > thoroughly. > > (I will copy item (3) to pgsql-patches.) > > -- > Pete Forman -./\.- Disclaimer: This post is originated > Western Geophysical -./\.- by myself and does not represent > pete.forman@westgeo.com -./\.- the opinion of Baker Hughes or > http://www.crosswinds.net/~petef -./\.- its divisions. -- Bruce Momjian | http://candle.pha.pa.us pgman@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
Bruce Momjian writes: > Any chance you can test our current PostgreSQL version and let us > know what needs changing for Irix? I think it will work better > now. I have submitted two patches to get around build problems. I'd expect both to be needed for AIX and Solaris at least, as well as IRIX. "Add support for <xti.h>" "Bug in pg_restore.c" A minor problem that I have not addressed is that for the main build I was able to "make". That found my /usr/local/bin/gmake and from there on used "gmake". The same feature has not been done in src/test/regress. Running "gmake" directly is fine though. The runcheck regression tests are all good except for geometry. That has nine differences in the least significant digit compared with geometry-positive-zeros.out. Do you think that's good enough to submit a geometry-irix.out file? Summary: Snapshot with my two patches builds and passes the runcheck regression tests. -- Pete Forman -./\.- Disclaimer: This post is originated Western Geophysical -./\.- by myself and does not represent pete.forman@westgeo.com -./\.- the opinion of Baker Hughes or http://www.crosswinds.net/~petef -./\.- its divisions.
Pete Forman writes: > I have submitted two patches to get around build problems. I'd expect > both to be needed for AIX and Solaris at least, as well as IRIX. Both Solaris and AIX have been known to work. > A minor problem that I have not addressed is that for the main build I > was able to "make". That found my /usr/local/bin/gmake and from there > on used "gmake". The same feature has not been done in > src/test/regress. Running "gmake" directly is fine though. Actually, you can now run the regression tests simply by typing "make check" in the top-level directory; there's not need to move into the source tree anymore. We're probably not going to add the GNU make detection everywhere, since it's more of a gimmick than a real feature. > The runcheck regression tests are all good except for geometry. That > has nine differences in the least significant digit compared with > geometry-positive-zeros.out. Do you think that's good enough to > submit a geometry-irix.out file? Sure. Perhaps you could check first if the result you got matches any of the other geometry output files. > Snapshot with my two patches builds and passes the runcheck regression > tests. Where are the patches? -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
> Sure. Perhaps you could check first if the result you got matches any of > the other geometry output files. > > > Snapshot with my two patches builds and passes the runcheck regression > > tests. > > Where are the patches? > I think the patches list is stuck again. Marc? -- Bruce Momjian | http://candle.pha.pa.us pgman@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
On Fri, 13 Oct 2000, Bruce Momjian wrote: > > Sure. Perhaps you could check first if the result you got matches any of > > the other geometry output files. > > > > > Snapshot with my two patches builds and passes the runcheck regression > > > tests. > > > > Where are the patches? > > > > I think the patches list is stuck again. Marc? not that I can tell ... last one was from you last night, and I just sent a test through and it went through fine ... but, found a couple that I needed to approve. I'm going to remove some of teh checksum checks that are on the lists and see if it helps, as I've seen neither go thorugh, but were on hold due to checksum matches ...
The Hermit Hacker writes: > not that I can tell ... last one was from you last night, and I just sent > a test through and it went through fine ... but, found a couple that I > needed to approve. I'm going to remove some of teh checksum checks that > are on the lists and see if it helps, as I've seen neither go thorugh, but > were on hold due to checksum matches ... This might be too complicated, but maybe anyone that is subscribed to any pgsql-*@postgresql.org list should be able to post to pgsql-patches. Folks might find it too cumbersome to have to subscribe to a mailing list first to submit patches, so they either don't send them, or send them somewhere else where not everyone sees them. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
The Hermit Hacker writes:
> On Fri, 13 Oct 2000, Bruce Momjian wrote:
>
> > > Sure. Perhaps you could check first if the result you got
> > > matches any of the other geometry output files.
> > >
> > > > Snapshot with my two patches builds and passes the runcheck
> > > > regression tests.
> > >
> > > Where are the patches?
> > >
> >
> > I think the patches list is stuck again. Marc?
>
> not that I can tell ... last one was from you last night, and I
> just sent a test through and it went through fine ... but, found a
> couple that I needed to approve. I'm going to remove some of teh
> checksum checks that are on the lists and see if it helps, as I've
> seen neither go thorugh, but were on hold due to checksum matches
> ...
I submitted three patches to pgsql-patches@postgresql.org on Oct 13.
Only two have shown up on the web site. Even the mbox is missing the
second.
The missing patch is a one-liner, so here it is. I can resend the
whole bug report if wanted.
*** src/bin/pg_dump/pg_restore.c.orig Wed Aug 9 08:00:43 2000
--- src/bin/pg_dump/pg_restore.c Fri Oct 13 10:37:29 2000
***************
*** 88,94 ****
typedef struct option optType;
! #ifdef HAVE_GETOPT_H
struct option cmdopts[] = {
{ "clean", 0, NULL, 'c' },
{ "create", 0, NULL, 'C' },
--- 88,94 ----
typedef struct option optType;
! #ifdef HAVE_GETOPT_LONG
struct option cmdopts[] = {
{ "clean", 0, NULL, 'c' },
{ "create", 0, NULL, 'C' },
Here are some headers of the messages. It is the second, "Bug in
pg_restore.c", that is missing. I've had no messages back from mail
daemons.
Message-ID: <14822.54934.469674.683766@kryten.bedford.waii.com>
From: Pete Forman <gsez020@kryten.bedford.waii.com>
To: pgsql-patches@postgresql.org
Subject: Add support for <xti.h>
Date: Fri, 13 Oct 2000 10:32:06 +0100 (BST)
Message-ID: <14822.58242.931615.571964@kryten.bedford.waii.com>
From: Pete Forman <gsez020@kryten.bedford.waii.com>
To: pgsql-patches@postgresql.org
Subject: Bug in pg_restore.c
Date: Fri, 13 Oct 2000 11:27:14 +0100 (BST)
Message-ID: <14822.60874.529654.921133@kryten.bedford.waii.com>
From: Pete Forman <gsez020@kryten.bedford.waii.com>
To: pgsql-patches@postgresql.org
Subject: Regression tests - expected file for IRIX geometry test
Date: Fri, 13 Oct 2000 12:11:06 +0100 (BST)
--
Pete Forman -./\.- Disclaimer: This post is originated
Western Geophysical -./\.- by myself and does not represent
pete.forman@westgeo.com -./\.- the opinion of Baker Hughes or
http://www.crosswinds.net/~petef -./\.- its divisions.
Applied.
> The Hermit Hacker writes:
> > On Fri, 13 Oct 2000, Bruce Momjian wrote:
> >
> > > > Sure. Perhaps you could check first if the result you got
> > > > matches any of the other geometry output files.
> > > >
> > > > > Snapshot with my two patches builds and passes the runcheck
> > > > > regression tests.
> > > >
> > > > Where are the patches?
> > > >
> > >
> > > I think the patches list is stuck again. Marc?
> >
> > not that I can tell ... last one was from you last night, and I
> > just sent a test through and it went through fine ... but, found a
> > couple that I needed to approve. I'm going to remove some of teh
> > checksum checks that are on the lists and see if it helps, as I've
> > seen neither go thorugh, but were on hold due to checksum matches
> > ...
>
> I submitted three patches to pgsql-patches@postgresql.org on Oct 13.
> Only two have shown up on the web site. Even the mbox is missing the
> second.
>
> The missing patch is a one-liner, so here it is. I can resend the
> whole bug report if wanted.
>
> *** src/bin/pg_dump/pg_restore.c.orig Wed Aug 9 08:00:43 2000
> --- src/bin/pg_dump/pg_restore.c Fri Oct 13 10:37:29 2000
> ***************
> *** 88,94 ****
>
> typedef struct option optType;
>
> ! #ifdef HAVE_GETOPT_H
> struct option cmdopts[] = {
> { "clean", 0, NULL, 'c' },
> { "create", 0, NULL, 'C' },
> --- 88,94 ----
>
> typedef struct option optType;
>
> ! #ifdef HAVE_GETOPT_LONG
> struct option cmdopts[] = {
> { "clean", 0, NULL, 'c' },
> { "create", 0, NULL, 'C' },
>
>
>
> Here are some headers of the messages. It is the second, "Bug in
> pg_restore.c", that is missing. I've had no messages back from mail
> daemons.
>
> Message-ID: <14822.54934.469674.683766@kryten.bedford.waii.com>
> From: Pete Forman <gsez020@kryten.bedford.waii.com>
> To: pgsql-patches@postgresql.org
> Subject: Add support for <xti.h>
> Date: Fri, 13 Oct 2000 10:32:06 +0100 (BST)
>
> Message-ID: <14822.58242.931615.571964@kryten.bedford.waii.com>
> From: Pete Forman <gsez020@kryten.bedford.waii.com>
> To: pgsql-patches@postgresql.org
> Subject: Bug in pg_restore.c
> Date: Fri, 13 Oct 2000 11:27:14 +0100 (BST)
>
> Message-ID: <14822.60874.529654.921133@kryten.bedford.waii.com>
> From: Pete Forman <gsez020@kryten.bedford.waii.com>
> To: pgsql-patches@postgresql.org
> Subject: Regression tests - expected file for IRIX geometry test
> Date: Fri, 13 Oct 2000 12:11:06 +0100 (BST)
>
> --
> Pete Forman -./\.- Disclaimer: This post is originated
> Western Geophysical -./\.- by myself and does not represent
> pete.forman@westgeo.com -./\.- the opinion of Baker Hughes or
> http://www.crosswinds.net/~petef -./\.- its divisions.
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@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