[Gc]: Dependency tracking for configuration macros

Petter Urkedal urkedal at nbi.dk
Fri Oct 9 16:22:34 PDT 2009


On 2009-10-09, Andreas Tobler wrote:
> Petter Urkedal wrote:
> > 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
> 
> Currently the system compiler: gcc version 4.0.1 (Apple Inc. build 5493)
> But I can try with a self built one tomorrow. (Need to build them first)

Given that it's GCC and not an ancient version, it seems like an
implausible cause.  If you haven't done so, I'd try to compare the gcc
command lines with that of a working system first.  If the command lines
are different you could also try to regenerate the makefiles with the
most recent autotoolchain, in case there are fixes.  If the command
lines are essentially the same, the next step could be to try to run the
commands manually on both system with exactly the same options (incl.
-M*) and compare the .Plo outputs.


More information about the Gc mailing list