From help-octave-request at bevo dot che dot wisc dot edu Tue Feb 1 12:08:47 2000 Subject: Re: compile on Cray/ nonGNUcompiler From: Mumit Khan To: "help-octave at bevo dot che dot wisc dot edu" Date: Tue, 1 Feb 2000 12:08:44 -0600 (CST) 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 -----------------------------------------------------------------------