Thread: BUG #15243: make check shows errors,i.e. fails to find initdb and others

The following bug has been logged on the website:

Bug reference:      15243
Logged by:          Mario Emmenlauer
Email address:      mario@emmenlauer.de
PostgreSQL version: 10.4
Operating system:   Ubuntu Linux
Description:

I tried my first build of PostgreSQL 10.4 on Ubuntu Linux 16.04 today. The
build worked out of the box. However `make check` fails. I am under the
impression that it tries a "strange" path to search for build-time binaries.
But I'm not experienced enough to figure out why. Here are my
observations:

Make check aborts immediately with message:

rm -rf ./testtablespace
mkdir ./testtablespace
PATH="/tmp/Debug/Shared/postgresql-10.4/tmp_install/thirdparty/Debug/Shared/bin:$PATH"
LD_LIBRARY_PATH="/tmp/Debug/Shared/postgresql-10.4/tmp_install/thirdparty/Debug/Shared/lib:$LD_LIBRARY_PATH"
../../../src/test/regress/pg_regress --temp-instance=./tmp_check
--inputdir=. --bindir=     --dlpath=.  --schedule=./parallel_schedule  
============== creating temporary instance            ==============
============== initializing database system           ==============
pg_regress: initdb failed
Examine /tmp/Debug/Shared/postgresql-10.4/src/test/regress/log/initdb.log
for the reason.
Command was: "initdb" -D
"/tmp/Debug/Shared/postgresql-10.4/src/test/regress/./tmp_check/data"
--no-clean --no-sync >
"/tmp/Debug/Shared/postgresql-10.4/src/test/regress/log/initdb.log" 2>&1
GNUmakefile:130: recipe for target 'check' failed

In /tmp/Debug/Shared/postgresql-10.4/src/test/regress/log/initdb.log there
is just a short message saying that initdb was not found. What makes me
curious is the PATH setting above that ends in
`tmp_install/thirdparty/Debug/Shared/bin`. This whole suffix does not exist
on my machine, and actually the suffix `/thirdparty/Debug/Shared/bin` is my
target installation prefix.
Does anyone else experience issues with make check, or does this ring a bell
with anyone?

Thanks for the great work, and all the best, Mario Emmenlauer

=?utf-8?q?PG_Bug_reporting_form?= <noreply@postgresql.org> writes:
> I tried my first build of PostgreSQL 10.4 on Ubuntu Linux 16.04 today. The
> build worked out of the box. However `make check` fails. I am under the
> impression that it tries a "strange" path to search for build-time binaries.
> But I'm not experienced enough to figure out why.

It's hard for someone else to be sure either.  What "make check" is
supposed to do is create a temporary installation under
...sourcedir.../tmp_install/, so this:

> PATH="/tmp/Debug/Shared/postgresql-10.4/tmp_install/thirdparty/Debug/Shared/bin:$PATH"

looks correct if your PG source is in /tmp/Debug/Shared/postgresql-10.4/
and the configured real installation path is /thirdparty/Debug/Shared/.
You confirmed the latter but not the former.

> In /tmp/Debug/Shared/postgresql-10.4/src/test/regress/log/initdb.log there
> is just a short message saying that initdb was not found.

This suggests that the temp installation failed to be made, but you did
not show us the part of the make log where that should've happened;
it'd be before this extract, of course.

Also, were you trying a VPATH build, or just build-in-source-tree?
That affects where this stuff would end up.

            regards, tom lane

Dear Tom,

I hope the reply-by-mail works (this is my first pgsql report :-) )

On 15.06.2018 23:20, Tom Lane wrote:
> =?utf-8?q?PG_Bug_reporting_form?= <noreply@postgresql.org> writes:
>> I tried my first build of PostgreSQL 10.4 on Ubuntu Linux 16.04 today. The
>> build worked out of the box. However `make check` fails. I am under the
>> impression that it tries a "strange" path to search for build-time binaries.
>> But I'm not experienced enough to figure out why.
> 
> It's hard for someone else to be sure either.  What "make check" is
> supposed to do is create a temporary installation under
> ...sourcedir.../tmp_install/, so this:
> 
>> PATH="/tmp/Debug/Shared/postgresql-10.4/tmp_install/thirdparty/Debug/Shared/bin:$PATH"
> 
> looks correct if your PG source is in /tmp/Debug/Shared/postgresql-10.4/
> and the configured real installation path is /thirdparty/Debug/Shared/.
> You confirmed the latter but not the former.

Yes, its exactly like you say: PG sources are in
/tmp/Debug/Shared/postgresql-10.4/ and the configured real installation
path is /thirdparty/Debug/Shared/.


>> In /tmp/Debug/Shared/postgresql-10.4/src/test/regress/log/initdb.log there
>> is just a short message saying that initdb was not found.
> 
> This suggests that the temp installation failed to be made, but you did
> not show us the part of the make log where that should've happened;
> it'd be before this extract, of course.

I have tried the build again and this time I used the directories
/data/Debug/Shared/postgresql-10.4 for the build and /data/Debug/Shared
for the installation. /data/ is a symlink to /data1/ on my machine, in
case that makes a difference. The build works fine so I only attach the
log from 'make -j1 check'.


> Also, were you trying a VPATH build, or just build-in-source-tree?
> That affects where this stuff would end up.

I tried the build-in-source-tree so far. Should I try a VPATH build?

All the best and thanks a lot,

    Mario Emmenlauer


--
BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
D-81669 München                          http://www.biodataanalysis.de/

Mario Emmenlauer <mario@emmenlauer.de> writes:
> On 15.06.2018 23:20, Tom Lane wrote:
>> This suggests that the temp installation failed to be made, but you did
>> not show us the part of the make log where that should've happened;
>> it'd be before this extract, of course.

> I have tried the build again and this time I used the directories
> /data/Debug/Shared/postgresql-10.4 for the build and /data/Debug/Shared
> for the installation. /data/ is a symlink to /data1/ on my machine, in
> case that makes a difference. The build works fine so I only attach the
> log from 'make -j1 check'.

Hm ... definitely no temp installation creation happening there :-(

Looking at the make code that should be invoking this, I'm guessing
that you must be hitting one of the "if" conditions that prevent the
rule from being executed:

check: temp-install

.PHONY: temp-install
temp-install:
ifndef NO_TEMP_INSTALL
ifneq ($(abs_top_builddir),)
ifeq ($(MAKELEVEL),0)
    rm -rf '$(abs_top_builddir)'/tmp_install
    $(MKDIR_P) '$(abs_top_builddir)'/tmp_install/log
    $(MAKE) -C '$(top_builddir)' DESTDIR='$(abs_top_builddir)'/tmp_install install
>'$(abs_top_builddir)'/tmp_install/log/install.log2>&1 
endif
    $(if $(EXTRA_INSTALL),for extra in $(EXTRA_INSTALL); do $(MAKE) -C '$(top_builddir)'/$$extra
DESTDIR='$(abs_top_builddir)'/tmp_installinstall >>'$(abs_top_builddir)'/tmp_install/log/install.log || exit; done) 
endif
endif

The most likely bet is that the MAKELEVEL condition is firing,
perhaps because you're invoking "make check" from some makefile of
your own rather than by hand.  If so, you could try doing this:

    unset MAKELEVEL && make check

            regards, tom lane

Dear Tom,

On 18.06.2018 22:36, Tom Lane wrote:
> Mario Emmenlauer <mario@emmenlauer.de> writes:
>> On 15.06.2018 23:20, Tom Lane wrote:
>>> This suggests that the temp installation failed to be made, but you did
>>> not show us the part of the make log where that should've happened;
>>> it'd be before this extract, of course.
> 
>> I have tried the build again and this time I used the directories
>> /data/Debug/Shared/postgresql-10.4 for the build and /data/Debug/Shared
>> for the installation. /data/ is a symlink to /data1/ on my machine, in
>> case that makes a difference. The build works fine so I only attach the
>> log from 'make -j1 check'.
> 
> Hm ... definitely no temp installation creation happening there :-(
> 
> Looking at the make code that should be invoking this, I'm guessing
> that you must be hitting one of the "if" conditions that prevent the
> rule from being executed:
> 
> check: temp-install
> 
> .PHONY: temp-install
> temp-install:
> ifndef NO_TEMP_INSTALL
> ifneq ($(abs_top_builddir),)
> ifeq ($(MAKELEVEL),0)
>     rm -rf '$(abs_top_builddir)'/tmp_install
>     $(MKDIR_P) '$(abs_top_builddir)'/tmp_install/log
>     $(MAKE) -C '$(top_builddir)' DESTDIR='$(abs_top_builddir)'/tmp_install install
>'$(abs_top_builddir)'/tmp_install/log/install.log2>&1
 
> endif
>     $(if $(EXTRA_INSTALL),for extra in $(EXTRA_INSTALL); do $(MAKE) -C '$(top_builddir)'/$$extra
DESTDIR='$(abs_top_builddir)'/tmp_installinstall >>'$(abs_top_builddir)'/tmp_install/log/install.log || exit; done)
 
> endif
> endif
> 
> The most likely bet is that the MAKELEVEL condition is firing,
> perhaps because you're invoking "make check" from some makefile of
> your own rather than by hand.  If so, you could try doing this:
> 
>     unset MAKELEVEL && make check

Very good observation! Horray! This is actually the very cause of
the problem! I build PostgreSQL from inside my build system that is
itself based on Makefiles.

I now added 'unset MAKEFLAGS && unset MAKELEVEL', and everything
works as expected! Hats off to you!

All the best,

    Mario Emmenlauer


--
BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
D-81669 München                          http://www.biodataanalysis.de/

Dear Tom and all,

I just wanted to say a big "thank you" to the developers and community!
I can successfully build PostgreSQL on Windows, Linux and MacOSX now!
I am specifically happy that the MSVC build was so nicely explained, and
that it even works on Windows with the Intel Compiler.

So just a big thank you!

And, this is my first bug report, I do not know how to close it. Please
let me know if there is something I need to do.

All the best,

   Mario Emmenlauer


--
BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
D-81669 München                          http://www.biodataanalysis.de/

Mario Emmenlauer <mario@emmenlauer.de> writes:
> And, this is my first bug report, I do not know how to close it. Please
> let me know if there is something I need to do.

Nope, we don't have any formal process for that.  No worries.

            regards, tom lane