Conference smurf::buildhelp

2730.0. "v32de1supportos.nightly backed sandbox on v40 system build failing" by AOSG::FILTER (Automatic Posting Software - mail to flume::puck) Fri Dec 13 1996 12:47

Date Of Receipt: 	13-DEC-1996 12:13:36.04
From: 	ALPHA::amilicia "Anne Milicia bossec"
To: 	buildhelp@DEC:.zko.alpha
CC: 	
Subj: 	v32de1supportos.nightly backed sandbox on v40 system build failing

Hi,
Suddenly I'm getting the errors again for these programs when trying to
build a sandbox for v32de1supportos.nightly on a v40 system.  The Makefile
for mkdata does have INCFLAGS as "-I../../include -I/usr/include", but when
I look in obj/alpha/kernel/include there is no string.h in the builds, so
it's using my /usr/include 4.0 version.  Did the string.h get removed from the
kernel include or something?

I don't seem to have an old sandbox around that used to work to look and see
if it had a string.h in obj/alpha/kernel/include.

Thanks for the help!
Anne

> Bet you're running 4.0 trying to build 3.2, no?  At present this doesn't work. 
> The giveaway is the COMP_HOST_ROOT=/ COMP_TARGET_ROOT=/ /usr/bin/cc.
> 
> To get this to work you'll need to submit the following changes to the support 
> pool as analyzed and defined by Fred Cantor in the following mail:
> 
> 
> | As you know I had trouble building a sandbox backed by hw6os.bl6 on
> | my workstation running V4.0. The errors were in three files:
> | 	src/kernel/src/mkdata/mkdata.c
> | 	src/kernel/src/mkeisadata/mkeisadata.c
> | 	src/kernel/src/mktcdata/mktcdata.c
> | 
> | The errors were caused by mixing and matching problems with the string.h
> | header file. These error should be fixed before UHS developers convert
> | their workstations to V4.0 and encounter them. There are two options
> | for fixing this:
> | 
> | 1) Remove the #include of string.h and stdlib.h from the above files.
> |    They build if these #includes are removed.
> | 
> | 2) Modify the Makefile for the above .c files as follows:
> 
> | 	41c41
> | 	< INCFLAGS              = -I/usr/include -I../../include
> | 	---
> | 	> INCFLAGS              = -I../../include -I/usr/include
> | 
> | Searching /usr/include first makes sure the compiler sees the matching
> | version of the header files (i.e., the ones from the build machine).
> | Option 2 seems cleaner to me.
> | 
> | Fred
> 
> 
> 			-Grant
> 
> 
> 
> 
> 
> > Hi,
> > I'm working on a backlog reduction CLD and the customer has 3.2D installed
> > so I want to build a fix for that version.  I created a sandbox backed to
> > v32de1supportos.nightly and tried to build a kernel.  When I tried
> > "build setup" I got the following errors and the build quit:
> > 
> > mkdata: created directory
> > env - COMP_HOST_ROOT=/ COMP_TARGET_ROOT=/ /usr/bin/cc   -EL -c  -DBSD44 -DMSG  
> > -D__WCHAR_T_LEN=4 -Wf,-wchar32  -DMACH -DCMU -DOSF  -Dalpha -D__alpha__ 
> > -D__alpha -Dunix -D__unix__      -O2 -Olimit 5000    -DCMU -D_NO_PROTO 
> > -Dconst=      `genpath -I.` `genpath  -I../../include -I/usr/include ` 
> > -I/usr/include  /usr/sde/osf1/build/v32de1supportos.nightly/src/kernel/src/mkdata/mkdata.c
> > cc: Error: /usr/include/string.h, line 164: In the declaration of "__R", a funct
> > ion may not return a function type.
> > extern char    * __R(basename) __((char  *));
> > -----------------^
> > cc: Warning: /usr/include/string.h, line 164: In the declaration of "__R", a fun
> > ction declarator has an identifier list but is not part of a function definition
> > .  Extraneous parameter names are ignored.
> > extern char    * __R(basename) __((char  *));
> > -----------------^
> > cc: Error: /usr/include/string.h, line 165: In the declaration of "__R", a funct
> > ion may not return a function type.
> > extern char    * __R(dirname) __((char  *));
> > -----------------^
> 
> 
>