From help-octave-request at bevo dot che dot wisc dot edu Tue Feb 1 14:38:57 2000 Subject: Re: compile on Cray/ nonGNUcompiler From: "John W. Eaton" To: Mumit Khan Cc: "help-octave at bevo dot che dot wisc dot edu" Date: Tue, 1 Feb 2000 14:39:37 -0600 (CST) On 1-Feb-2000, Mumit Khan 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 -----------------------------------------------------------------------