Configure problems on Solaris 2.7, pgsql 7.02 and 7.03

Ciaran Johnston <Ciaran.Johnston@eei.ericsson.se> writes:

Sorry to bother you's but I am currently doing a database comparison and
have been trying to get postgresql installed. I'm running Solaris 2.7. I
downloaded pgsql 7.03 and ran ./configure in the src/ directory. This
was fine until the very end when this error appeared:

creating ./config.status
creating GNUmakefile
sed: command garbled: s%@CC_VERSION@%Version: CSE C Compiler CAA 139
1065/11 R14A

Hm. I'm guessing that cc --version on your machine puts out multiple
lines, or something like that. Possibly you could simply ignore this
error and push on, but since you are just doing evaluation and not
production work, I'd suggest you forget 7.0.3 and try 7.1RC2 or later
instead. It looks like the newer version is more wary about this sort
of thing.

regards, tom lane

Mathijs Brands wrote:

On Wed, Apr 04, 2001 at 06:46:12PM +0300, Mart�n Marqu�s allegedly wrote:

Why are you running configure inside src/? I'm not sure if the 7.0.x had the
configure on the src/ dir or the root.

It's in the src dir with 7.0.x alright.

You could take a look at 7.1RC[2-3], which looks pretty stable, and I have
(RC1) compiled and working on a Solaris 8 SPARC.

I'm using pgsql 7.0.3 on Solaris 7 Sparc and Solaris 8 Intel for a
website that get's about 600,000 pageviews daily. pgsql 7.0.x works
without problems for me and I'm connecting to it via JDBC. No crashes
or major problems so far.

This is pretty much what I want to do - it is an internal management
server but the principle is the same and I intend to use JDBC to connect
to it. I'm glad to hear you are getting good results. Anyway, I checked
out 7.1RC2 and it configured OK, but gave me an error on make, in an
include file. We are planning the first release of the management system
for August, so it would be preferable to get a stable system up and
running ASAP rather than a test one.

Anyway, 7.0.x should work problem free on Solaris (there are some
issues with 7.1 at the moment). To make this a bit easier to diagnose,
could you send me the output of the following commands?

Here they are, with a couple extra for luck. The obese path is the
creation of the sysadmins here, and I have had to install my own
versions of make and sed:

##################################################################

eeiatuc282 eeicjon 101> uname -a
SunOS eeiatuc282 5.7 Generic_106541-11 sun4u sparc SUNW,Ultra-5_10
eeiatuc282 eeicjon 102> echo $PATH
/client_local/db/ant/bin:/client_local/mysql-3.22.32-sun-solaris2.7-sparc/bin:/home/eeicjon/R7B/bin:/apps/Java/jdk1.2.2_05/bin:/apps/workshop/SUNWspro/bin/:/usr/ccs/bin:/home/atus07B/apps3/emacs-20.5/bin:/usr/atria/bin:/usr/dt/bin:/usr/openwin/bin:/bin:/usr/bin:/usr/ucb:/usr/lib/X11:/usr/local/SUNWspro:/usr/openwin/lib/X11:/usr/bin:/bin:/usr/etc:/usr/5bin:/usr/sbin:/usr/local/bin:/usr/ucb:/usr/local/flextool/bin/sun4:/usr/openwin/bin:/usr/openwin/bin/xview:/home/atus07C/apps4/apssystem_v3.2/bin:/apps/localtools/filediff:/apps/scripts:/apps/localtools:/usr/local/WWW/bin:/home/atus02A/publish/ioffice/bin:/home/atus11B/SUNWspro/bin:/apps/Java/jdk1.1/bin:/apps/Java/jdk1.2beta3:/apps/Java/jit:/apps/eliza-R6/sunos5/bin:.
eeiatuc282 eeicjon 103> which sed
sed: aliased to /client_local/exec/sed/bin/sed
eeiatuc282 eeicjon 104> sed -V
GNU sed version 3.02

Copyright (C) 1998 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE,
to the extent permitted by law.
eeiatuc282 eeicjon 105> which gcc
/home/atus07C/apps4/apssystem_v3.2/bin/gcc
eeiatuc282 eeicjon 106> gcc -v
/home/atus07C/apps4/apssystem_v3.2/lib/cse/c_compiler/bin/gcc
-B/home/atus07C/apps4/apssystem_v3.2/lib/cse/c_compiler/lib/gcc-lib/sun4/ericsson/
-v
Reading specs from
/home/atus07C/apps4/apssystem_v3.2/lib/cse/c_compiler/lib/gcc-lib/sun4/ericsson/specs
gcc version 2.9-gnupro-98r2
eeiatuc282 eeicjon 107> which make
make: aliased to /client_local/exec/make/bin/make
eeiatuc282 eeicjon 108> make -v
GNU Make version 3.79, by Richard Stallman and Roland McGrath.
Built for sparc-sun-solaris2.7
Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99
Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

Report bugs to <bug-make@gnu.org>.

eeiatuc282 eeicjon 109>

##################################################################

Thanks in advance for any help you can give me on this one.

--
Ciaran Johnston
Ericsson Systems Expertise Ltd.,
Athlone
Co. Westmeath
Eire

email: Ciaran.Johnston@eei.ericsson.se
Phone: +353 902 31274

Mathijs Brands wrote:

<SNIP>

If you want to start running your production machine in august, it would
be a very good idea to start using 7.1 now, since the stable release will
most likely be out before then (probably april or early may).

You seem to be using the Cygnus version of GCC. I'm not sure that will
work ok, although it most likely does. The version of make and sed you're
using are ok, so they shouldn't be causing your problems.

Since it took me a couple of days to respond, it's possible that you've
already resolved this problem. Have you? If not, you might try a binary
distribution of pgsql instead. Or you could mail me the errors you're
receiving. Maybe I can figure it out. No promises though.

Thanks, and thanks to all who responded. I experimented with a couple of configs and
finally went back to 7.0.3 and edited the configure script so that it didn't pass 'cc
--version' to sed (cheers to Tom Lane for pointing out the multiple-line output).
This worked and compiled, but postmaster gave me a nasty memory error which the FAQ
was able to provide a workaround for - shmget failed (invalid argument) was the
error. Seems my kernel isn't properly configured for postGres (along with all the
other things that are wrong with my system). I'm currently passing -N 16 -B 32 to the
postmaster and it is running - haven't tested it yet tho'. Are there optimum
parameters for these numbers, before I get around to getting my sysadmins to fix my
kernel for me? The testing should really be finished by next week and there's no way
they'll get it right before then. Also how much difference will this make? I'm
noticing slower queries but better scaleability to bigger tables than MySQL at the
minute, although my tests were far from optimised, and I have only just come back to
this.

I could probably have got 7.1RC2 working as well, I was just hoping the above error
was specific to that version and not to my system :-). When we set up the proper test
environment (which won't be for a few weeks), we'll probably use that (assuming
no-one here decides to spend 50 grand on Oracle, or MySQL doesn't suddenly pip the
post in the tests :-).

Thanks again.

Ciaran.

--
Ciaran Johnston
Ericsson Systems Expertise Ltd.,
Athlone
Co. Westmeath
Eire

email: Ciaran.Johnston@eei.ericsson.se
Phone: +353 902 31274