Thread

  1. Possible dependency issue in makefile

    Filip Janus <fjanus@redhat.com> — 2021-08-04T07:50:31Z

    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>
    
    Regards,
    
        -Filip-
    
  2. Re: Possible dependency issue in makefile

    Tom Lane <tgl@sss.pgh.pa.us> — 2021-08-04T13:46:15Z

    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>
    
    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
    
    
    
    
  3. Re: Possible dependency issue in makefile

    Filip Janus <fjanus@redhat.com> — 2021-08-05T08:12:56Z

    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:
    
    > 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>
    >
    > 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
    >
    >
    >