Thread: 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@hotmail.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@sss.pgh.pa.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@postgresql.org" #define PG_VERSION "7.4.2" #define DEF_PGPORT 5432 #define DEF_PGPORT_STR "5432" configure: exit 1
"David P. Lurie" <dbase4@hotmail.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@sss.pgh.pa.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@hotmail.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@sss.pgh.pa.us> wrote in message news:16753.1080262892@sss.pgh.pa.us... > 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