Re: Fix compiler warnings on 64-bit Windows

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fix compiler warnings on 64-bit Windows
Date: 2020-02-17 14:31:29
Message-ID: 959.1581949889@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> On 2020-02-14 15:52, Tom Lane wrote:
>> BTW: I'm still concerned about the possibility of the C library being
>> less than C99. The model that was popular back then, and which still
>> exists on e.g. gaur, was that you could install a C99 *compiler* on
>> a pre-C99 system, and the compiler would bring its own standard header
>> files as necessary. While I don't have the machine booted up to check,
>> I'm pretty sure that gaur's <stdint.h> is being supplied by the gcc
>> installation not directly from /usr/include. On the other hand, that
>> compiler installation is still dependent on the vendor-supplied libc.

> Yeah, stdint.h belongs to the compiler, whereas intttypes.h belongs to
> the C library. So if we require a C99 compiler we can get rid of all
> tests and workarounds for stdint.h missing. Patch attached.

I tried this on gaur's host, and got:

$ make -s
In file included from ../../src/include/postgres_fe.h:25,
from base64.c:18:
../../src/include/c.h:67:20: stdint.h: No such file or directory
make[2]: *** [base64.o] Error 1
make[1]: *** [all-common-recurse] Error 2
make: *** [all-src-recurse] Error 2

Ooops. Poking around, it looks like this version of gcc has brought its
own stdbool.h, but not stdint.h:

$ ls /usr/include/std*
/usr/include/std_space.h /usr/include/stdio.h
/usr/include/stdarg.h /usr/include/stdlib.h
/usr/include/stddef.h
$ find /opt/gcc-3.4.6 -name 'std*.h'
/opt/gcc-3.4.6/lib/gcc/hppa2.0-hp-hpux10.20/3.4.6/include/stdarg.h
/opt/gcc-3.4.6/lib/gcc/hppa2.0-hp-hpux10.20/3.4.6/include/stdbool.h
/opt/gcc-3.4.6/lib/gcc/hppa2.0-hp-hpux10.20/3.4.6/include/stddef.h
/opt/gcc-3.4.6/lib/gcc/hppa2.0-hp-hpux10.20/3.4.6/include/stdio.h
/opt/gcc-3.4.6/lib/gcc/hppa2.0-hp-hpux10.20/3.4.6/include/stdlib.h
/opt/gcc-3.4.6/lib/gcc/hppa2.0-hp-hpux10.20/3.4.6/install-tools/include/stdarg.h
/opt/gcc-3.4.6/lib/gcc/hppa2.0-hp-hpux10.20/3.4.6/install-tools/include/stdbool.h
/opt/gcc-3.4.6/lib/gcc/hppa2.0-hp-hpux10.20/3.4.6/install-tools/include/stddef.h

Kind of annoying. Perhaps more recent gcc versions fixed that?
Anyway, this seems like a bit of a blocker for this idea, at least
unless I update or retire this buildfarm critter.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2020-02-17 14:36:10 Duplicate words in comments
Previous Message Sergei Kornilov 2020-02-17 13:57:04 Re: pgsql: walreceiver uses a temporary replication slot by default