🚀 go-pugleaf

In response to Alan Bair's message:
>I just retrieved the iv-2.5.tar file and will be building it shortly.  We
>have g++-1.35, which I understand is the current 'official' release from
>FSF.
>
>Before I get going too far, is there something in g++-1.35.1 that InterViews
>requires?  Or was that just what was being usd at Stanford, so it was included
>with InterViews.

and Doug Schmidt's reply:

>Make *sure* that you build the G++ included with InterViews
>distribution, and then use that to compile the other InterViews
>libraries and utilities.  If you don't do this, the libraries and
>utilities will not work correctly.  I believe all this has to do with
>the InterViews handling of I/O, in contrast to the way that libg++
>does it with the `official' G++ release.
>
>At any rate, I got it to work by rebuilding the G++ from the InterViews
>tape, while it failed the other way...

    The version of g++ distributed with InterViews is a snapshot
    that works with our code.  I'm not sure about the g++ 1.35.0 compiler,
    but there were fixes needed to g++ in the process of getting it to work
    with InterViews (as well as vice versa).

    The InterViews distribution contains its own set of header files and
    a stream implementation, thereby making the code functional
    with either g++ or cfront.  The distribution does not include libg++;
    we provide a CC command that works with either c++ (g++'s compiler) or
    cfront.  Unlike the g++ compiler driver, our CC command does not
    try to link with libg++.

    My intent in all of this is to satisfy all of the following needs:

	(1) People who want to use InterViews with cfront.
	(2) People who want to use InterViews with standard g++.
	(3) People who don't have a C++ compiler, but want to try InterViews.

    I'm sure (1) and (3) work, as I have tested them.  As we don't use libg++
    here, I haven't tested (2).  If there are problems using standard g++
    that are not 1.35.0 bugs, I would like to know about them.

	Mark