Re: compile on Cray/ nonGNUcompiler

[Mumit Khan]

On Mon, 31 Jan 2000, John W. Eaton wrote:

> When I started working on Octave, there were no ANSI/ISO standard C++
> compilers, or even any ANSI/ISO standard.

And even today there's not a single compiler that implements it (unless
you believe in whatever marketing says ;-)

> I'm willing to work toward making Octave more compliant with the
> current standard(s), but not at the expense of compiling with the
> current release of g++.  I don't really care about any version of g++
> before 2.95.x.  So, since I'm not as up-to-date as others may be about
> what features are or are not supported, can anyone tell me if this is
> a reasonable goal?

A good goal is to make sure that Octave will work next release of gcc,
and I believe that's what we should spend time on first, and then look
at other compilers. Getting Octave to build with next GCC release will
do 90% of the work of getting Octave to build other conforming compilers.

However, I do believe that jwe's time is much better spent on core Octave
than on this issue, especially since this can easily be done by other
contributors. I'll contribute what I can.

There're a few things I had forgotten in the list (I took another look 
last night):

1. GNU libio/iostream extension: Octave uses a few extensions that need
   to taken care of. Off the cuff, these are streambuf::form, the proc
   buf and stream, and probably a few others that I haven't yet looked
   into.

2. kpathsea needs 'proto'izing' in addition to readline.

> Other than g++, I think the only C++ compiler that I have available to
> me that is Sun CC on a SunOS 5.7 system, which reports the following
> version information:
> 
>   CC: WorkShop Compilers 5.0 98/12/15 C++ 5.0
> 
> I tried using this last night, and immediately ran into the same
> problems Mumit reported (mostly namespace and forward declaration
> problems).  Does anyone know if it is reasonable to expect this
> compiler to do the job?  I had no trouble compiling Octave's C and
> Fortran code using the corresponding C and Fortran compilers on the
> same system.

We're using the same compiler, and it certainly has its share of problems,
but it does provide a nearly conforming standard library. A good one is
a missing "extern "C"" block in climits.

Here's what I would propose:

1. Get configure to add a few macros: __STD and __C_STD, which will 
   expand to "std" if it's supported. Note that we need __C_STD so 
   that "unwrapped" C headers will work with GCC (currently, std::errno
   won't work with even the experimental libstdc++-v3, and you need to
   use ::errno instead).

2. Fix up Octave's code to use STD and C_STD so that code looks like
   STD::string instead of just string.

3. Fix up readline and kpathsea. I don't know if newer releases of these
   packages have these fixed or not. It's tedious work at best. It should
   be easy to auto-protoize readline, but kpathsea will take some manual 
   work.

That will make Octave work with next major release of GCC (2.96 or maybe
3.0?) and also the libstdc++-v3 that'll hopefully come with 3.0. This 
will also keep Octave compatible with gcc-2.95.x series, which is
important in my opinion.

Next step:

1. Remove GNU'ish extensions such as:
     streambuf::form -- can be emulated without too much trouble
     procbuf, procstream: a bit more work.

Anything else?

Regards,
Mumit




-----------------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.che.wisc.edu/octave/octave.html
How to fund new projects:  http://www.che.wisc.edu/octave/funding.html
Subscription information:  http://www.che.wisc.edu/octave/archive.html
-----------------------------------------------------------------------