From help-octave-request at bevo dot che dot wisc dot edu Mon Jan 31 18:07:46 2000 Subject: Re: compile on Cray/ nonGNUcompiler From: Mumit Khan To: Daniel Heiserer cc: jwe at bevo dot che dot wisc dot edu, "help-octave@bevo.che.wisc.edu" Date: Mon, 31 Jan 2000 18:07:39 -0600 (CST) On Mon, 31 Jan 2000, Daniel Heiserer wrote: > That would be easy for me. I can run it thru tons of other compilers. > If there is somebody who can fix it AND wants to fix it in the way > that octave is 100% ANSI C++ (what I think is not the worst idea.) You're of course correct, but do keep in mind that not everybody wants to (or can!) jump to the latest and greatest compilers that tend to break lots of existing code. If you really want a surprise, try IBM's latest VisualAge C++. Now on to topic at hand -- here're the various pieces that need to be changed to make Octave compile with a reasonably conforming compiler (note that I don't consider any versions of GCC released to date to be "reasonably conforming"): Here's a few things from memory when I looked into this a while back. Simple things: 1. Fix up readline headers. Currently these use K&R declarations. 2. There were a few issues in kpathsea as well, but probably fixed by now (my own packages use an older version that did fixing). 3. Fix up non-conformant forward decls, such as: class ostream; class string; etc and replace these with the appropriate include statements. 4. Fix up configure to handle non-GNU compilers. It should generally work, but won't in the following cases: a. Make sure you tell configure to use an ANSI C compiler. The current check for f2c compatible F77 compiler will fail otherwise. Easy to fix of course. b. Other issues such as creating .d files won't work, but again there're well established/known methods to make these portable. c. Little things like -shared flags may not be acceptable, and you may need to use something else (eg., on Solaris, gcc will accept -shared, but CC will only take -G). Again, easy to fix. 5. GCC allows certain accesses that are illegal (due to bugs in scope handling in GCC, not because GCC is trying to help you ;-). I remember a case or two in Octave, and easily fixed. Simple, but very tedious things: 1. Fix up all usages of std:: namespace symbols! When I moved to EDG based compilers, this was what took me the most time to "fix" a large package. I don't care for my own sofware to be compilable by older compilers, so my solution was simple -- prefix each occurance of iostream, string etc with std::. The rest of my code was already namespaced, so the transition was quite trivial. Quality of Implementation issues: 1. Fix up various variable shadow'ing issues in Octave. Octave's code has a few cases where the class data member names and the name of a parameter to a method coincide. I tend to name data members so that this doesn't happen, but that's a style/guideline issue. The current shadowing in Octave is unlikely to lead to bugs because of the relatively decent type-safey in C++, but it'd be nice to get rid of these. I probably have most of these changes sitting in a CVS branch somewhere, and if you someone really wants it, I'll dig it out. If you really want to try good compilers, try out KCC or something based on EDG. 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 -----------------------------------------------------------------------