Conference smurf::buildhelp

2049.0. "Re: Any idea on this? He has libots.a on his system." by AOSG::FILTER (Automatic Posting Software - mail to flume::puck) Fri Jan 12 1996 12:29

Date Of Receipt: 	12-JAN-1996 11:39:25.54
From: 	SMURF::FLUME::"[email protected]" "Joe Mario DEC C  12-Jan-1996 1136"
To: 	John Flanagan - UNIX Systems Group <[email protected]>
CC: 	[email protected], [email protected], [email protected],
	[email protected], [email protected], [email protected],
	[email protected]
Subj: 	Re: Any idea on this? He has libots.a on his system.

This is another example of a broken build makefile.  We have seen several
of these.  The command is using the tools from /usr/bin/cc.  That is
fine and it's often done when building components that need to be run
during the build.  However, when the native /usr/bin/cc is used to do
a compilation, then every thing about that compilation *MUST* come from
the native system and not from the build.   

This compilation has mixed pieces from both the native system and from
the build pool.  In this case it looks like some of the objects being
linked were built in the Platinum pool with the DECC compiler and they
are trying to be linked with the native pre-platinum /usr/lib/cmplrs/cc
compilation environment.

The solution is to fix the makefile to either use all the native environment
or use all the build pool but not to mix them.

We've been through this many times and have ideas on how to fix it if
you're interested.

Joe

> 
> ------- Forwarded Message
> 
> Return-Path: schloss
> Received: from ralpha.zk3.dec.com by flume.zk3.dec.com; 
> (5.65v3.2/1.1.8.2/16Jan95-0946AM)
> 	id AA15708; Thu, 11 Jan 1996 17:13:26 -0500
> Received: from mhs.zk3.dec.com by falpha.zk3.dec.com; 
> (5.65v3.2/1.1.8.2/20May95-1022AM)
> 	id AA03370; Thu, 11 Jan 1996 17:13:05 -0500
> Received: from localhost by mhs.zk3.dec.com; (5.65v3.2/1.1.8.2/05Sep95-1215PM
)
> 	id AA12086; Thu, 11 Jan 1996 17:13:05 -0500
> Message-Id: <[email protected]>
> To: buildhelp
> Subject: Re: build help question
> Date: Thu, 11 Jan 96 17:13:04 -0500
> From: schloss
> X-Mts: smtp
> 
> It has been a few weeks now and I still haven't gotten an
> response to this.  It was last left as a problem related
> to the fact that I have a populated (links) tools directory.
> Is anyone following up on this?
> 
> Mike
> 
> = To: buildhelp
> = Subject: Re: build help question
> = Date: Tue, 19 Dec 95 10:25:31 -0500
> = From: schloss
> = X-Mts: smtp
> = 
> = John Flanagan writes:
> = > Sounds like he doesn't have a library installed on his system? 
> = 
> = Andrew Duane writes:
> = > This sounds like the new versus old compiler stuff.
> = 
> = This answers seem to be missing a key point.  Should the build 
> = be taking anything from the local system?  If this is allowed
> = then the output of the build may depend upon which system was
> = used to do the build (or at least the version of the installed
> = software).  Shouldn't all tools be running from the pool's tools
> = directory?
> = 
> = Sean Davidson writes:
> = > This looks like you are linking against part of pt.lite libraries
> = > and pt libraries.
> = > 
> = > This looks like you are picking up the pt version of mld and the
> = > pt.lite version of libc.
> = > 
> = > Make sure your sandbox is backed by ptos.nightly.  I just created
> = > a sandbox and build fsmrg on flambe running V3.2C (pt.lite).
> = 
> = OK, now we are getting somewhere, I think.  I have one sandbox
> = backed by ptos.nightly and another backed by ptos.  Both exhibit
> = the same problem.
> = 
> = In one case, the offending component is usr/lib/sabt/sbin/fsmrg.
> = 
> = The failed fragment is:
> = 
> = [ /usr/lib/sabt/sbin/fsmrg ]
> = makepath fsmrg/. && cd fsmrg &&  exec make 'RELEASE_OPTIONS=-idfile `genloc
 
> /src
> = /setup/osf1_idlist`'    MAKEFILE_PASS=BASIC dopass_all
> = fsmrg: created directory
> = env - COMP_HOST_ROOT=/ COMP_TARGET_ROOT=/ /usr/bin/cc   -EL -call_shared  
> -O2   
> =   `genpath   ` -L/usr/lib -L/lib  -Wf,-wchar32 -DBSD44 -DMSG -DNLS 
> -D__WCHAR_T_L
> = EN=4 -DMACH -DCMU -DOSF -DOSF  -Dalpha -D__alpha__ -D__alpha  -Dunix 
> -D__unix__ 
> =    -D_SHARED_LIBRARIES  -O2 -Olimit 5000              `genpath -I.` `genpat
h 
>  -I
> = ../../../usr/include -I../../include ` -I/usr/include  -o fsmrg.X 
> ../../../../..
> = /../../src/kernel/src/fsmrg/fsmrg.c  -L/usr/ccs/lib -lmld  
> = ld:
> = Unresolved:
> = _OtsRemainder32Unsigned
> = _OtsDivide64Unsigned
> = _OtsRemainder64Unsigned
> = _OtsDivide32Unsigned
> = _OtsMove
> = _OtsDivide32
> = _OtsRemainder32
> = *** Exit 1
> = `dopass_all' not remade because of errors
> = 
> = I question whether the build should be specifying -I/usr/include or 
> -L/usr/ccs/lib.
> = 
> = Mike
> 
> ------- End of Forwarded Message
> 
> 
> 
> 
>  ______________________________________________________________________
> 
>  John Flanagan	 		enet:    [email protected]	
>  MS: ZKO3-3/W20			decnet:  flume::johnf
>  USG Release Engineering		 (603) 881-1719
>  110 Spitbrook Road 			 (DTN) 381-1719
>  Nashua, NH  
>  ______________________________________________________________________
> 
> 
> 

Date Of Receipt: 	12-JAN-1996 12:22:56.34
From: 	SMURF::FLUME::"[email protected]" "Mike Schloss usg  12-Jan-1996 1201"
To: 	John Flanagan - UNIX Systems Group <[email protected]>
CC: 	[email protected],
	John Flanagan - UNIX Systems Group    <[email protected]>,
	[email protected], [email protected],
	[email protected], [email protected],
	[email protected], [email protected]
Subj: 	Re: Any idea on this? He has libots.a on his system.

> Joe, what I don't understand is that we don't get this build problem
> during the nightly build.  And the nightly build is done on a V3.2C
> build system!  The Makefile may be busted, but it works fine during 
> the build, so noone has ever flagged it.  Is there a proposed fix for
> this Makefile?

The difference appears to be that I have populated my tools directory
with links.  I don't know why this makes a difference, but it does.

Mike

Date Of Receipt: 	12-JAN-1996 12:23:10.95
From: 	SMURF::FLUME::"[email protected]" "John Flanagan USG Test Johnf Tools Group  12-Jan-1996 1143"
To: 	[email protected]
CC: 	John Flanagan - UNIX Systems Group    <[email protected]>,
	[email protected], [email protected],
	[email protected], [email protected],
	[email protected], [email protected]
Subj: 	Re: Any idea on this? He has libots.a on his system.

Joe, what I don't understand is that we don't get this build problem
during the nightly build.  And the nightly build is done on a V3.2C
build system!  The Makefile may be busted, but it works fine during 
the build, so noone has ever flagged it.  Is there a proposed fix for
this Makefile?


 ______________________________________________________________________

 John Flanagan	 		enet:    [email protected]	
 MS: ZKO3-3/W20			decnet:  flume::johnf
 USG Release Engineering		 (603) 881-1719
 110 Spitbrook Road 			 (DTN) 381-1719
 Nashua, NH  
 ______________________________________________________________________