thakur@ZERKALO.HARVARD.EDU (Manavendra K. Thakur) (11/23/89)
Hi there,
I'm trying to install g++ 1.36.1 and libg++ 1.36.1 on a Sun 3/470 (68030
cpu) running SunOS 4.0.3.
I've using gcc 1.36, bison 1.03, and gas 1.34. (All of these installed
without any problems.)
I've a couple of observations and some questions, mostly arising from my
doubts about whether I'm doing something stupid or if installation
instructions are wrong or if there really is a problem with g++ and/or
libg++.a
==============
Observation #1
==============
The instructions for installing g++ conflict with what I find in the
Makefile, particularly in regard to linking with crt0+.o instead of
crt0.o:
The README says that "If GAS and GNU LD work on your machine, *use
them*. That will permit you to use the system's crt0.o, including
mcrt0.o and gcrt0.o which support profiling and other features."
The instructions in the g++.texinfo document, to the other hand, say
that "The GNU C++ compiler uses its own crt0.c.... To get this
effect, if may be necessary to modify the file tm.h to link with
crt0+.o rather than crt0.o."
So which is it? Should we be using the system's crt0.o file or the
one that comes with g++?
If the latter, precisely how does one modify the tm.h file to use
crt0+.o instead? If it is just a simple matter of replacing "crt0.o"
with "crt0+.o" then this seem to doesn't work, since crt0+.o doesn't
get made unless you explicitly type "make crt0+.o".
In the course of an ordinary make, however, crt1+.o does get made. Is
this correct?
==============
OBSERVATION #2
==============
The README for g++ does not say anything about how to install g++.
This would not be much of a problem, except that the README *does* say
to "proceed to use GNU C++ to build the GNU C++ run-time libraries"
and that by "running the test programs, you can verify that GNU C++
has been properly installed." The wording here seems to imply that
you should build libg++.a and run these test programs while the g++
executable still sits in the g++ build directory, and then type "make
install" only after having verified that g++ works. Clearly, this is
incorrect. The wording needs to be tightened.
In addition, the README says nothing about how to install the C++
versions of the system include files. Stranger still, typing "make
install" in the g++ build directory will create and chmod the
g++-include directory but nothing ever gets copied in there!
This causes problems when you go to make libg++.a -- especially
considering that the libg++.a Makefile has targets for editing the Sun
versions of certain system header files!!
Which do I do first? Run the libg++.a stuff or move the g++-include
files into /usr/lib (or whevever)? This is all very confusing at the
moment, and some basic sanity checking on the whole thing would be
immensely helpful.
==============
OBSERVATION #3
==============
The installation instructions in the User's Guide to C++ contain some
leftover instructions from the GCC installation instructions.
Specifically, instructions 5 through 12 on pages 27 and 28 should be
deleted. Reading it, it's pretty clear that they are from GCC.
Step 13 on page 28 and 29 again tell you to "Make sure the Bison parser
generator is installed." This step is correctly listed.
Step 14 on page 29 purports to tell you how to install the g++
compiler's passes and run time support. However, the parts that says to
install gnulib and gcc-cpp should be reworded so that users are
instructed "to make sure that gnulib and gcc-cpp were installed
correctly after the original compilation of gcc". This way, no one can
be mislead into thinking that gnulib and gcc-cpp are compiled while
building g++.
The next section about fixincludes needs some *very* careful attention
vis a vis the discussion about include files above. Again, is the user
supposed to run fixincludes again after compiling g++? Most likely not,
but let's make this perfectly clear.
==============
OBSERVATION #4
==============
Compiling libg++.a presents its own headaches. First of all, the
Installation section in the "User's Guide to the GNU C++ Class Library"
document is very much out of step with the README file. I chose to
ignore the User's Guide info.
Next hurdle: the Sun 3 assembler dies a horrible death if you try to use
the -pipe argument to g++. From the man page for the Sun as:
as translates the assembly source file, filename into an
executable object file, objfile. The Sun-4 assembler recog-
nizes the filename argument `-' as the standard input.
So it seems that you have to specify a `-' as a dummy filename in order
for the -pipe to work correctly, and that only on a Sun-4. So a message
should be added to the libg++.a Makefile and README warning people about
this. It is probably better to simply get gas and install it.
In fact, it's more than better. It's virtually mandatory to use gas.
Here's why:
If you remove the -pipe option from the libg++.a Makefile, then
temporary files are used to pass info between g++ and (Sun) as. This is
all fine and good -- until you try to compile builtin.cc. Here is what
you get while compiling builtin.cc with g++ and the Sun as:
g++ -I/usr/src/Gnu/libg++/g++-include -O -fstrength-reduce -felide-constructors -fschedule-insns -fdelayed-branch -fsave-memoized -Wall -c AllocQueue.cc
g++ -I/usr/src/Gnu/libg++/g++-include -O -fstrength-reduce -felide-constructors -fschedule-insns -fdelayed-branch -fsave-memoized -Wall -c builtin.cc
builtin.cc: In function char *dtoa (double, char (= 103 ), int (= 0 ), int (=
6 )):
builtin.cc:499: warning: unused variable `carry'
builtin.cc:386: warning: unused variable `fworkend'
/usr/src/Gnu/libg++/g++-include/time.h: At top level:
In file included from /usr/src/Gnu/libg++/g++-include/osfcn.h:4, from builtin.cc:763:
/usr/src/Gnu/libg++/g++-include/time.h:60: warning: type declaration of timezone shadows previous declaration
/usr/src/Gnu/libg++/g++-include/time.h:60: warning: `timezone' was declared `extern' and later `static'
builtin.cc:848: warning: structure has no data members
as: error (/usr/tmp/cca15252.s:1388): Invalid operand
as: error (/usr/tmp/cca15252.s:1404): Invalid operand
*** Error code 1
make: Fatal error: Command failed for target `builtin.o'
Current working directory /usr/src/Gnu/libg++/src
*** Error code 1
make: Fatal error: Command failed for target `src/libg++.a'
zerkalo%
It seems that the Sun as chokes on empty files, which are being created
(?) because something weird is going on in the time.h include file.
However, if I use gas, the compile does *not* die. Rather, it proceeds
to conclusion and creates a libg++.a.
But, but, BUT: How can I be sure that this is the right thing? Is this
problem with time.h and/or builtin.cc serious? Am I losing something
(will my libg++.a be corrupt or incomplete) as a result?
The answer seems to be yes, since "make tests" doesn't work at all for
me. I keep getting problems with "crt0+.o not found." If I explicitly
go the g++ directory, make crt0+.o, and then copy it to /usr/lib, and
then run "make tests" again, here is what I get:
/usr/lib/gcc-cc1plus -quiet -dumpbase test.shell.cc -fstrength-reduce -felide-constructors -fschedule-insns -fdelayed-branch -fsave-memoized -O -Wall -version -o - | as -mc68020 -o test.shell
GNU CPP version 1.36
GNU C++ version 1.36.1 (based on GCC 1.36) (68k, MIT syntax) compiled by GNU C version 1.36.
default target switches: -m68020 -mc68020 -m68881 -mbitfield
test.shell.cc:2: warning: structure has no data members
g++ test.hello.o -L../src -lg++ -lm -o test0
/usr/lib/crt0+.o: Definition of symbol ___do_global_cleanup (multiply defined)
/usr/lib/crt0+.o: Definition of symbol ___do_global_init (multiply defined)
gnulib3.o: Definition of symbol ___do_global_cleanup (multiply defined)
gnulib3.o: Definition of symbol ___do_global_init (multiply defined)
*** Error code 1
make: Fatal error: Command failed for target `test0'
(The "no data members" error appears on other files too.)
So, either I clearly goofed while installing g++ in the first place, or
this library stuff is coming back to haunt me. Any help or advice?
==============
OBSERVATION #5
==============
How in the world do I tell g++ what assembler to use? I did it by
renaming "/usr/bin/as" to "/usr/bin/as.sun" and making a link from
/usr/bin/as to /usr/bin/gas. But there must be an easier way (I hope).
Is there some command line option, or some other trick? I tried to
define USE_GAS in the tm-sun3.h file, but I couldn't find any ifdefs
that depend on USE_GAS in the g++ or gcc source code, and I really
didn't feel like tracking the whole internal workings of gcc and g++.
This may seem like a dumb question to you, but it sure has me stumped.
Again, a few words could spare somebody a lot of trouble.
====================================
Conclusion: I'm going nowhere fast. Any help you can provide on these
or other problems would be greatly appreciated.
Manavendra K. Thakur
System Manager, High Energy Division
Harvard-Smithsonian Center for Astrophyics
thakur@zerkalo.harvard.edu
thakur@cfa.harvard.eduscp@SFI.SANTAFE.EDU ("Stephen C. Pope") (11/25/89)
on Thu, 23 Nov 89 06:15:25 EST,
Manavendra K. Thakur <thakur@zerkalo.harvard.edu> said:
Manavendra> Hi there,
Manavendra> I'm trying to install g++ 1.36.1 and libg++ 1.36.1 on a Sun 3/470 (68030
Manavendra> cpu) running SunOS 4.0.3.
Manavendra> I've using gcc 1.36, bison 1.03, and gas 1.34. (All of these installed
Manavendra> without any problems.)
Manavendra> Observation #1
Manavendra> The instructions for installing g++ conflict with what I find in the
Manavendra> Makefile, particularly in regard to linking with crt0+.o instead of
Manavendra> crt0.o:
Ignore whatever the various documents say. Reality changes much faster
than documentation. G++-1.36 and up now *must* use gas and Gnu ld.
Meanwhile, the usual Sun supplied crt0.o and such are used also.
What to do:
* Install gas 1.34 (or gas.xtar.Z frm labrea) as $(libdir)/gcc-as
* Install ld++ from the g++-1.36.1 distribution as $(libdir)/gcc-ld
(Note: do *not* attempt to use Gnu ld from the binutils distribution.
Also, installing Gnu ld as such will cause gcc to use it also,
meaning that will will no longer get anything dynamically loaded.
If you must have your gcc-compiled code dynamically loaded,
install ld++ as something else, and tweak the ld spec in
g++'s gcc.c.
If trying to compile libg++ test programs result in ld error messages
involving __DYNAMIC, __CTOR_LIST, or __main, you've done something wrong.
Manavendra> OBSERVATION #2
Manavendra> The README for g++ does not say anything about how to install g++.
Simply ``make install'', but note that you'll have to install ld++ by
hand, as noted above
Manavendra> This would not be much of a problem, except that the README *does* say
Manavendra> to "proceed to use GNU C++ to build the GNU C++ run-time libraries"
If you really don't want to install g++ before testing, then change
your compilation flags in libg++ Makefile(s) to use
/usr/whereever/g++-1.36.1/g++ -B/usr/whereever/g++-1.36.1/
Manavendra> OBSERVATION #4
Manavendra> Next hurdle: the Sun 3 assembler dies a horrible death if you try to use
Manavendra> the -pipe argument to g++. From the man page for the Sun as:
Use gas installed as gcc-as as per above
Manavendra> builtin.cc:848: warning: structure has no data members
Manavendra> as: error (/usr/tmp/cca15252.s:1388): Invalid operand
Manavendra> as: error (/usr/tmp/cca15252.s:1404): Invalid operand
ditto.
Manavendra> OBSERVATION #5
Manavendra> How in the world do I tell g++ what assembler to use?
gcc.c starts by looking for $(libdir)/gcc-as, then searches the rest of
your $path for /whatever/as. You can tweak all the compiler table
entry specs if you like.
stephen pope
santa fe institute
scp@sfi.santafe.edu