From: Anichini, Steve (Sanichini_at_[hidden])
Date: 2002-12-18 14:52:56
The problem is in execnt.c, where bjam creates temp files used in executing
// ~ line 474
if( !cmdtab[ slot ].tempfile )
if( !( tempdir = getenv( "TEMP" ) ) &&
!( tempdir = getenv( "TMP" ) ) )
tempdir = "\\temp";
cmdtab[ slot ].tempfile = malloc( strlen( tempdir ) + 14 );
sprintf( cmdtab[ slot ].tempfile, "%s\\jamtmp%02d.bat",
tempdir, slot );
// end code
If multiple processes are running, these temp files will collide.
As an unrelated issue, I've found when the TEMP or TMP env vars contain
paths with spaces it can cause problems.
I've got a patch that fixes both of these problems, David, I will send you
the patch directly.
> -----Original Message-----
> From: David Abrahams [mailto:dave_at_[hidden]]
> Sent: Wednesday, December 18, 2002 11:54 AM
> To: jamboost_at_[hidden]
> Subject: Re: [jamboost] bjam failure when two instances running?
> Beman Dawes <bdawes_at_[hidden]> writes:
> > I just had an odd failure - the full boost regression tests
> were running,
> > and I tried to run some separate filesystem tests at the
> same time (in a
> > different Win 32 command window).
> > Four of the boost regression test status/bin/xxx.test
> directories were
> > mistakenly created in the boost-root/libs/filesystem directory!
> That's very odd. Are you sure you don't mean that it was crating
> directories in which to build the compiled part of the filesystem
> > Both runs showed unexpected errors.
> > Afterwards, I reran the tests, being careful not to invoke
> both at the same
> > time, and they then ran correctly.
> > Note that both bjam runs are done from batch files.
> > So on the surface, it looks like there may be some
> interaction between two
> > bjam instances running in completely different processes.
> > Is that a known issue?
> I don't understand the symptoms you're seeing at all. On the other
> hand, I wouldn't expect it to work _right_ unless you used
> ALL_LOCATE_TARGET to move the build tree of one or both of the tests.
> Remember, bjam needs to evaluate file dependency information to decide
> what's out-of-date and needs to be rebuilt. If something (like
> another test build) comes along and changes the parts of the
> filesystem which participate in the dependency graph, you could
> certainly see some unexpected results.
> David Abrahams
> dave_at_[hidden] * http://www.boost-consulting.com
> Boost support, enhancements, training, and commercial distribution
> ------------------------ Yahoo! Groups Sponsor
> Get 128 Bit SSL Encryption!
> To unsubscribe from this group, send an email to:
> Your use of Yahoo! Groups is subject to
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk