Re: configure script failure with SCO 5.0.7

I've been using postgresql 7.3.4 on SCO 5.0.7, with binaries installed as
part of SCO Update Pack 2 for 5.0.7.

GNU development tools include gcc 2.95.3p4, installed as supplied by SCO.

The cywwin build that I am using for development is 7.4.1-3 , and I would
like to run similar versions on both systems.

The configure script for the 7.4.2 source distribution fails as follows:

checking build system type... i386-pc-sco3.2v5.0.7
checking host system type... i386-pc-sco3.2v5.0.7
checking which template to use... sco
checking whether to build with 64-bit integer date/time support... no
checking whether NLS is wanted... no
checking for default port number... 5432
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking how to turn off strict aliasing in gcc -b elf...
configure: using CFLAGS=-O2
checking whether the C compiler still works... no
configure: error: cannot proceed

Thanks,

David P. Lurie

"David P. Lurie" <dbase4(at)hotmail(dot)com> writes:
> The configure script for the 7.4.2 source distribution fails as follows:
> checking whether the C compiler still works... no
> configure: error: cannot proceed

The info configure prints on the terminal is much too brief to help in
diagnosing problems. Look into config.log to see what the C compiler is
unhappy about.

regards, tom lane

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in message > The info configure prints
on the terminal is much too brief to help in
> diagnosing problems. Look into config.log to see what the C compiler is
> unhappy about.

The configuration scripts appear to be lookin for the path

/usr/gnu/lib/gcc-lib/elf/2.95.3/...

while the equivalent path for the SCO-supplied GNU tools appears to be

/usr/gnu/lib/gcc-lib/i586-pc-sco3.2v5.0/2.95.3/..

Where do I make changes to set this path? Adding it to my path in .profile
did not correct the problem.

config.log is pasted below (system serial number removed).

Thanks for your assistance,

David P. Lurie

config.log:
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by PostgreSQL configure 7.4.2, which was
generated by GNU Autoconf 2.53. Invocation command line was

$ ./configure

## --------- ##
## Platform. ##
## --------- ##

hostname = dplp4.jointsrus.net
uname -m = i386
uname -r = 3.2
uname -s = SCO_SV
uname -v = 5.0.7

/usr/bin/uname -p = unknown
/bin/uname -X =
System = SCO_SV
Node = dplp4
Release = 3.2v5.0.7
KernelID = 2003-02-18
Machine = Pent4
BusType = ISA
Serial =
Users = 15
OEM# = 0
Origin# = 1
NumCPU = 1

/bin/arch = unknown
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
hostinfo = unknown
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown

PATH: /bin
PATH: /etc
PATH: /usr/bin
PATH: /tcb/bin
PATH: ./
PATH: /usr/gnu/bin
PATH: /usr/lib/samba/bin
PATH: /usr/local/lib
PATH: /usr/local/include/pthread
PATH: /usr/local/include
PATH: /usr/local/bin
PATH: /usr/local/mysql/bin
PATH: /usr/bin/X11
PATH: /usr/lib/powerchute

## ----------- ##
## Core tests. ##
## ----------- ##

configure:1296: checking build system type
configure:1314: result: i386-pc-sco3.2v5.0.7
configure:1322: checking host system type
configure:1336: result: i386-pc-sco3.2v5.0.7
configure:1346: checking which template to use
configure:1446: result: sco
configure:1565: checking whether to build with 64-bit integer date/time
support
configure:1596: result: no
configure:1603: checking whether NLS is wanted
configure:1637: result: no
configure:1645: checking for default port number
configure:1674: result: 5432
configure:1899: checking for gcc
configure:1915: found /usr/gnu/bin/gcc
configure:1925: result: gcc
configure:1944: checking for C compiler version
configure:1947: gcc --version </dev/null >&5
2.95.3
configure:1950: $? = 0
configure:1952: gcc -v </dev/null >&5
Reading specs from /usr/gnu/lib/gcc-lib/i586-pc-sco3.2v5.0/2.95.3/specs
gcc version 2.95.3 20030406 (SCO/p4)
configure:1955: $? = 0
configure:1957: gcc -V </dev/null >&5
gcc: argument to `-V' is missing
configure:1960: $? = 1
configure:1986: checking for C compiler default output
configure:1989: gcc conftest.c >&5
configure:1992: $? = 0
configure:2025: result: a.out
configure:2030: checking whether the C compiler works
configure:2036: ./a.out
configure:2039: $? = 0
configure:2054: result: yes
configure:2061: checking whether we are cross compiling
configure:2063: result: no
configure:2066: checking for suffix of executables
configure:2068: gcc -o conftest conftest.c >&5
configure:2071: $? = 0
configure:2093: result:
configure:2099: checking for suffix of object files
configure:2123: gcc -c conftest.c >&5
configure:2126: $? = 0
configure:2145: result: o
configure:2149: checking whether we are using the GNU C compiler
configure:2176: gcc -c conftest.c >&5
configure:2179: $? = 0
configure:2182: test -s conftest.o
configure:2185: $? = 0
configure:2197: result: yes
configure:2203: checking whether gcc accepts -g
configure:2227: gcc -c -g conftest.c >&5
configure:2230: $? = 0
configure:2233: test -s conftest.o
configure:2236: $? = 0
configure:2246: result: yes
configure:2273: gcc -c -g -O2 conftest.c >&5
conftest.c:2: syntax error before `me'
configure:2276: $? = 1
configure: failed program was:
#ifndef __cplusplus
choke me
#endif
configure:2414: checking how to turn off strict aliasing in gcc -b elf
configure:2448: gcc -b elf -c -O2 -fno-strict-aliasing conftest.c >&5
gcc: installation problem, cannot exec `cpp0': No such file or directory
gcc: file path prefix `/usr/gnu/lib/gcc-lib/elf/2.95.3/' never used
configure:2451: $? = 1
configure: failed program was:
#line 2429 "configure"
#include "confdefs.h"

#ifdef F77_DUMMY_MAIN
# ifdef __cplusplus
extern "C"
# endif
int F77_DUMMY_MAIN() { return 1; }
#endif
int
main ()
{

;
return 0;
}
configure:2471: result:
configure:2483: using CFLAGS=-O2
configure:2492: checking whether the C compiler still works
configure:2514: gcc -b elf -o conftest -O2 conftest.c >&5
gcc: installation problem, cannot exec `cpp0': No such file or directory
gcc: file path prefix `/usr/gnu/lib/gcc-lib/elf/2.95.3/' never used
configure:2517: $? = 1
configure: failed program was:
#line 2495 "configure"
#include "confdefs.h"

#ifdef F77_DUMMY_MAIN
# ifdef __cplusplus
extern "C"
# endif
int F77_DUMMY_MAIN() { return 1; }
#endif
int
main ()
{
return 0;
;
return 0;
}
configure:2530: result: no
configure:2532: error: cannot proceed

## ---------------- ##
## Cache variables. ##
## ---------------- ##

ac_cv_build=i386-pc-sco3.2v5.0.7
ac_cv_build_alias=i386-pc-sco3.2v5.0.7
ac_cv_c_compiler_gnu=yes
ac_cv_env_CC_set=''
ac_cv_env_CC_value=''
ac_cv_env_CFLAGS_set=''
ac_cv_env_CFLAGS_value=''
ac_cv_env_CPPFLAGS_set=''
ac_cv_env_CPPFLAGS_value=''
ac_cv_env_CPP_set=''
ac_cv_env_CPP_value=''
ac_cv_env_DOCBOOKSTYLE_set=''
ac_cv_env_DOCBOOKSTYLE_value=''
ac_cv_env_LDFLAGS_set=''
ac_cv_env_LDFLAGS_value=''
ac_cv_env_build_alias_set=''
ac_cv_env_build_alias_value=''
ac_cv_env_host_alias_set=''
ac_cv_env_host_alias_value=''
ac_cv_env_target_alias_set=''
ac_cv_env_target_alias_value=''
ac_cv_exeext=''
ac_cv_host=i386-pc-sco3.2v5.0.7
ac_cv_host_alias=i386-pc-sco3.2v5.0.7
ac_cv_objext=o
ac_cv_prog_ac_ct_CC=gcc
ac_cv_prog_cc_g=yes

## ----------- ##
## confdefs.h. ##
## ----------- ##

#define PACKAGE_NAME "PostgreSQL"
#define PACKAGE_TARNAME "postgresql"
#define PACKAGE_VERSION "7.4.2"
#define PACKAGE_STRING "PostgreSQL 7.4.2"
#define PACKAGE_BUGREPORT "pgsql-bugs(at)postgresql(dot)org"
#define PG_VERSION "7.4.2"
#define DEF_PGPORT 5432
#define DEF_PGPORT_STR "5432"

configure: exit 1

"David P. Lurie" <dbase4(at)hotmail(dot)com> writes:
> configure:2492: checking whether the C compiler still works
> configure:2514: gcc -b elf -o conftest -O2 conftest.c >&5
> gcc: installation problem, cannot exec `cpp0': No such file or directory
> gcc: file path prefix `/usr/gnu/lib/gcc-lib/elf/2.95.3/' never used

I'd say you have a screwed-up gcc installation. The apparent file path
problem is certainly not configure's fault, as those paths are all
purely internal to gcc.

The fact that it seems to work up till the point where we add "-b elf"
to the compiler switches is interesting. I do not know how that might
provoke a gcc failure where there was none before, but the obvious thing
to try is to remove the line in src/template/sco that does that.

regards, tom lane

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in message

>the obvious thing
> to try is to remove the line in src/template/sco that does that.
>

Getting close now:

Removed the -b elf option in src/template/sco, and configure completed
without problem, then again with perl and openssl options added.

Make, make install, and initdb completed without problems. Default
directories were used (/usr/local/pgsql/...) The 7.3x version from SCO
wasn't uninstalled, but isn't running. It installed binaries to a different
directory, and was set up to use a different data directory.

LD_LIBRARY_PATH set to /usr/local/pgsql/lib for user postgres

tcp_socket set to true in postgresql.conf

trusted access set for local use in pg_hba.conf

trusted access set for host for my windows box on LAN in pg_hba.conf

postmaster loads without error, with initial log messages to stdout same as
other version.

logging into the server locally as postgres from the console, "locally"
(xterm on X desktop from my windows box) or telnet from my windows box
results in the same error when attempting to run createdb or psql:

dplp4:~$ psql template1
psql: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
dplp4:~$ createdb testdb
psql: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
createdb: database creation failed

Here is a sample output from the server log after either of the above:

dplp4:/usr/local/pgsql/data$ cat server.log
LOG: database system was shut down at 2004-03-25 18:43:09 EST
LOG: checkpoint record is at 0/9B276C
LOG: redo record is at 0/9B276C; undo record is at 0/0; shutdown TRUE
LOG: next transaction ID: 653; next OID: 17142
LOG: database system is ready
LOG: setsockopt(TCP_NODELAY) failed: Protocol not available

I can connect to the server using trusted login from pgAdminIII from my
windows box, with template0 and template1 displayed as with the older
version, and cywin ports on windows boxes.

Attempt at creating a new database with pgAdminIII results in

ERROR: source database "template1" is being accessed by other users

The same error also shows up in the server log.

Thanks for your assistance. What should I try next?

David P. Lurie

"David P. Lurie" <dbase4(at)hotmail(dot)com> writes:
> dplp4:~$ psql template1
> psql: server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.

So, what shows up in the postmaster log when this happens? Is there a
core file, and if so can you get a stack trace from it?

> I can connect to the server using trusted login from pgAdminIII from my
> windows box, with template0 and template1 displayed as with the older
> version, and cywin ports on windows boxes.

Yeah? Can you connect locally via TCP? Try
psql -h localhost template1
If that works then the problem must be localized to Unix socket access
... I have no idea what would cause such a problem though ...

regards, tom lane

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in message
news:16753(dot)1080262892(at)sss(dot)pgh(dot)pa(dot)us(dot)(dot)(dot)
> So, what shows up in the postmaster log when this happens? Is there a
> core file, and if so can you get a stack trace from it?
>
> > I can connect to the server using trusted login from pgAdminIII from my
> > windows box, with template0 and template1 displayed as with the older
> > version, and cywin ports on windows boxes.
>
> Yeah? Can you connect locally via TCP? Try
> psql -h localhost template1
> If that works then the problem must be localized to Unix socket access
> ... I have no idea what would cause such a problem though ...
>

No core file because the server doesn't terminate despite the error message.

psql -h localhost template1 works! Was used to mysql where local connection
wasn't tcp socket unless explicitly specified. Still doesn't explain why I
can connect with pgAdminIII from the LAN but not successfully execute
commands.

It must be a socket problem; I found the following post in the postgresql
archives, but no attachment, just his PGP signature, and no new
src/template/sco in the source tree:

a.. From: Larry Rosenman <ler ( at ) lerctr ( dot ) org>
b.. To: pgsql-hackers ( at ) postgresql ( dot ) org
c.. Subject: OpenServer 5.0.7: setsockopt(TCP_NODELAY)?
d.. Date: Thu, 06 Nov 2003 18:56:31 -0600

----------------------------------------------------------------------------
----

I asked my friends at SCO (who are productizing PG) to test
7.4RC1 on OpenServer 5.0.7, and received this back:

A "make check" fails at createdb with errors in the postmaster logfile:

LOG: setsockopt(TCP_NODELAY) failed: Protocol not available

Plus he needed to add:

if test "$GCC" != yes ; then
CC="$CC -b elf"
fi
to src/template/sco for 5.0.7.
I downloaded 7.4 RC1 and successfully compiled it on an OpenServer 5.0.7
system.
I am attaching the only change i had to make. This is the file
src/template/sco.
The GCC compiler on OSR5 no longer accepts the "-b elf" argument.

Anyone of the guru's have ideas?

Thanks,
LER

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler ( at ) lerctr ( dot ) org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749