On Mon, Apr 04, 2011 at 02:13:36AM -0500, Yaakov (Cygwin/X) wrote: >On Mon, 2011-04-04 at 00:56 -0500, Yaakov (Cygwin/X) wrote: >> No, I duplicated this on Linux as well (after I tracked down a cocom >> RPM), but that did make me think of other possibilities. The difference >> seems to be if you pass an absolute or relative path to the top-level >> configure script; only in the latter does it fail as I described. I >> presume you've been using an absolute path? > >This is definitely the problem. If configure is called with a relative >path (e.g. mkdir build; cd build; ../configure ...), then srcdir is also >defined relative, which is then used in VPATH. But when Makefile.common >is include()d, it overrides srcdir to an absolute path, the value of >which is used later in the $(srcdir)/devices.cc: rule. Since the new >value of srcdir isn't identical to the old (although functionally the >same), make doesn't find the dependency automatically. > >I see two solutions: > >1) move the VPATH definition to after the Makefile.common inclusion, OR >2) change the $(srcdir)/devices.cc: rule to @srcdir@/devices.cc. > >Your preference?
The last time I reported that I was using relative paths in the gcc/binutils/winsup directory I was told "Don't do that. It isn't supported." However, I'll move the call to Makefile.common earlier in Makefile.in. Thanks for the analysis. cgf
