[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

2614.0. "rpc.lockd compiles picking up wrong include files" by AOSG::FILTER (Automatic Posting Software - mail to flume::puck) Tue Oct 22 1996 13:22

Date Of Receipt: 	14-OCT-1996 11:33:52.39
From: 	WASTED::werme "Eric Werme USG"
To: 	buildhelp@DEC:.zko.wasted, jmf@DEC:.zko.wasted
CC: 	werme@DEC:.zko.wasted
Subj: 	rpc.lockd compiles picking up wrong include files

First - Is this alias up-to-date? Some people seem an odd fit and people
I expect to see are not here..

buildhelp       afd bstevens [email protected] darrell dupuis helix::krueger  
        jmcg kenny locus_ode mento [email protected] mwarren reng  
        [email protected] shashi smurf::filter zap   

I sent a good portion of Friday trying to figure out why rpc.lockd
was blowing up when I built it in a steel sandbox.  (I think it was
working fine in a ptos sandbox, but I may have copied all source
files there.  Haven't check.  Did check, I had.)

I've checked out these files (and other sources I haven't listed:)

/build/steel/src/usr/sbin/rpc.lockd:
-rw-rw-r--   1 werme    system     14226 Oct 11 16:32 prot_lock.h
-rw-r--r--   1 werme    system     25379 Oct 11 11:35 prot_proc.c

I have not checked out:
/share/kgb/build/steelos.dsk6/steelos.nightly0/src/usr/sbin/rpc.lockd
-r--r--r--   1 devbld   staff      11066 Feb 24  1994 prot_libr.c

When I "build prot_proc.o" with the compiler options -C -E, this
line:

#include "prot_lock.h"

elicits:

# 81 "../../../../../src/usr/sbin/rpc.lockd/prot_proc.c"

# 1 "../../../../../src/usr/sbin/rpc.lockd/prot_lock.h"

This brings in my modified header file.  However, when I "build prot_libr.o"
with the compiler options -C -E, this line:

#include "prot_lock.h"

elicits:

# 67 "/usr/sde/osf1/build/steelos.nightly/src/usr/sbin/rpc.lockd/prot_libr.c"

# 1 "/usr/sde/osf1/build/steelos.nightly/src/usr/sbin/rpc.lockd/prot_lock.h"

This reads the include file from the backing tree.  Since I changed a data
structure by inserting some new entries, rpc.lockd blows up upon
taking and releasing a lock.

The compiler run lines for the two files are:

relative path: ./usr/sbin/rpc.lockd.
string passed to /usr/sde/osf1/build/steelos.nightly/tools/alpha_OSF1/alpha/hostbin/make:
   make -cF prot_proc.o cd ../../../../obj/alpha/usr/sbin/rpc.lockd
/usr/sde/osf1/build/steelos.nightly/tools/alpha_OSF1/alpha/acc/cc   -std0 -c   -DBSD44 -DMSG -DNLS  -DMACH -DCMU -DOSF -DOSF  -Dalpha -D__alpha__ -D__alpha  -Dunix -D__unix__    -D_SHARED_LIBRARIES  -O2    -UMSG -g -DLSD -C -E    -I  `genpath -I.` `genpath   `  -I/usr3/werme/sb/steel/export/alpha/usr/include -I/usr/sde/osf1/build/steelos.nightly/export/alpha/usr/include  ../../../../../src/usr/sbin/rpc.lockd/prot_proc.c

relative path: ./usr/sbin/rpc.lockd.
string passed to /usr/sde/osf1/build/steelos.nightly/tools/alpha_OSF1/alpha/hostbin/make:
   make -cF prot_libr.o cd ../../../../obj/alpha/usr/sbin/rpc.lockd
/usr/sde/osf1/build/steelos.nightly/tools/alpha_OSF1/alpha/acc/cc   -std0 -c   -DBSD44 -DMSG -DNLS  -DMACH -DCMU -DOSF -DOSF  -Dalpha -D__alpha__ -D__alpha  -Dunix -D__unix__    -D_SHARED_LIBRARIES  -O2    -UMSG -g -DLSD -C -E    -I  `genpath -I.` `genpath   `  -I/usr3/werme/sb/steel/export/alpha/usr/include -I/usr/sde/osf1/build/steelos.nightly/export/alpha/usr/include  /usr/sde/osf1/build/steelos.nightly/src/usr/sbin/rpc.lockd/prot_libr.c

After several wrong paths trying to dothe moral equivalent of CC=/usr/bin/echo,
I finally got:

alingo 129% !!
build prot_libr.o 
relative path: ./usr/sbin/rpc.lockd.
string passed to /usr/sde/osf1/build/steelos.nightly/tools/alpha_OSF1/alpha/hostbin/make:
   make -cF prot_libr.o 
cd ../../../../obj/alpha/usr/sbin/rpc.lockd
/usr/bin/echo -c   -DBSD44 -DMSG -DNLS  -DMACH -DCMU -DOSF -DOSF  -Dalpha -D__alpha__ -D__alpha  -Dunix -D__unix__    -D_SHARED_LIBRARIES  -O2    -UMSG -g -DLSD    -I  `genpath -I.` `genpath   `  -I/usr3/werme/sb/steel/export/alpha/usr/include -I/usr/sde/osf1/build/steelos.nightly/export/alpha/usr/include  /usr/sde/osf1/build/steelos.nightly/src/usr/sbin/rpc.lockd/prot_libr.c
-c -DBSD44 -DMSG -DNLS -DMACH -DCMU -DOSF -DOSF -Dalpha -D__alpha__ -D__alpha -Dunix -D__unix__ -D_SHARED_LIBRARIES -O2 -UMSG -g -DLSD -I -I. -I/usr3/werme/sb/steel/src/usr/sbin/rpc.lockd -I/usr/sde/osf1/build/steelos.nightly/src/usr/sbin/rpc.lockd -I/usr3/werme/sb/steel/export/alpha/usr/include -I/usr/sde/osf1/build/steelos.nightly/export/alpha/usr/include /usr/sde/osf1/build/steelos.nightly/src/usr/sbin/rpc.lockd/prot_libr.c
Elapsed build time(hr:min:sec): 0:0:2 

Ah - perhaps this is it.  I was under the impression that -I without a
directory reset the include search list to empty.  Apparently it merely
removes /usr/include.  Hmm.  There appears to be no easy way to test this
within the confines of an ODE build.  Wait a minute - yes there is.  Just
NFS mount a copy of the backing tree usr/sbin/rpc.lockd on top of that.
Yes, indeed, that's the problem.

Now, I had discounted all that based on my observation that modifying
prot_lock.h cause recompilation of prot_libr.c.

So, I guess I have these questions:

1) The #include "foo.h" style directective should never be used with files
   built with ODE, except possibly for .h files built as part of the build
   process and don't exist elsewhere.  Right?

2) Is that documented anywhere?  odeman of build, make, and makefiles doesn't
   mention it.  Oops - I see something in makefiles, but I discounted it
   earlier because it said ".include", not "#include", so I assumed it was
   going to talk about includes in Makefiles.  Sigh.  The title of the
   section says "Use Quote Syntax" which is not being very helpful.

3) That section talks about using -I-, it appears to me we neither support
   it nor report an error.  True?  (I assume I just added the directory "-"
   to the serach list.)

4) I imagine that changing prot_lock.h triggered recompilation because
   my Makefile has HFILES = prot_lock.h.  True?  I don't see any warnings
   about this.

T.RTitleUserPersonal
Name
DateLines