Nokia Networks Home

Nokia nmake Product Builder

Quick Links

Related Products

How can we use HP's cfront C++ compiler with Nokia nmake?

There have been some problems using HP's native cfront based C++ compiler. This compiler is generally known as /bin/CC, /usr/bin/CC, or /opt/CC/bin/CC on HP-UX 10.x and 11.x machines. This is not the same as HP's Softbench aCC compiler.

What's the problem?

The main problem we see when using this compiler is the following type of error message when the compiler is doing template instantiation:

    CC: error: header cache out of date in read-only repository
    /home/bugati/richb/build/v3/src/ptrepository/gt__FiT1.he (-I changed
    ) (727)

What does this error really mean?

The error is telling the user that an object in a secondary repository (the ptrepository directory mentioned in the error) is out of date. Since the secondary repositories are read-only (they are down the VPATH) the error is really telling the user to rebuild the indicated repository. This makes no sense in a VPATH build environment. We would like the compiler to do what the Lucent C++ 3.0.3 compiler does (which is also based on cfront). If the compiler deems an object in a secondary repository out-of-date, then the compiler should rebuild that object in the primary repository rather than give an error message. Additionally, when you change the -I arguments used on the compile line HP's compiler will consider an object out of date. This is indicated by "(-I changed)" in the error message. In many cases this behavior will throw anything out of date when you add a node to the VPATH since the new node may need to be searched for include files.

After talking to HP support about this issue we have decided HP's cfront C++ compiler does not integrate well into a build environment using nmake. When inquiring about changing the behavior of the compiler to rebuild out of date objects rather than return an error we were told the following by HP support:

This compiler is at the end of its life cycle. The lab will only fix critical errors at this point. If your company would like to pursue a business case for this being a critical error we may get the lab to make a change, but its sounds like it would result in a significant change in behavior, so I wouldn't be too hopeful of that approach.

Update 08/18/2000: HP has stated on their web site that support for the cfront C++ compiler will end August 1, 2001.
See http://www.hp.com/esy/lang/cpp/cxx.html#notice

Recommendations

Because of this undesirable behavior and the statement indicating the compiler is "at the end of its life cycle" we are recommending projects migrate off HP's cfront C++ compiler. Some alternative C++ compilers we can recommend are:

What About a Work-around?

The safest work-around we have come up with is to eliminate the -ptr arguments from the command line. This will insure the compiler does not look at repositories down the VPATH and thus will not complain about out-of-date objects found in secondary repositories.

  1. Add the following to your global makefile when using the cfront HP C++ compiler:
    .PTR.INIT : .CLEAR .VIRTUAL .NULL
    
    .PTR.OPTIONS. : .CLEAR .FUNCTION .NULL
    
  2. Remove any setting of .SOURCE.ptr from your makefiles or global makefiles. If you are already redefining .PTR.INIT (such as to copy the entire repository from down the VPATH) then remove your modification and use the above instead.
  3. The first time using these new rules you should do a new build from scratch in a clean area or remove your ptrepository directories and use nmake -F to force a rebuild.

The down side of this work-around is that compiling in a new node will take longer since the compiler is unable to view through the old repositories and reuse objects that were already built. The up side is the compiler builds your code and does not return the "header cache out of date" error.

What About Library Closure?

You will need to do library closure on your C++ libraries. This is still a bit experimental so let us know if you have any problems.

  1. Add the following rule to your global makefile.
    .ARCLEAN : .CLEAR .AFTER .IGNORE .VIRTUAL .FORCE .REPEAT
    	if [ -n "$(LIBCLOSE:N=$(<<))" ]
    	then
    	       echo "int main(){ return 0; }" > 1.tmp.c
    	       trap 'rm -f $(<<) 1.tmp.*; exit 1' ERR QUIT HUP INT
    	       $(CC) -pta $(CCFLAGS:N=-[D]*|-I-D*) $(!$(>>):A=.SCA
    N.c:@?$$(*.SOURCE.%.LCL.INCLUDE:I=$$$(!$(>>):A=.LCL.INCLUDE:P=D):/
    ^/-I/) -I- $$(*.SOURCE.%.LCL.INCLUDE:I=$$$(!$(>>):A=.LCL.INCLUDE|.
    STD.INCLUDE:P=D):$(.CC.NOSTDINCLUDE.):/^/-I/)??) $(>>:P=L:A!=.JOIN
    T) 1.tmp.c
    	       $(AR) $(ARFLAGS) $(<<) ./ptrepository/*.o
    	       $(RM) -f a.out 1.tmp.*
    	fi
    	$(.ARCLEAN.LIST.:K=$(RM) $(RMFLAGS))
    
  2. In your local makefiles, when you have a C++ library which you need to close set "LIBCLOSE=libname.a libname2.a etc". This allows for the case of building multiple libraries in the same Makefile where some need to be closed but others do not.
Last Update: Friday,12-Aug-2016 10:45:33 EDT