[Gc]: Dependency tracking for configuration macros

Andreas Tobler andreast-list at fgznet.ch
Fri Oct 9 13:18:26 PDT 2009

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)

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

Interesting! Was not aware of that.

Thanks for helping out here!


More information about the Gc mailing list