Thread: testing for usable C compiler
BTW, would it be possible to tweak configure's test for "minimum working
C compiler" to include a check that cc accepts ANSI-style function
prototypes? That would allow us to bounce HP's lame excuse for a free
compiler with a slightly useful message ...
regards, tom lane
------- Forwarded Message
Date: Tue, 02 Sep 2003 23:17:20 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Weiping He <laser@zhengmai.com.cn>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] configure error in HP-UX 11.00
Weiping He <laser@zhengmai.com.cn> writes:
> I've put the config.log on:
> http://www.pgsqldb.org/config.log
configure:10847: cc -Ae -c +O2 -D_XOPEN_SOURCE_EXTENDED conftest.c >&5
(Bundled) cc: warning 480: The -A option is available only with the C/ANSI C product; ignored.
Get a real compiler :-(
The "bundled" cc is a piece of junk that HP ought to be ashamed to ship.
You cannot build Postgres (or much of anything else) with it. If you
don't want to shell out for HP's real C compiler, install gcc.
regards, tom lane
------- End of Forwarded Message
Tom Lane writes: > BTW, would it be possible to tweak configure's test for "minimum working > C compiler" to include a check that cc accepts ANSI-style function > prototypes? That would allow us to bounce HP's lame excuse for a free > compiler with a slightly useful message ... Yes, unfortunately that involves that configure automatically mucks with CFLAGS, which could have interesting side-effects on some platforms. For example, on Tru64 it will add -std1, which is more strict than the -std that we currently use. Eventually, we'll have to deal with this anyway, because newer autoconf versions do this automatically when you can AC_PROG_CC (blame yours truly for that change), but it might not be the wisest thing to try right now. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> BTW, would it be possible to tweak configure's test for "minimum working
>> C compiler" to include a check that cc accepts ANSI-style function
>> prototypes? That would allow us to bounce HP's lame excuse for a free
>> compiler with a slightly useful message ...
> Yes, unfortunately that involves that configure automatically mucks with
> CFLAGS, which could have interesting side-effects on some platforms.
Yeah. I would suggest doing it at the "check that C compiler still
works" stage, after we think we have all the CFLAGS. Couldn't we just
throw a prototyped function into that test program?
regards, tom lane
Tom Lane writes: > Yeah. I would suggest doing it at the "check that C compiler still > works" stage, after we think we have all the CFLAGS. Couldn't we just > throw a prototyped function into that test program? The standard Autoconf prototype test is pretty involved (see AC_PROG_CC_STDC in /usr/local/share/autoconf/autoconf/c.m4 or whatever). Maybe you can come up with a smaller test for now that fails on the lame-excuse compiler on HP-UX? If you don't want to merge it in yourself, feel free to just send me a .c file that fails to compile and I'll integrate it. But: What's the error message going to be? Is "compiler does not accept prototypes" going to be clearer for the user than what he gets now? (What does he get now anyway? Does it fail to compile something down the road?) -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> Couldn't we just throw a prototyped function into that test program?
> The standard Autoconf prototype test is pretty involved (see
> AC_PROG_CC_STDC in /usr/local/share/autoconf/autoconf/c.m4 or whatever).
Yikes. And that's really of zero value to us, since we already have all
that knowledge (about which CFLAGS to use per-platform) embedded in our
template files.
> Maybe you can come up with a smaller test for now that fails on the
> lame-excuse compiler on HP-UX?
It's not hard.
$ cat test.c
int test(int x)
{ return x;
}
-- cc is the "good" compiler
$ cc -c test.c
cc: "test.c", line 1: error 1705: Function prototypes are an ANSI feature.
$ cc -Ae -c test.c
$
-- /usr/ccs/bin/cc is bogus
$ /usr/ccs/bin/cc -c test.c
(Bundled) cc: "test.c", line 1: error 1705: Function prototypes are an ANSI feature.
$ /usr/ccs/bin/cc -Ae -c test.c
(Bundled) cc: warning 480: The -A option is available only with the C/ANSI C product; ignored.
(Bundled) cc: "test.c", line 1: error 1705: Function prototypes are an ANSI feature.
$
> But: What's the error message going to be? Is "compiler does not accept
> prototypes" going to be clearer for the user than what he gets now?
For sure. See the discussion a day or two back --- with the bundled
compiler, the first sign of trouble is that configure fails to determine
the argument types for accept(). Not very helpful :-(
regards, tom lane