[Gc]: Dependency tracking for configuration macros

Petter Urkedal urkedal at nbi.dk
Fri Oct 9 12:38:52 PDT 2009


On 2009-10-09, Andreas Tobler wrote:
> Petter Urkedal wrote:
> > On 2009-10-08, Andreas Tobler wrote:
> >> This patch breaks builds outside the source directory. When you have the 
> >> build inside a separate objdir which is on the same level as the src 
> >> directory the build breaks with the following message:
> >>
> >> make[1]: *** No rule to make target `atomic_ops.c', needed by 
> >> `atomic_ops.lo'.  Stop.
> >> make: *** [all-recursive] Error 1
> > 
> > I can't reproduce this, but I'm not sure if I understood you correctly.
> > I tried the following from the source directory
> > 
> > 	$ mkdir _build
> > 	$ cd _build
> > 	$ ../configure
> > 	$ make
> > 
> > as well as putting _build one level above.  Usually I build from a
> > completely different directory, which also works.  Can you list the
> > commands to reproduce the problem, starting from the original sources
> > and an empty build directory?  What's your environment?  Do you have any
> > idea yourself about the cause?  I'm wondering why "make" looks for
> > atomic_ops.c when the file is listed as libatomic_ops/src/atomic_ops.c
> > in Makefile.am.
> 
> Well, it must be something darwin specific, or my environment. I can not 
> reproduce the failure neither on sparc-solaris nor under x86_64 linux.
> 
> The tree I build from is a fresh co, w/o modifications from my side.
> Like you describe above.
> 
> The thing I found so far is, that .deps/atomic_ops.Plo does not contain 
> the right path names:
> 
> darwin .deps/atomic_ops.Plo:
> 
> atomic_ops.lo atomic_ops.o: atomic_ops.c \
> ....
> 
> sparc .deps/atomic_ops.Plo:
> 
> atomic_ops.lo atomic_ops.o: ../bdwgc/libatomic_ops/src/atomic_ops.c \
> ...

Which compiler do you use?  There is an analogue dependency hard-coded
in Makefile.in

    atomic_ops.lo: libatomic_ops/src/atomic_ops.c

which contains the actual rule.  (This one seems to rely on VPATH, since
it does not list the build directory.)  This rule has three-cases
conditioned by substitution of comment characters.  Your Makefile
probably has the first case enabled (@am__fastdepCC_TRUE@), so the
compiler generates the dependencies.  I'm thinking maybe it strips off
paths from dependency rules.  If that's the case, configure should
probably decide to not use the fastdepCC case.


More information about the Gc mailing list