Hmmm...I think I need more coffee...I hit transmit too soon and I'm now not sure I see the config.status issue at all :(
On 2/13/07, deckrider <[EMAIL PROTECTED]> wrote:
On 2/12/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Hello Jason, all, > > * Jason Kraftcheck wrote on Mon, Feb 12, 2007 at 07:34:25PM CET: > > > > This looks like a race to create .libs by concurrent libtool processes. > > Nope. Unless the output is mangled in order, the link commands are > simply issued too early. This is what I thought at first. However, another characteristic is that I am _not_ able to cause an error through these steps: configure make make clean PARALLEL=4 export PARALLEL while make -P ; do make clean ; done In other words, _after_ config.status runs, it is safe to run in parallel. But as you can see in the log, config.status is at times running _again_ with HP make. Thus, if I do this in Makefile.am, I also don't see errors: $(PROGRAMS): Makefile We also have a very large project, but have not seen this problem in it. Perhaps the reason is that it has a lot of $(BUILT_SOURCES) to generate before it starts compiling and linking, and by the time it compiles and links, config.status has already finished running. But I am not certain of my conclusions ... just reporting some additional behavior that I've seen. > Looks like a bug in HP-UX make. Haven't > reproduced it yet, though. My guess is it doesn't understand inference > rules with separated dependencies, when targets and/or dependencies are > in subdirectories. But I haven't been able to confirm this either. > > > Perhaps libtool should check again to see if the directory exists if mkdir > > fails? > > It does already. > > Cheers, > Ralf
-- ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html
