🚀 go-pugleaf

I have a problem porting 'textbook' code from an HP-UX C++ (cfront) compiler
to a GNU g++ one.

The problem involves the use of inlining.

The cfront accepts 2.1, and to my experience conforms to it or explicitly
states otherwise in it's error messages.  It's on an HP 9000/360 running
HP-UX 7.x

The  GNU is version 2.3.1, for sparc-sun-sunos4.1.  I have used it with
and without the -ansi, -pedantic, -Wall flags.

The code compiles without errors or warnings.
I package my object files into a library (ar rv libtk.a *.o; ranlib libtk.a).
No prob.  But when I try to link it with some test code and make executables,
the linker returns symbol not found errors.  All the symbols are in function/
method label format.

The problem occurs when I try to link with a compilation unit whose header
contains one or more of:
	A) Automatically inlined friend functions
		(used as per Stroustup's C++ reference manual, AT&T,
		 chap. 11.4 paragraph 6)
		
	B) (Automatically) inlined methods that call private methods
	
	C) Another as yet unidentified circumstance, which I believe to be
	   similar

In the first case, the symbols not found are those of the friend fn names
themselves. By swapping code around and making things explicit, these errors
disappear.  I'm still diagnosing the other cases.

All this code, the make files, everything was debugged & running smooth on
the HP.

I'll try to whip up a quick & simplified example to post.  In the meantime,
if this is a known and/or documented problem, or if you have ideas about
what's wrong, please let me know.

P.S. Please reply by e-mail AS WELL AS post.  Thanks. 
-- 
===============================================================================
	Every program has at least one bug and can be shortened by at least
	one instruction -- from which, by induction, one can deduce that
	every program can be reduced to one instruction which doesn't work.