When the default octave package from 'emerge octave' is built with the new gcc-3.4.1-r3 (or any gcc-3.4.x) it gives a segmentation fault when run. Octave builds fine, and by default uses -fPIC shared libraries. If the .ebuild file is modified to use static, then the resulting octave builds and runs. Reproducible: Always Steps to Reproduce: 1. emerge gcc (with gcc-3.4.x) 2. emerge octave 3. ./octave Actual Results: free(): invalid pointer 0x8a51fd8! panic: Segmentation fault -- stopping myself... attempting to save variables to 'octave-core'... save to 'octave-core' complete Segmentation fault Expected Results: octave> If you comment out the "use static ||..." line in the ebuild for octave-2.1.57-x then octave builds fine with CFLAGS="-march=athlon -O2 -pipe", but by default the version with shared libraries gives the segfault. Using -march=i486 doesn't help either.
same thing here, octave just won't work
(In reply to comment #0) > When the default octave package from 'emerge octave' is built with the new gcc-3.4.1-r3 (or any gcc-3.4.x) it gives a segmentation fault when run. Octave builds fine, and by default uses -fPIC shared libraries. If the .ebuild file is modified to use static, then the resulting octave builds and runs. > > Reproducible: Always > Steps to Reproduce: > 1. emerge gcc (with gcc-3.4.x) > 2. emerge octave > 3. ./octave > > Actual Results: > free(): invalid pointer 0x8a51fd8! > panic: Segmentation fault -- stopping myself... > attempting to save variables to 'octave-core'... > save to 'octave-core' complete > Segmentation fault > > Expected Results: > octave> > > If you comment out the "use static ||..." line in the ebuild for octave-2.1.57-x > then octave builds fine with CFLAGS="-march=athlon -O2 -pipe", but by default > the version with shared libraries gives the segfault. Using -march=i486 doesn't > help either. Hello, With my computer Octave works correctly. I've installed: i686-pc-linux-gnu-gcc (GCC) 3.4.4 (Gentoo 3.4.4, ssp-3.4.4-1.0, pie-8.7.8) "OCTAVE 2.1.69" "GLIBC-1.2.10" On "/etc/make.conf" I set: CFLAGS="-O9 -march=athlon-xp -fomit-frame-pointer -ffast-math" No USE flag I set to compile Octave... (I left default USE flags specified for Octave) USE="-blas -emacs -hdf5 -ifc -mpi +readline -static +tetex +zlib" then After I did: # emerge octave # ./octave GNU Octave, version 2.1.69 (i686-pc-linux-gnu). ... (cut) (cut) ... octave:1> y = [1 3 4 2 1 5 3 5 6 7 4 5 7 10 11 3]; octave:2> g = [1 1 1 1 1 1 1 2 2 2 2 2 2 3 3 3]; octave:3> anova(y,g); One-way ANOVA Table: Source of Variation Sum of Squares df Empirical Var ********************************************************* Between Groups 72.3903 2 36.1951 Within Groups 58.7619 13 4.5201 --------------------------------------------------------- Total 131.1522 15 Test Statistic f 8.0075 p-value 0.0054 octave:4> quit # It's Ok, Octave works and didn't crash. Bye. TorbaX.
I also had this problem on a pentium-m machine with gcc-3.4.4. The output after trying to run octave was, panic: Aborted -- stopping myself... terminate called after throwing an instance of 'std::length_error' what(): basic_string::_S_create panic: attempted clean up apparently failed -- aborting... Aborted
I think I've figured it out. Checking the bt from octave gives a hint: #3 0xa5dffff8 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string () from /usr/lib/libstdc++-v3/libstdc++.so.5 #4 0xa5e63574 in Fdispatch_help () from /usr/libexec/octave/2.1.69/site/oct/i686-pc-linux-gnu/octave-forge/dispatch.oct #5 0xa5e64286 in Fdispatch () Octave uses octave-forge on startup. But, octave-forge depends on octave, so when you do `emerge -e world` after updating gcc-3.3 -> 3.4, octave is rebuilt to use gcc-3.4 at some point. Meanwhile octave-forge is using gcc-3.3. At this point octave is borked. Then when emerge gets to octave-forge, the build fails because octave is run (and promptly dies) during the configure stage of octave-forge. For some reason octave-forge doesn't let a little thing like a segfault stop it, and keeps right on building. 10 minutes later, the build fails as a direct result of the borked configuration. In the end, you're left with octave unable to start, since octave-forge is still out of date. The answer is: emerge -C octave-forge emerge octave-forge So I guess the bug is with octave-forge?
As the last comment says, you need to have everything compiled with gcc-3.4, so this isn't a gcc-porting problme. I don't know if the sci team wants to fix the configure so it actually works properly, so I'm reassigning this to them so they can decide.
I think that this is covered by the upgrade guide, but basically a lot of apps break when you mix 3.3 and 3.4 (or 4.0 for that matter). I am not certain how the configure script should be changed to account for this, but many things break if you do not recompile your entire system. Marking as WORKSFORME on a pure GCC 3.4 system.