Re: ecpg-related build failure with make 3.82

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: ecpg-related build failure with make 3.82
Date: 2011-10-28 18:33:25
Message-ID: CA+TgmoYxQdr-YZ9YGGhkTXCW23Ct5NCtp1EwLS55k9jKxGs+fw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 28, 2011 at 1:24 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On my Fedora 14 box, make -j3 fails.  I think the below is the
>> relevant portion of the output.  This has a passing similarity to bug
>> 5665, but I can't for the life of me see what the problem is here.
>> parer.o depends on preproc.h, which depends on preproc.c; therefore,
>> parser.o should not be built until preproc.c has been built, but
>> that's exactly what make is doing.
>
> I tried to reproduce this on my own Fedora 14 box, and couldn't.
> I cd'd to src/interfaces/ecpg/preproc and did several repetitions of
>
>        make maintainer-clean
>        make -j
>
> and every time, make carefully waited until bison was done before
> launching the compiles of preproc.o, parser.o, and the other files
> that are declared to depend on preproc.h.

I see the same thing. But when I do make -j3 at the toplevel, it
bombs out as described before.

> I *can* reproduce failures if I do the same thing one directory level
> up, in src/interfaces/ecpg.  But those are caused by the other sub-makes
> not waiting for include/ecpg_config.h to get built.  Fixing that is
> beyond my level of make-fu.

I can also reproduce this problem. I think this one does not occur on
a fresh build because ecpg_config.h is created by configure and is
only removed by make maintainer-clean. If I make maintainer-clean in
src/interfaces/ecpg, then rerun config.status, and then do make -j it
succeeds. However, if I repeat those steps from one level further up,
in src/interfaces, then it bombs out as described in my OP.

> This is with make-3.82-3.fc14.x86_64 ...

That's the same make I'm using here.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-10-28 18:37:43 Re: TOAST versus VACUUM, or "missing chunk number 0 for toast value" identified
Previous Message Robert Haas 2011-10-28 17:58:51 Re: So, is COUNT(*) fast now?