Re: Octave chokes on this in some systems

[Quentin Spencer]

On November 30, Shai Ayal wrote:

> I am not sure what is the status of this problem, especially if 
> something has been done regarding this in the fc4 rpm's.


Nothing yet. I finally got a patch that worked, but I haven't yet 
decided if it deserves a new release by itself.

> I now understand John's position on hiding bugs and I agree with him 
> that we should work to fix the bug in gcc rather than workaround in 
> octave.


I just test-built octave-2.9.4 with the pre-release version of gcc-4.1.0 
that will appear in Fedora Core 5, and in the next test release (4.1 is 
expected to be finalized before the final release). Octave does not 
crash any more, so I'm assuming that the bug has been fixed in the gcc 
4.1 branch  (the release is about a week newer than the SVN sources John 
tried, and it may have Fedora patches). The question is whether a fix 
will be backported to the 4.0.x branch.

> However, what should be done in the meantime?


It appears to me that this bug affects very few users, so I'm not going 
to push a new release out just for this, particularly considering that 
the bug can be avoided by setting an environment variable. If there is 
another unrelated reason for an update to 2.1.72, or a possible 2.1.73 
release before Fedora Core 5, I'll consider then whether to include the 
patch for this.


> My suggestion is to advise against compiling with gcc-4 until it has 
> been resolved -- maybe add in the README or somewhere appropriate: 
> "Warning: gcc 4.0.0 -> gcc 4.0.x has a bug which might affect ...." 
> where one day, when it is resolved, we can fill in the x.
>
> As for the fc4 packages, I suggest that they should be compiled with 
> gcc32,g++32,g77 available for fc4. This is what I do now when 
> compiling from source and all works well, even when combining with the 
> fc4 lapac, atlas & fftw3 packages (presumably since they are not c++ 
> and not linked against any c++ code, so they are not affected by this 
> bug).
> I do not follow gcc development: does gcc-4 has some "killer feature" 
> which would make using gcc32 to compile octave too big a setback?


Not really. Its just that in my opinion, using non-default compilers for 
a package in any distribution is an ugly hack that should be considered 
a last resort. This problem hasn't seemed to me to be severe enough to 
justify that in this case, given that setting GLIBCXX_FORCE_NEW=1 avoids 
the problem, and it affects relatively few users.


> IF we do it this way we have a rpm which we know is free of this bug 
> without hiding anything, or patching octave, just avoiding buggy code 
> by using a bug-free version of gcc.


...

> John W. Eaton wrote:
>
> > BTW, I tried building Octave with the current SVN sources of GCC to
> > see if the problem was already fixed.  Unfortunately it was not.
> > Doubly unfortunate is that the C++ compiler seems much slower now
> > (maybe more optimizations?) and it took >10 minutes to create
> > liboctinterp.so.  Would someone like to verify this problem and
> > compare the build times (possibly also timing some individual steps
> > like creating shared libraries) between GCC 3.4, 4.0, and the current
> > SVN sources of GCC?  If GCC built from the current sources is really
> > as slow as I experienced (and the problem wasn't due to something
> > stupid that I did) then I think we need to report the problem.

I didn't pay very close attention during the build, but I did notice 
that it seemed slower, and that some of the linking seemed particularly 
slow. I don't have time right now for creating a formal report on the 
problem. Maybe later. Anyone else tried this yet?

-Quentin



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

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