[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference smurf::buildhelp

Title:USG buildhelp questions/answers
Moderator:SMURF::FILTER
Created:Mon Apr 26 1993
Last Modified:Mon Jan 20 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2763
Total number of notes:5802

353.0. "problems with builds in our sandboxes" by SMURF::FILTER (Automatic Posting Software - mail to flume::puck) Wed Sep 29 1993 11:53

Date Of Receipt: 	29-SEP-1993 10:29:22.59
From: 	QUARRY::tomp "Tom Peterson USG  29-Sep-1993 1029"
To: 	odehelp@DEC:.zko.quarry, brett@DEC:.zko.quarry, jmcg@DEC:.zko.quarry
CC: 	whatde@DEC:.zko.quarry
Subj: 	problems with builds in our sandboxes

I'm seeing what seems to be an ODE problem when doing builds in my
sandbox backed by agosminor.nightly.  The problem is that sources
which have been moved and/or defuncted are being pulled from one of
the older backing trees instead of the new location in local sandbox
or immediate backing tree.  Some mail was sent by Neil O'Brian last
week about this problem & it was suggested that it might be due to the
network glitch last week.  I don't think this is the case.

I just did a build of all the libc's in my sandbox last night and
ended up getting itrunc.o from

/usr/sde/alpha/build/alpha.bl012/src/usr/ccs/lib/libc/itrunc.c

instead of from my sandbox (a softlink) or the backing tree
agosminor.nightly in

./src/usr/ccs/lib/libc/alpha/itrunc.c

This file was moved from .../libc to .../libc/alpha and the
Makefile/machdep.mk's accurately reflect this.  Unfortunately, I did
not save my full build log, so I'm not sure how many other files were
erroneously taken from older backing trees as well.

Neil also saw this problem recently with a header being taken from an
alternate location in an older backing tree when he had a header of
the same name in the appropriate place in his own export area.

This problem does not show up in the nightly builds, apparently because
they do not have the same multiple backing tree dependencies that we
average users do.  However, this is a serious problem.  We have been
trying to build libc's to check for performance/size improvements and
end up getting something that has bogus modules or headers in it.  If
we don't notice (and often times it isn't obvious) that some wrong
sources are getting pulled in, our results do not accurately reflect
our changes.  These libc's then get tested for performance & who knows
how far off the results really are.  The same goes for standards
testing.

Can someone pls look into this?

thanks,
- Tom

T.RTitleUserPersonal
Name
DateLines