Alexander Lakhin <exclusion@gmail.com> writes:
> 14.07.2018 13:57, Peter Eisentraut wrote:
>> On 06.07.18 09:45, Alexander Lakhin wrote:
>>> ./configure --enable-tap-tests
>>> make install
>>> make install -C contrib
>>> chown -R postgres:postgres /usr/local/pgsql/
>>> /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
>>> /usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data
>>> /make clean/
>>> # Also you can just install binary packages to get the same state.
>>>
>>> make installcheck-world
>>> # This check fails.
I remain pretty skeptical that this is a sensible way to proceed,
especially not if what you're testing is installed binary packages.
You're creating yet *another* hazard for version-skew-like problems,
namely that there's no certainty that you gave configure arguments
that're compatible with what the installed packages used.
But having said that ...
>> For me, this fails at
>> In file included from ../../src/include/postgres.h:47,
>> from chklocale.c:17:
>> ../../src/include/utils/elog.h:71:10: fatal error: utils/errcodes.h: No
>> such file or directory
>> That's probably fixable. But it's different from what you had initially
>> reported.
> This error wasn't present in master at the time of initial report (in
> April). As "git bisect" shows such errors appeared after 372728b.
> So in REL_10_STABLE (or in master before 372728b) you could "make
> installcheck" (but not installcheck-world) in a clean environment.
... I think this was actually induced by 3b8f6e75f, for which we already
had to make some adjustments to ensure that the generated headers got
built when needed. This seems like another such case, so I stuck in a
couple more submake-generated-headers dependencies to fix it.
The original complaint about ecpg remains; I'm not terribly excited
about messing with that.
regards, tom lane
