Possible dependency issue in makefile

Started by Filip Janusover 4 years ago3 messages
#1Filip Janus
fjanus@redhat.com

Hi all,
I am building libecpg 13.1 but 13.3 behaves in the same manner and my build
fails with:

path.c: In function 'get_html_path':
path.c:787:38: error: 'HTMLDIR' undeclared (first use in this function)
787 | make_relative_path(ret_path, HTMLDIR, PGBINDIR, my_exec_path);
| ^~~~~~~
path.c:787:38: note: each undeclared identifier is reported only once
for each function it appears in
path.c: In function 'get_man_path':
path.c:796:38: error: 'MANDIR' undeclared (first use in this
function); did you mean 'MAXDIM'?
796 | make_relative_path(ret_path, MANDIR, PGBINDIR, my_exec_path);
| ^~~~~~
| MAXDIM
make[2]: *** [<builtin>: path.o] Error 1

It looks like some dependency issue, because this error is followed by:
make[2]: Entering directory '/builddir/build/BUILD/postgresql-13.1/src/port'
echo "#define PGBINDIR \"/usr/bin\"" >pg_config_paths.h
echo "#define PGSHAREDIR \"/usr/share/pgsql\"" >>pg_config_paths.h
echo "#define SYSCONFDIR \"/etc\"" >>pg_config_paths.h
echo "#define INCLUDEDIR \"/usr/include\"" >>pg_config_paths.h
echo "#define PKGINCLUDEDIR \"/usr/include/pgsql\"" >>pg_config_paths.h
echo "#define INCLUDEDIRSERVER \"/usr/include/pgsql/server\""

pg_config_paths.h

echo "#define LIBDIR \"/usr/lib64\"" >>pg_config_paths.h
echo "#define PKGLIBDIR \"/usr/lib64/pgsql\"" >>pg_config_paths.h
echo "#define LOCALEDIR \"/usr/share/locale\"" >>pg_config_paths.h
echo "#define DOCDIR \"/usr/share/doc//pgsql\"" >>pg_config_paths.h
echo "#define HTMLDIR \"/usr/share/doc//pgsql\"" >>pg_config_paths.h
echo "#define MANDIR \"/usr/share/man\"" >>pg_config_paths.h
make[2]: Leaving directory '/builddir/build/BUILD/postgresql-13.1/src/port'

So from my point of view, pg_config_paths.h header file finished
*after* it was used to compile code.

This issue is probably caused by parallel build because sometimes build succeed.

Complete build log: log <https://fjanus.fedorapeople.org/postgresql/build.log&gt;

Regards,

-Filip-

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Filip Janus (#1)
Re: Possible dependency issue in makefile

Filip Janus <fjanus@redhat.com> writes:

I am building libecpg 13.1 but 13.3 behaves in the same manner and my build
fails with:
...
Complete build log: log <https://fjanus.fedorapeople.org/postgresql/build.log&gt;

It looks like you're just running configure and then trying to do this:

/usr/bin/make -O -j40 V=1 VERBOSE=1 -C src/interfaces/ecpg

which is probably not a great idea. It bypasses the .NOTPARALLEL:
in src/Makefile, which would normally ensure that src/port gets
built before src/interfaces. If you want to not build the entire
system, I think a minimal approach would be to make src/port,
src/common, src/interfaces/libpq, then src/interfaces/ecpg, in series.

As-is, it looks like two different sub-makes are recursing to build
pg_config_paths.h concurrently. Since the rule for that is

pg_config_paths.h: $(top_builddir)/src/Makefile.global
echo "#define PGBINDIR \"$(bindir)\"" >$@
echo "#define PGSHAREDIR \"$(datadir)\"" >>$@
...
echo "#define HTMLDIR \"$(htmldir)\"" >>$@
echo "#define MANDIR \"$(mandir)\"" >>$@

it's not too surprising that concurrent builds misbehave. I don't
know of any way to prevent make from doing that other than
sprinkling .NOTPARALLEL around a lot more, which would defeat
your purpose in using -j in the first place.

We could possibly adjust this specific rule to create pg_config_paths.h
atomically (say, write to a temp file and then "mv" it into place), but
I don't have any faith that there's not other similar issues behind
this one. Building ecpg by itself is not a case that we test or consider
supported.

regards, tom lane

#3Filip Janus
fjanus@redhat.com
In reply to: Tom Lane (#2)
Re: Possible dependency issue in makefile

Thanks, for Your advice Tom.
I tried writing to temp file followed by mv, but it didn't bring the
desired effect.
I am going to follow Your minimal approach and I'll build src/port,
src/common, src/interfaces/libpq, then src/interfaces/ecpg, in series.

Regards,

-Filip-

st 4. 8. 2021 v 15:46 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:

Show quoted text

Filip Janus <fjanus@redhat.com> writes:

I am building libecpg 13.1 but 13.3 behaves in the same manner and my

build

fails with:
...
Complete build log: log <

https://fjanus.fedorapeople.org/postgresql/build.log&gt;

It looks like you're just running configure and then trying to do this:

/usr/bin/make -O -j40 V=1 VERBOSE=1 -C src/interfaces/ecpg

which is probably not a great idea. It bypasses the .NOTPARALLEL:
in src/Makefile, which would normally ensure that src/port gets
built before src/interfaces. If you want to not build the entire
system, I think a minimal approach would be to make src/port,
src/common, src/interfaces/libpq, then src/interfaces/ecpg, in series.

As-is, it looks like two different sub-makes are recursing to build
pg_config_paths.h concurrently. Since the rule for that is

pg_config_paths.h: $(top_builddir)/src/Makefile.global
echo "#define PGBINDIR \"$(bindir)\"" >$@
echo "#define PGSHAREDIR \"$(datadir)\"" >>$@
...
echo "#define HTMLDIR \"$(htmldir)\"" >>$@
echo "#define MANDIR \"$(mandir)\"" >>$@

it's not too surprising that concurrent builds misbehave. I don't
know of any way to prevent make from doing that other than
sprinkling .NOTPARALLEL around a lot more, which would defeat
your purpose in using -j in the first place.

We could possibly adjust this specific rule to create pg_config_paths.h
atomically (say, write to a temp file and then "mv" it into place), but
I don't have any faith that there's not other similar issues behind
this one. Building ecpg by itself is not a case that we test or consider
supported.

regards, tom lane