[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

56.0. "Why does a file that builds in a sandbox break the nightly build?" by SMURF::FILTER (Automatic Posting Software - mail to flume::puck) Tue May 18 1993 16:45

Date Of Receipt: 	17-MAY-1993 10:52:26.77
From: 	ABYSS::werme "Eric Werme USSG"
To: 	abyss::buildhelp
CC: 	
Subj: 	Why does a file that builds in a sandbox break the nightly build?

I received the following from Grant today.  One of my changes was to
change routine freefid() from untyped (i.e. int) to void.  However, I
did not know that someone else recently created a header file that
has function prototypes for all routines in vfs, including freefid().

However, the sandbox build ran fine, despite seeing this line from
sys/vfs_proto.h:

	extern int freefid(struct flino * );

As you can see below, the nightly build rejected it.  The header file *is*
being read by the sandbox build, if I say:

	extern voidfoo freefid(struct flino * );

I do get a syntax error.   My BINARY/Makefile is the same RCS rev as is
in the backing tree, I don't think there is a more recent one.  The command
line options of both compiles look nearly identical:

--- build
/usr/build/osf1/agosmaint.bld/tools/alpha/cc/cc
	-c -O2 -g3  -DLANGUAGE_C -g3 -G 4 -I -I. -I.. -I../include
	-DIDENT=BINARY -DDEC3000_300 -DDEC3000_500 -DDEC7000 -DDEC4000 -DALPHAADU
	-DSWAPTYPE=1 -DRELEASE='"'9.0'"' -DVERSION='"'0'"' -DMACH -DOSF -DCOMPAT_43
	-DPACKETFILTER -DUFS -DRT -DKERNEL -D_KERNEL -D_BSD -signed -no_excpt
	-Wb,-static -Wco,-nofloat -Olimit 1000 -D__alpha -Umips -UMIPS -DBINARY
	../../../../src/kernel/vfs/vfs_flock.c

--- sandbox
/usr/sde/osf1/build/agosmaint.nightly/tools/alpha/cc/cc
	-c -O2 -g3  -DLANGUAGE_C -g3 -G 4 -I -I. -I.. -I../include
	-DIDENT=BINARY -DDEC3000_300 -DDEC3000_500 -DDEC7000 -DDEC4000 -DALPHAADU 
	-DSWAPTYPE=1 -DRELEASE='"'9.0'"' -DVERSION='"'0'"' -DMACH -DOSF -DCOMPAT_43 
	-DPACKETFILTER -DUFS -DRT -DKERNEL -D_KERNEL -D_BSD -signed   -no_excpt
	-Wb,-static -Wco,-nofloat -Olimit 1000 -D__alpha -Umips -UMIPS -DBINARY
	/usr/sde/osf1/build/agosmaint.nightly/src/kernel/vfs/vfs_flock.c

So what gives?

	-Ric

------- Forwarded Message

To: werme
Cc: jac, kenny, reng, barrys
Subject: It appears that your submit of vfs_flock.c has broken the MAINT build
Date: Mon, 17 May 93 09:59:04 EDT
From: Grant Van Dyck <vandyck>



See below:

 * $Log: vfs_flock.c,v $
 * Revision 4.2.9.6  1993/05/14  19:54:10  Eric_Werme
 *      VREF vnodes on first lock, vrele on last unlock.  rpc.lockd can close
 *      locked files and that would leave free vnodes with locks held.
 *      [1993/05/14  19:52:22  Eric_Werme]


/usr/build/osf1/agosmaint.bld/tools/alpha/cc/cc  -c -O2 -g3  -DLANGUAGE_C -g3 -G
 4 -I -I. -I.. -I../include -DIDENT=BINARY -DDEC3000_300 -DDEC3000_500 -DDEC7000
 -DDEC4000 -DALPHAADU -DSWAPTYPE=1 -DRELEASE='"'9.0'"' -DVERSION='"'0'"' -DMACH
- -DOSF -DCOMPAT_43 -DPACKETFILTER -DUFS -DRT -DKERNEL -D_KERNEL -D_BSD -signed
- -no_excpt -Wb,-static -Wco,-nofloat -Olimit 1000 -D__alpha -Umips -UMIPS -DBINAR
Y ../../../../src/kernel/vfs/vfs_flock.c
/usr/build/osf1/agosmaint.bld/tools/alpha/cc/usr/lib/cmplrs/cc/cfe: Error: ../..
/../../src/kernel/vfs/vfs_flock.c, line 402: redeclaration of 'freefid'; previou
s declaration at line 67 in file '../include/sys/vfs_proto.h'
 void freefid(flip)
 -----^
/usr/build/osf1/agosmaint.bld/tools/alpha/cc/usr/lib/cmplrs/cc/cfe: Error: ../..
/../../src/kernel/vfs/vfs_flock.c, line 402: Incompatible function return type f
or this function
 void freefid(flip)
 ------------^
>> *** Exit 1


rm -f vmunix vmunix.sys
loading vmunix.sys
/usr/build/osf1/agosmaint.bld/tools/alpha/cc/ld:
Can't open: vfs_flock.o (No such file or directory)
>> *** Exit 1



	-Grant

------- End of Forwarded Message


T.RTitleUserPersonal
Name
DateLines
56.1buildsSMURF::FILTERAutomatic Posting Software - mail to flume::puckMon Mar 14 1994 11:0514
Date Of Receipt: 	14-MAR-1994 10:04:37.12
From: 	WASTED::haeck "Debby Haeck"
To: 	buildhelp@wasted:zko.dec
CC: 	haeck@wasted:zko.dec
Subj: 	builds

I have read kernel-build-rules, but my question is not answered there.

Is there any way I can start with an empty obj directory and build
just BINARY, FLAMINGO and MYHOST?  

Thanks
Debby

56.2Re: buildsSMURF::FILTERAutomatic Posting Software - mail to flume::puckMon Mar 14 1994 11:0619
Date Of Receipt: 	14-MAR-1994 10:09:43.21
From: 	WASTED::dupuis "Gary Dupuis New CPU Support  14-Mar-1994 1008"
To: 	Debby Haeck <haeck@wasted:zko.dec>
CC: 	buildhelp@wasted:zko.dec, dupuis@wasted:zko.dec
Subj: 	Re: builds

	Debby,
	
	I believe the correct sequence of commands is

	build setup
	build BINARY
	build FLAMINGO
	build MYHOST

	Let me know if that does not work.
	
	Gary

56.3Re: buildsSMURF::FILTERAutomatic Posting Software - mail to flume::puckMon Mar 14 1994 11:0818
Date Of Receipt: 	14-MAR-1994 10:35:47.44
From: 	FLUME::jmcg "Jim McGinness"
To: 	flume::haeck
CC: 	flume::buildhelp
Subj: 	Re:  builds
I haven't tried this myself, yet, but try something like: 	

cd kernel
build setup
build BINARY
build KERNEL_CONFIG=FLAMINGO config vmunix
build KERNEL_CONFIG=MYHOST config vmunix

This skips some depend steps and the other kernels, so it should go faster
and take up less space than what would happen if you just said "build".

	-- jmcg

56.4Re: buildsSMURF::FILTERAutomatic Posting Software - mail to flume::puckMon Mar 14 1994 11:1028
Date Of Receipt: 	14-MAR-1994 11:02:48.55
From: 	FLUME::jmcg "Jim McGinness"
To: 	flume::haeck
CC: 	flume::buildhelp
Subj: 	Re:  builds

I've watched the "build setup" step and it looks like there's another
refinment you can add to try to speed things up:

	cd kernel
	build setup OTHERS=""
	build BINARY
	build KERNEL_CONFIG=FLAMINGO config vmunix
	build KERNEL_CONFIG=MYHOST config vmunix

The FLAMINGO line can equally well be expressed as:

	build FLAMINGO_config FLAMINGO_vmunix

but it loses the parallelism with the MYHOST line where the KERNEL_CONFIG
version is the only one that actually works.  Adding the OTHERS="" to
the "build setup" is intended to supress the automatic configuration
of all the kernels that normally occurs.  Building the FLAMINGO kernel
is not a prerequisite for building MYHOST, by the way, so you could
safely leave that out.

	-- jmcg

56.5Re: buildsSMURF::FILTERAutomatic Posting Software - mail to flume::puckMon Mar 14 1994 12:1432
Date Of Receipt: 	14-MAR-1994 11:41:20.69
From: 	US2RMC::"[email protected]" "Darrell Dunnuck 381-0358 ZKO3-3/T79"
To: 	Debby Haeck <[email protected]>
CC: 	[email protected]
Subj: 	Re: builds

Hi Debby,

>I have read kernel-build-rules, but my question is not answered there.
>
>Is there any way I can start with an empty obj directory and build
>just BINARY, FLAMINGO and MYHOST?  
>
>Thanks
>Debby

The only way I know to do this, other than write a script that runs all 
the commands one at a time, is to change ./src/kernel/Makefile in your 
sandbox to only contain those kernels.  Please don't submit though. :-)

Darrell

% Received: 	from gulch.zk3.dec.com by us2rmc.bb.dec.com (5.65/rmc-22feb94) id AA02200; Mon, 14 Mar 94 11:37:39 -050
	from localhost by gulch.zk3.dec.com; (5.65/1.1.8.2/02Mar94-0809PM) id AA11673; Mon, 14 Mar 1994 11:40:35 -050
% Message-Id: 	<[email protected]>
% To: 	Debby Haeck <[email protected]>
% Cc: 	[email protected]
% Subject: 	Re: builds
% In-Reply-To: 	Your message of "Mon, 14 Mar 94 10:03:50 EST." <[email protected]>
% Date: 	Mon, 14 Mar 94 11:40:35 -0500
% From: 	Darrell Dunnuck 381-0358 ZKO3-3/T79 <[email protected]>
% X-Mts: 	smtp
56.6Re: buildsSMURF::FILTERAutomatic Posting Software - mail to flume::puckMon Mar 14 1994 13:2116
Date Of Receipt: 	14-MAR-1994 12:31:55.16
From: 	FLUME::jmcg "Jim McGinness"
To: 	flume::haeck
CC: 	flume::buildhelp
Subj: 	Re:  builds

Nope, the OTHER="" has no effect.  It doesn't look like it's possible to
supress the configuration of all the CONFIGFILES entries without changing a
Makefile.  This seems like a flaw, since these configurations account for
something like 50-70% of the overall runtime of the setup step.

On the other hand, I think it's required to re-run the config
step after BINARY has built, so you can't drop it from the FLAMINGO step.

	-- jmcg

56.7Re: buildsSMURF::FILTERAutomatic Posting Software - mail to flume::puckMon Mar 14 1994 14:3629
Date Of Receipt: 	14-MAR-1994 14:14:05.19
From: 	FLUME::jmcg "Jim McGinness"
To: 	flume::haeck
CC: 	flume::buildhelp
Subj: 	Re:  builds

This has been an interesting puzzle (you can tell I think so, right?).
Each trial takes an hour or so to complete, but only a few minutes are
needed to look at what happened and decide what to try next.

This addition chops about 50% off the time of build setup in your
situation (as opposed to plain "build setup":

build conf_SUBMAKEFLAGS=CONFIGFILES= setup


Just to make things simpler in the NOTESFILE: the goal was to build
just what was needed for FLAMINGO and MYHOST kernel starting from an
empty obj directory.

The recommendation from me is:

cd kernel
build conf_SUBMAKEFLAGS=CONFIGFILES= setup
build BINARY
build KERNEL_CONFIG=FLAMINGO config vmunix
build KERNEL_CONFIG=MYHOST config vmunix