[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Octave chokes on this in some systems

From: Quentin Spencer
Subject: Re: Octave chokes on this in some systems
Date: Mon, 12 Dec 2005 13:59:00 -0600
User-agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)

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


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

Octave's home on the web:
How to fund new projects:
Subscription information:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]