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 <t...@sss.pgh.pa.us> napsal:

> Filip Janus <fja...@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
>
>
>

Reply via email to