Conference smurf::buildhelp

Date Of Receipt: 	 5-AUG-1994 07:31:59.16
From: 	WASTED::"[email protected]" "05-Aug-1994 0730"
To: 	[email protected]
CC: 	pzl%peewee [email protected]
Subj: 	read_advfs Undefined build prob on goldminos.nightly

Hi,

I reported the problem below two days ago and have not heard back
even a responce. So I am repeating it here. I am pretty much dead
in the water without being able to do a single build. Please look
into this problem soon!

When a "build" (in src/kernel) is attempted using our brand new
goldminos.nightly backing tree, then the following error
message appears within about a minute or so:
th dec/sas/alpha/. && cd dec/sas/alpha &&  exec make 'RELEASE_OPTIONS=-idfile 
`genloc /src/setup/osf1_idlist`'    MAKEFILE_PASS=BASIC dopass_all
echo "char *version=\""`date`"\";" > version.c
/usr/sde/osf1/build/goldminos.nightly/tools/alpha_OSF1/alpha/acc/cc   -std0 -EL 
-c  -DBSD44 -DMSG -DNLS -D__WCHAR_T_LEN=4 -Wf,-wchar32  -DMACH -DCMU -DOSF  
-Dalpha -D__alpha__ -D__alpha  -Dunix -D__unix__      -O2 -Olimit 5000    -O1   
-no_excpt -Wco,-nofloat -Wb,-static    -I  `genpath -I.` `genpath  -I.. 
-I../../../../usr/sbin `  -I/u1/osb/export/alpha/usr/include 
-I/usr/sde/osf1/build/goldminos.nightly/export/alpha/usr/include  version.c
ld -non_shared -s -N -T 20010000 -o osf_boot csu.alpha.SECONDARY.o 
prom.SECONDARY.o libasm.SECONDARY.o  switch2pal.o mach_boot.o sys.LSECONDARY.o 
io.LABELS.o  loadmappedimage.SECONDARY.o map.o copy.SECONDARY.o get.o  prf.o 
libc.SECONDARY.o divide.SECONDARY.o  loadimage.SECONDARY.o version.o
ld:
Error: Undefined:
read_advfs
open_advfs
*** Exit 1
Stop.
*** Exit 1
Stop.
*** Exit 1
Stop.

P. S.
It should be easy to verify this problem. Just do a "workon your_sb",
then do a "resb goldminos.nightly" using the brand new backing tree
(here at "unx"). Then use any build which sets the "BASIC dopass_all"
PASS variable such as "build setup BINARY" or just plain "build" while
in in sandbox directory src/kernel. Since this backing tree is brand
new (07/02/94), it is possible that it might be a local problem only
since I would expect that other people should be having this problem
if not. Another possibility is that no one except me has tried a
"dopass_all" build (on the kernel) since the problem first appeared
since that kind of build is normally done only "initially" or when
something global (such as an include file) changes.

Floyd,

Date Of Receipt: 	 5-AUG-1994 07:34:41.94
From: 	QUARRY::"[email protected]" "05-Aug-1994 0732"
To: 	[email protected]
CC: 	pzl%peewee [email protected]
Subj: 	read_advfs Undefined build prob on goldminos.nightly

Hi,

I reported the problem below two days ago and have not heard back
even a responce. So I am repeating it here. I am pretty much dead
in the water without being able to do a single build. Please look
into this problem soon!

When a "build" (in src/kernel) is attempted using our brand new
goldminos.nightly backing tree, then the following error
message appears within about a minute or so:
th dec/sas/alpha/. && cd dec/sas/alpha &&  exec make 'RELEASE_OPTIONS=-idfile 
`genloc /src/setup/osf1_idlist`'    MAKEFILE_PASS=BASIC dopass_all
echo "char *version=\""`date`"\";" > version.c
/usr/sde/osf1/build/goldminos.nightly/tools/alpha_OSF1/alpha/acc/cc   -std0 -EL 
-c  -DBSD44 -DMSG -DNLS -D__WCHAR_T_LEN=4 -Wf,-wchar32  -DMACH -DCMU -DOSF  
-Dalpha -D__alpha__ -D__alpha  -Dunix -D__unix__      -O2 -Olimit 5000    -O1   
-no_excpt -Wco,-nofloat -Wb,-static    -I  `genpath -I.` `genpath  -I.. 
-I../../../../usr/sbin `  -I/u1/osb/export/alpha/usr/include 
-I/usr/sde/osf1/build/goldminos.nightly/export/alpha/usr/include  version.c
ld -non_shared -s -N -T 20010000 -o osf_boot csu.alpha.SECONDARY.o 
prom.SECONDARY.o libasm.SECONDARY.o  switch2pal.o mach_boot.o sys.LSECONDARY.o 
io.LABELS.o  loadmappedimage.SECONDARY.o map.o copy.SECONDARY.o get.o  prf.o 
libc.SECONDARY.o divide.SECONDARY.o  loadimage.SECONDARY.o version.o
ld:
Error: Undefined:
read_advfs
open_advfs
*** Exit 1
Stop.
*** Exit 1
Stop.
*** Exit 1
Stop.

P. S.
It should be easy to verify this problem. Just do a "workon your_sb",
then do a "resb goldminos.nightly" using the brand new backing tree
(here at "unx"). Then use any build which sets the "BASIC dopass_all"
PASS variable such as "build setup BINARY" or just plain "build" while
in in sandbox directory src/kernel. Since this backing tree is brand
new (07/02/94), it is possible that it might be a local problem only
since I would expect that other people should be having this problem
if not. Another possibility is that no one except me has tried a
"dopass_all" build (on the kernel) since the problem first appeared
since that kind of build is normally done only "initially" or when
something global (such as an include file) changes.

Floyd,

Date Of Receipt: 	 5-AUG-1994 07:38:21.18
From: 	QUARRY::"[email protected]" "05-Aug-1994 0736"
To: 	[email protected]
CC: 	[email protected], [email protected]
Subj: 	read_advfs Undefined build prob on goldminos.nightly

Hi,

I reported the problem below two days ago and have not heard back
even a responce. So I am repeating it here. I am pretty much dead
in the water without being able to do a single build. Please look
into this problem soon!

When a "build" (in src/kernel) is attempted using our brand new
goldminos.nightly backing tree, then the following error
message appears within about a minute or so:
th dec/sas/alpha/. && cd dec/sas/alpha &&  exec make 'RELEASE_OPTIONS=-idfile 
`genloc /src/setup/osf1_idlist`'    MAKEFILE_PASS=BASIC dopass_all
echo "char *version=\""`date`"\";" > version.c
/usr/sde/osf1/build/goldminos.nightly/tools/alpha_OSF1/alpha/acc/cc   -std0 -EL 
-c  -DBSD44 -DMSG -DNLS -D__WCHAR_T_LEN=4 -Wf,-wchar32  -DMACH -DCMU -DOSF  
-Dalpha -D__alpha__ -D__alpha  -Dunix -D__unix__      -O2 -Olimit 5000    -O1   
-no_excpt -Wco,-nofloat -Wb,-static    -I  `genpath -I.` `genpath  -I.. 
-I../../../../usr/sbin `  -I/u1/osb/export/alpha/usr/include 
-I/usr/sde/osf1/build/goldminos.nightly/export/alpha/usr/include  version.c
ld -non_shared -s -N -T 20010000 -o osf_boot csu.alpha.SECONDARY.o 
prom.SECONDARY.o libasm.SECONDARY.o  switch2pal.o mach_boot.o sys.LSECONDARY.o 
io.LABELS.o  loadmappedimage.SECONDARY.o map.o copy.SECONDARY.o get.o  prf.o 
libc.SECONDARY.o divide.SECONDARY.o  loadimage.SECONDARY.o version.o
ld:
Error: Undefined:
read_advfs
open_advfs
*** Exit 1
Stop.
*** Exit 1
Stop.
*** Exit 1
Stop.

P. S.
It should be easy to verify this problem. Just do a "workon your_sb",
then do a "resb goldminos.nightly" using the brand new backing tree
(here at "unx"). Then use any build which sets the "BASIC dopass_all"
PASS variable such as "build setup BINARY" or just plain "build" while
in in sandbox directory src/kernel. Since this backing tree is brand
new (07/02/94), it is possible that it might be a local problem only
since I would expect that other people should be having this problem
if not. Another possibility is that no one except me has tried a
"dopass_all" build (on the kernel) since the problem first appeared
since that kind of build is normally done only "initially" or when
something global (such as an include file) changes.

Floyd,

Date Of Receipt: 	 5-AUG-1994 09:12:46.19
From: 	FLUME::jmcg "Jim McGinness"
To: 	[email protected]
CC: 	buildhelp@DEC:.zko.flume, [email protected], [email protected]
Subj: 	Re:  read_advfs Undefined build prob on goldminos.nightly

You didn't mention blowing away your obj tree after doing the resb.
If you had recently done a sandbox build against the old backing tree,
your obj tree will be "newer" than source files in the new backing
tree.  Is it possible that make skipped rebuilding sys.o?

I am attempting to duplicate your problem, but it looks like
it will take a couple of hours.

	-- jmcg

Date Of Receipt: 	 5-AUG-1994 10:47:02.64
From: 	FLUME::jmcg "Jim McGinness"
To: 	[email protected]
CC: 	buildhelp@DEC:.zko.flume
Subj: 	Re: read_advfs Undefined build prob on goldminos.nightly

Deleting the "machine" directories is definitely not sufficient.  It's
.o, .h, and .c files in the rest of the obj/alpha/kernel hierarchy
that are likely to cause problems.  Files there effectively "hide" files
in your sandbox and in the backing tree.  When you resb, I believe it's
necessary to exterminate *all* of the files in the obj hierarchy and,
if you're using mklinks, you need to remake all the links.  I'm not
a frequent user of resb -- partly because of this belief of mine.
I tend to make a new sandbox for each new thing.

My sandbox build against goldminos is still going.  It's getting
errors that I wouldn't expect, but doesn't get the one you saw.  We
know that the nightly build doesn't see a problem, but that may be
subtly different from a sandbox build.

	-- jmcg