[Gc]: Dependency tracking for configuration macros

Andreas Tobler andreast-list at fgznet.ch
Sat Oct 10 13:31:08 PDT 2009


Petter Urkedal wrote:
> 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.

Hm, confused. From my point of view it has nothing to do with gcc. The 
.deps/atomic_ops.Plo gets created during the configure stage, and there 
gcc is only invoked for conftests. So I guess there must be some other 
magic.

For the moment this issue is too expensive (in terms of time) for me to 
investigate on. I might try later.

Thanks,
Andreas



More information about the Gc mailing list