[comp.sys.alliant] libg++ make problems. Comments.

ric@ace.sri.com (Richard Steinberger) (10/13/90)

	I have been having quite a difficult time building the GNU C++
library, libg++, and would appreciate any help or suggestions.  g++ is
already built and installed on our system.  (g++, v 1.37, gcc v 1.37.93).

	This is what happened when I typed 'make src'  (last lines only):

-------------------------------------------------------------------------------

(cd src; make GXX="g++" GXXFLAGS=" -I/usr1/ric/g++/libg++-1.37.0/g++-include -g
 -O -fstrength-reduce -felide-constructors -fschedule-insns -fdelayed-branch -f
" LIBDIR="/usr/gnu/lib" SRCIDIR="/usr1/ric/g++/libg++-1.37.0/g++-include" CC="gc
c" CFLAGS=" -I/usr/gnu/lib/gcc-include -I/usr/include -I/usr1/ric/g++/libg++-1.3
7.0/g++-include -g -O -fstrength-reduce -fdelayed-branch -Wall  " RANLIB="ranli
b" LDXX="/usr/gnu/lib/gcc-ld" GXXCRT1="/usr/gnu/lib/crt1+.o" MAKE="make" prefix=
"/usr/gnu" VPATH="/usr1/ric/g++/libg++-1.37.0/g++-include")
g++ -I/usr1/ric/g++/libg++-1.37.0/g++-include -g -O -fstrength-reduce -felide-c
onstructors -fschedule-insns -fdelayed-branch -fsave-memoized  -Wall  -c  EH.cc
/usr/include/sys/signal.h:16: warning: `/*' within comment
/usr/include/sys/signal.h:17: warning: `/*' within comment
/usr/include/sys/signal.h:134: warning: `/*' within comment
In file included from /usr1/ric/g++/libg++-1.37.0/g++-include/signal.h:35, from
/usr/include/setjmp.h:20, from /usr1/ric/g++/libg++-1.37.0/g++-include/setjmp.h:
9, from EH.cc:5:
/usr/include/sys/signal.h:162: field `sc_gen' has incomplete type
/usr/include/sys/signal.h:163: field `sc_fpt' has incomplete type
/usr/include/sys/signal.h:164: field `sc_ccu' has incomplete type
/usr/include/sys/signal.h:165: field `sc_vec' has incomplete type
*** Exit 1

Stop.
*** Exit 1

Stop.
------------------------------------------------------------------------------

	To state the obvious, I am uncertain as to what to do next.  One
possible problem is that we do not have gcc-ld, and LDXX points to it
in the libg++ makefile.  In addition, GXXCRT1 points to crt1+.o, and
I don't believe we have this either, at least it's not in /usr/gnu/lib.

	Any help, guidance or suggestions would be more than welcome.
I could even set up a guest account here, if that would help.

regards,

	ric steinberger
	ric@ace.sri.com
	(415) 859 - 4300   8AM - 5PM PDT


Mild Flame, and some appreciation follow:

   Getting g++ made was no picnic.  The directions (i.e., the README
file) seemed to be particularily difficult to follow.  For example,
reference is made to a gcc-test directory that, as far as I can tell,
is not normally created when gcc is made.  Yet, it was necessary
to create a soft link to gcc-1.37.93 for this.  (No big deal, you might
say, it should be obvious.  Then why not be explicit about this?)

	The recommended directory structure of g++ and gcc was, I felt,
all too vague.  It would have been very nice to have include a brief
sketch of the suggested relative locations of the various directories.

	Particularily vexing were all the comments about crt0.o  Some
of us, including yours truly, are not compiler or internals gurus.
It would be very nice if a more specific procedure were detailed to
allow non-experts to figure out what to do, if anything, about crt0.
For instance, something better than, "GNU C++ *may* need to use its
own crt0.c, borrowed and modified [HOW ???] from GNU Emacs", would have
been very much appreciated.  Although the make finished OK (after I defined
LD_PATH to /lib /usr/lib /usr/local/lib, a goofiness necessary to overcome
a partially brain-dead Alliant loader that can't recognize the -L flag),
it's unclear what the effect of my not doing something special about
crt0 is.  Any ideas?

	In summary, I believe that not enough care was taken to develop an
install procedure that does not require one to be an internals or compiler
expert.  I have found the GNU SW to be, in general, excellent quality
work.  It would be a shame if people were prevented from using it because
the install procedures are too difficult for the "average" system
manager or applications programmer to handle.	

	Anyone who has ever installed SW developed by Larry Wall (patch,
for example), cannot but marvel at the simplicity and intelligence that
are present in the install procedure.  The procedure basically figures
out what kind of system you've got (e.g., BSD 4.x or SYSV), what commands
it's got, where they are, what's in the C RTL, etc., etc.  This approach
ought to be a goal for some of the more difficult-to-install programs
like g++/libg++.

[Suggestion for the crt0 "problem":  Why not include a prodecure for
people to follow that would lead them to an appropriate conclusion 
about what they had to do?  Such a procedure might be a combination
of written instructions and short pgms or shell scripts that helped
guide people along.  And, of course, a better explanation of just
what crt0.c is would be nice.  And, a means to verify that what they
did was correct.]

Mild flame off.