Re: compile on Cray/ nonGNUcompiler

[John W. Eaton]

On  1-Feb-2000, Mumit Khan <address@hidden> wrote:

| 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.

OK, any help is appreciated.  However, let's try to avoid duplicating
work.  Out of curiousity, I've already started working with the Sun
compiler and have managed to get things to a state where most of
liboctave passes through it.  The changes I've made so far are already
in the CVS archive for the bleeding-edge.  Octave still compiles with
g++ 2.95.1.

I also found the bug in the climits file distributed with the Sun
compiler (no `extern "C" {' to match the closing '}' at the end of the
file) and I'm not going to try to fix Octave to work around the
problem -- people who care will just have to fix their systems.

The Sun compiler is also giving me some really strange warnings about
ambiguous overloading (the source lines it points to don't seem to
even use the types referred to in the messages).

Once I'm through with the easy stuff, I may need some expert help
in determining what the weird error messages are all about.

| 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.

Yes, this will need some work, but Octave already has its own
procbuf/procstream classes (derived from the GNU code) so I don't
think that's a problem.  I could be wrong, but I think the real
problem is just the use of `scan' and `form', which I think can be
implemented using `<<' and `>>' and format state/manipulators/whatever,
provided that an equivalence with the C-style %-escapes can be found.

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

Instead of protoizing, I've decided to wrap them.  Otherwise, it tends
to cause trouble if I can't get the changes into the standard
distribution of readline/kpathsea/whatever, and since readline is so
pervasive, and people have lots of different versions floating around,
and (for whatever reason) they seem to like to try to build with
versions of readline not distributed with Octave, it is much simpler
to not mess with the headers.  To see how I'm doing this, check out
a current version of pathsearch.cc file and the new files
oct-kpse.{h,c}.

| 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).

I'm just using std:: where needed.  I'd rather avoid using a macro for
this unless it is really necessary, and so far I haven't found that it
is.  To solve the errno problem, I'm using 

  if (some_problem)
    {
      using namspace std;
      some_function (errno)
    }

which seems to avoid the problem, at least with the Sun compiler.

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

I've done this in liboctave, but using std:: directly.  I will
probably do more of it in the src directory soon.

| 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.

I'm fixing this without having to modify readline or kpathsea.

| 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.

Once the next bleeding-edge tar file is available (2.1.26) can someone
please try building it with the latest gcc snapshot and report the
problems they find?

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

Yes.

| Anything else?

I suppose I'll find out relatively soon...

Finally, although I am doing this work, and I plan to try to make sure
that new Octave code also conforms to these new requirements, I don't
plan to try to support lots of different compilers myself, nor do I
plan to do all the work myself to ensure that each new version of
Octave will compile with lots of different compilers.  That's what the
snapshots and test releases are for.  People who care about other
compilers or systems that I don't have will need to start trying to
build Octave on their systems and report (if not fix) the problems
they find.

Thanks,

jwe



-----------------------------------------------------------------------
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
-----------------------------------------------------------------------