[Gc]: Dependency tracking for configuration macros

Andreas Tobler andreast-list at fgznet.ch
Fri Oct 9 11:53:15 PDT 2009


Petter Urkedal wrote:
> On 2009-10-08, Andreas Tobler wrote:
>> Ivan Maidanski wrote:
>>> Hi!
>>> Petter Urkedal <urkedal at nbi.dk> wrote:
>>>> diff --git a/configure.ac b/configure.ac
>>>> index f1dcd65..ff400f3 100644
>>>> --- a/configure.ac
>>>> +++ b/configure.ac
>>>> @@ -24,7 +24,7 @@ AC_CANONICAL_TARGET
>>>>  AC_PREREQ(2.53)
>>>>  AC_REVISION($Revision: 1.51 $)
>>>> -AM_INIT_AUTOMAKE([foreign dist-bzip2 subdir-objects nostdinc])
>>>> +AM_INIT_AUTOMAKE([foreign dist-bzip2 nostdinc])
>>>>  AM_CONFIG_HEADER([include/private/config.h])
>>> I've checked it in (and regenerated).
>> 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 \

The sparc one works correctly since it has the leading 

I could not find out so far what the cause is for that.


More information about the Gc mailing list