"David Highley wrote:"
>
> "Philip Guenther wrote:"
> >
> > Looking backwards, this rule from your top level makefile:
> >
> > > $(INF_DIST_SVCS_OBJS): $(DIRS)
> >
> > seems bogus, given that $(INF_DIST_SVCS_OBJS) is a list of objects in
> > directories _below_ the list of directories in $(DIRS
"Philip Guenther wrote:"
>
> Looking backwards, this rule from your top level makefile:
>
> > $(INF_DIST_SVCS_OBJS): $(DIRS)
>
> seems bogus, given that $(INF_DIST_SVCS_OBJS) is a list of objects in
> directories _below_ the list of directories in $(DIRS). The top level
> make may recurse, then
Looking backwards, this rule from your toplevel makefile:
> $(INF_DIST_SVCS_OBJS): $(DIRS)
seems bogus, given that $(INF_DIST_SVCS_OBJS) is a list of objects in
directories _below_ the list of directories in $(DIRS). The toplevel
make may recurse, then on popping back out see that the *SOURCE
DI
"Philip Guenther wrote:"
>
> On Thu, Oct 7, 2010 at 9:22 AM, David Highley
> wrote:
> ...
> > Let us just cut to the essence of the issue we are running into, how do
> > target prerequisites get processed in version 3.81 of make?
> >
> > Example:
> > $(LIBRARY): $(INF_DIST_SVCS_OBJS)
> >
> > $(IN
On Thu, Oct 7, 2010 at 9:22 AM, David Highley
wrote:
...
> Let us just cut to the essence of the issue we are running into, how do
> target prerequisites get processed in version 3.81 of make?
>
> Example:
> $(LIBRARY): $(INF_DIST_SVCS_OBJS)
>
> $(INF_DIST_SVCS_OBJS): $(DIRS)
>
> $(DIRS):
>
> .PHO
OK, after more testing I now believe that I have leaped to the "Island
of Conclusions in the Sea of Wisdom" more than once, or more accurately
"I have fallen into the unconscious incompetent syndrome."
Let us just cut to the essence of the issue we are running into, how do
target prerequisites get
Paul,
Since yesterday was very hectic I decided to go back and re-run all my
testing for the intermittent parallel build failure. I have now
concluded that Red Hat 5.4 also does not work so the last know working
version was a 3.79-x version which came on Red Hat 3 Update 8. I did
retest the latest
"Paul Smith wrote:"
>
> On Tue, 2010-10-05 at 11:07 -0700, David Highley wrote:
> > The latest version of Fedora 13 does not have a 3.82 verion of make so
> > the only way to test would be to build from source which I can do. It
> > may take me a while since were pretty busy right now.
>
> Buildi
On Tue, 2010-10-05 at 11:07 -0700, David Highley wrote:
> The latest version of Fedora 13 does not have a 3.82 verion of make so
> the only way to test would be to build from source which I can do. It
> may take me a while since were pretty busy right now.
Building make from source is pretty trivi
"Paul Smith wrote:"
>
> On Tue, 2010-10-05 at 10:23 -0700, David Highley wrote:
> > Good news, it appears that Red Hat 5.4 with GNU make 3.81-3 fixes the
> > issue we are running into. Now to find the right version for Cygwin.
>
> I'd be really interested to know whether the current latest releas
On Tue, 2010-10-05 at 10:23 -0700, David Highley wrote:
> Good news, it appears that Red Hat 5.4 with GNU make 3.81-3 fixes the
> issue we are running into. Now to find the right version for Cygwin.
I'd be really interested to know whether the current latest release of
GNU make (3.82) has this pro
"David Highley wrote:"
>
> "Edward Welbourne wrote:"
> >
> > > Every time the subject of cache comes up its because they are always
> > > wrong.
> >
> > well, this *is* a *bug* list - every time anything comes up here, it's
> > because someone's found a bug in it ! The vast amount of the time
>
"Edward Welbourne wrote:"
>
> > Every time the subject of cache comes up its because they are always
> > wrong.
>
> well, this *is* a *bug* list - every time anything comes up here, it's
> because someone's found a bug in it ! The vast amount of the time
> that the cache works just fine and make
> Every time the subject of cache comes up its because they are always
> wrong.
well, this *is* a *bug* list - every time anything comes up here, it's
because someone's found a bug in it ! The vast amount of the time
that the cache works just fine and makes builds faster is (quite
properly) not n
"Edward Welbourne wrote:"
>
> > it appears from running make with the debug option that the
> > top level make does not see the object file created by the lower level
> > make in the time when it checks the dependencies for the library.
>
> sounds a *lot* like an issue with make's caching of stat
> it appears from running make with the debug option that the
> top level make does not see the object file created by the lower level
> make in the time when it checks the dependencies for the library.
sounds a *lot* like an issue with make's caching of stat information;
if the uppper make has lo
We have a build process that had no issues in the past when we were on
Red Hat 3 and an older version of Cygwin. Now our core library builds
fail to link intermittently on a rebuild when building on Red Hat 5.1
and Windows using Cygwin make and Windows compilers. I did some digging
into it today a
17 matches
Mail list logo
