[Gc]: Dependency tracking for configuration macros
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: *** 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