Xref: utzoo unix-pc.general:5054 comp.sys.att:9055
Path: utzoo!attcan!uunet!zephyr.ens.tek.com!uw-beaver!mit-eddie!bu.edu!lll-winken!brutus.cs.uiuc.edu!samsung!cs.utexas.edu!execu!sequoia!attdso!westmark!argon!ebh
From: ebh@argon.UUCP (Ed Horch)
Newsgroups: unix-pc.general,comp.sys.att
Subject: G++ on the Unix PC
Message-ID: <833@argon.UUCP>
Date: 20 Mar 90 17:35:26 GMT
References: <1743@lakesys.lakesys.com> <1122@icus.ICUS.COM> <1990Mar19.030337.1860@chinet.chi.il.us>
Reply-To: ebh@argon.UUCP (Ed Horch)
Distribution: unix-pc
Organization: Lightspace Designs, Highland Park, NJ
Lines: 106

In article <1990Mar19.030337.1860@chinet.chi.il.us> kdb@chinet.chi.il.us (Karl Botts) writes:
>>|>	Next question: Has anybody done g++ for the Unix PC yet? I don't have
>
>Well, I wouldn't call it trivial but I believe it can be done.  I have the
>compiler compiled and am about to tackle the lib.

A word of warning to anyone about to tackle this:  Don't even think
about using GCC source older than 1.37.1, and G++ source older than
1.37.0.  GCC 1.37.1 compiles painlessly on the Unix PC, and G++
compiles with a little prodding.  Also, you must have libg++ 1.37.0,
since it contains the runtime support G++ needs.  (I'd like to
actually have two libraries - one for runtime support, the
"necessities", and one for the application-oriented classes.)

>One big problem is the short supply of virtual memory; to compile the
>parser I had to shut everything else down -- especially uucp -- and source
>a script produced with make -n.  It fails from inside make, or even if you
>run the script in a subshell --- the normal way.  I am thus afraid that I
>am right on the bubble of not being able to compile the next version at
>all.

I have succcessfully compiled G++, and the library libg++, and have
produced an executable "hello world" program with it.

Compiling the Bison output blew when trying to optimize that huge
switch for all the states.  Turning off optimization fixed that,
although the executable is probably a lot bigger than it should be.  I
also compiled everything without -g.  In any case, I did this on argon
with everything else running normally (n.b. argon is 1.5x67).

Here are a few gotchas.  I'll post a more complete set of details when
I get everything stabilized.

1.  The VM problem.  See above.

2.  The makelinks script doesn't work right.  I had to link a lot of
    things over from the GCC directory by hand.

3.  I had to link /usr/include/fcntl.h to /usr/include/sys/fcntl.h.

4.  Collect had a bug where the globals __CTOR_LIST__ and
    __DTOR_LIST__ had extra underscores prepended to them.

5.  For some reason, ld, when called by g++, can't find the libraries
    in /usr/lib.  running g++ with -nostdlib, and adding in -L /usr/lib 
    worked around this.

6.  The Unix PC assembler doesn't like either $ or . in symbols.  In
    cplus-tree.h there are a bunch of #defines that expect to be able
    to use one or the other.  The Unix PC assembler manual says that
    you can use - in symbols, but the assembler didn't take them.  I
    manually hacked in a section that used Z as that special
    character, at the risk of polluting the global name space.

7.  Some of the libg++ files have names >14 characters.  In
    particular, files that are 15 characters long and end in .cc are
    misinterpreted as .c files.  I fixed these by hand.  Header files
    with long names didn't seem to be a problem.

8.  Major nastiness!  As compiled on argon, G++ complains of a parse
    error anywhere a function is defined inside a class definition,
    even if it's an empty function.  In String.h, SampleStatistic.h,
    SampleHistogram.h, and xyzzy.cc, things that look like this:

        class Foo
        {
            Foo()  {}
            ~Foo()  {}
            int zero()  { return 0; }
        };

    have to be changed to

        class Foo
        {
            Foo();
            ~Foo();
            int zero();
        };

        inline Foo::Foo() {}
        inline Foo::~Foo() {}
        inline Foo::zero() { return 0; }

Those are all the major things I encountered.  Note also that on
argon, the compiler took seven hours to build.  This would likely be a
lot faster on a system with more RAM than I have, though.  In any
case, it looks like G++ on the Unix PC is a reality.

>I know this has been discussed before, but is there any way to get more
>than 4Meg VM on this machine?

Actually, the limits are 4MB of physical RAM, and 2.5MB of per-process
virtual memory.

>Anyhow, re. g++; hang tough, we're working on it.

Me too.  It would be helpful if we could get the gnu.* groups here on
argon, since they've probably encountered the same problems we have,
and likely some we haven't seen.  If possible, I'd also like to
contribute whatever real fixes I make to the general distribution.

Lastly, muchas gracias to Alex Crain for his work with GCC on the Unix
PC, which has made the work for G++ much easier.

-Ed