Skip site navigation (1) Skip section navigation (2)

Re: ecpg-related build failure with make 3.82

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: ecpg-related build failure with make 3.82
Date: 2011-10-28 19:02:22
Message-ID: 27794.1319828542@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Oct 28, 2011 at 1:24 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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.

In that case it's a make bug, which you should file with the proper
authorities.  I could believe it was our problem if it manifested when
starting from src/interfaces/ecpg, but none of the higher-level
makefiles know anything about subdirectories of ecpg.

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

Well, on closer inspection, running ecpg/include/Makefile is sufficient
to rebuild ecpg_config.h, apparently because of rules in
Makefile.global.  Now that I look at it, I bet we could fix that part
with some additions to the dependency rules in ecpg/Makefile.  But it
doesn't seem related at all to the preproc problem.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2011-10-28 19:27:36
Subject: Re: So, is COUNT(*) fast now?
Previous:From: Robert HaasDate: 2011-10-28 18:51:28
Subject: Re: So, is COUNT(*) fast now?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group