Wed 29 Feb 2012 06:38:45 PM UTC, comment #9:
gcc 4.1.2 seems to work. No immediate crash!
Thanks...
Ken
|
Wed 29 Feb 2012 04:46:13 AM UTC, comment #8:
3.6.1 has a patch specifically for the seg fault
problem when compiling on RHEL 5 using gcc 4.1.2.
I compiled it on a RHEL 5 system and it runs correctly.
The RHEL 5 system that I used is at the current update
level from RedHat. This might be relevant.
|
Wed 29 Feb 2012 04:31:27 AM UTC, comment #7:
I would love to test this, but I've now spent way too many hours
trying to fight a compile issue. I am running stock RHEL5, so the gcc is old (4.1.2), so in keeping with the request, I retrieved and compiled (successfully, I hope) gcc 4.6.2. I am trying to compile octave 3.6.1 using this 4.6.2 gcc package and end up in shared library hell.
The operative error is of the form:
/mnt/dogbert.tmp2/octave-3.6.1/src/.libs/lt-octave:
/usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by /mnt/dogbert.tmp2/octave-3.6.1/src/.libs/liboctinterp.so.1)
/mnt/dogbert.tmp2/octave-3.6.1/src/.libs/lt-octave:
/usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /mnt/dogbert.tmp2/octave-3.6.1/src/.libs/liboctinterp.so.1)
/mnt/dogbert.tmp2/octave-3.6.1/src/.libs/lt-octave:
/usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /mnt/dogbert.tmp2/octave-3.6.1/src/.libs/liboctinterp.so.1)
/mnt/dogbert.tmp2/octave-3.6.1/src/.libs/lt-octave:
/usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /mnt/dogbert.tmp2/octave-3.6.1/liboctave/.libs/liboctave.so.1)
/*mnt/dogbert.tmp2/octave-3.6.1/src/.libs/lt-octave:
/usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /mnt/dogbert.tmp2/octave-3.6.1/liboctave/.libs/liboctave.so.1)
The configure command for octave attempted to use rpath....
$ ./configure GCC=/opt/gcc-4.6.2/bin/gcc-4.6.2 CXX=/opt/gcc-4.6.2/bin/g++-4.6.2 F77=/opt/gcc-4.6.2/bin/gfortran-4.6.2 LDFLAGS=-Wl,-rpath -Wl,/opt/gcc-4.6.2/lib64 -Wl,-rpath-link -Wl,/opt/gcc-4.6.2/lib64 -L/opt/gcc-4.6.2/lib64
--prefix=/opt/octave-3.6.1 --without-curl
ldd of liboctave/.libs/liboctave.so.1 shows:
libstdc++.so.6 (CXXABI_1.3.1) => /opt/gcc-4.6.2/lib/../lib64/libstdc++.so.6
libstdc++.so.6 (GLIBCXX_3.4.9) =>
/opt/gcc-4.6.2/lib/../lib64/libstdc++.so.6
libstdc++.so.6 (CXXABI_1.3) =>
/opt/gcc-4.6.2/lib/../lib64/libstdc++.so.6
* libstdc++.so.6 (GLIBCXX_3.4.15) =>
/opt/gcc-4.6.2/lib/../lib64/libstdc++.so.6*
libstdc++.so.6 (GLIBCXX_3.4) =>
/opt/gcc-4.6.2/lib/../lib64/libstdc++.so.6
/mnt/dogbert.tmp2/octave-3.6.1/libcruft/.libs/libcruft.so.1:
libstdc++.so.6 (CXXABI_1.3) =>
/opt/gcc-4.6.2/lib/../lib64/libstdc++.so.6
libstdc++.so.6 (GLIBCXX_3.4) =>
/opt/gcc-4.6.2/lib/../lib64/libstdc++.so.6
shows that the rpath is working, but still, it keeps going back to the original /usr/lib64/libstdc++.so.6 library which is OLD.
What is wrong here?
Ken
|
Mon 27 Feb 2012 05:55:09 PM UTC, comment #6:
Can the reporter verify whether this is still a problem with a recent version of gcc and the latest Octave source code (3.6.1)?
|
Wed 10 Aug 2011 10:05:44 PM UTC, comment #5:
Note that RH 5.7 ships with gcc 4.1.2...
|
Wed 10 Aug 2011 04:25:27 PM UTC, comment #4:
I think this is a duplicate of
https://savannah.gnu.org/bugs/?func=detailitem&item_id=30685#options
In that report, the problem was occurring with old versions of GCC (4.1.x and 4.2.x) but not newer ones, so I'm surprised that the problem is happening now with GCC 4.4.x.
|
Tue 09 Aug 2011 11:31:28 PM UTC, comment #3:
FWIW, I have the exact same problem after compiling 3.4.2 in a RedHat 5.7 environment. The backtrace is:
(gdb) bt
#0 0x00002aaaabacac28 in sigemptyset ()
from /mnt/dogbert.tmp2/octave-3.4.2/src/.libs/liboctinterp.so.0
#1 0x00002aaaab07e4a1 in octave_set_signal_handler (sig=2,
handler=0x2aaaab07ea10 <sigint_handler(int)>, restart_syscalls=true)
at sighandlers.cc:225
#2 0x00002aaaab07e56a in octave_catch_interrupts () at sighandlers.cc:460
#3 0x00002aaaab07e5d3 in install_signal_handlers () at sighandlers.cc:529
#4 0x00002aaaab050ef7 in octave_main (argc=6, argv=0x7fffffffd858, embedded=0)
at octave.cc:665
#5 0x000000336901d994 in __libc_start_main () from /lib64/libc.so.6
#6 0x0000000000400639 in _start ()
Machine is:
Linux vienna 2.6.18-274.el5 #1 SMP Fri Jul 8 17:36:59 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux
Sorry the code isn't inline, but I can't find the magic widget!
|
Wed 03 Aug 2011 11:21:49 AM UTC, comment #2:
[that's why I spoke about a "strace output" and not a "stack trace" in my original post :-)]
Here is the stack trace. HTH
|
Tue 02 Aug 2011 02:51:39 PM UTC, comment #1:
That's not really a stack trace. It's strace output (s here means "system calls", not "stack"), which can be useful later, but is very noisy for now. Can you please provide a stack trace? Do this:
and that should make gdb give you a stack trace. That may be more helpful to diagnose the problem.
|
Tue 02 Aug 2011 11:16:39 AM UTC, original submission:
Running octave 3.4.2 (or ./run-octave just after installation) on CentOS 5.6 results in immediate "Segmentation fault". Same problem when compiling with gcc 4.1.2 and gcc 4.4.4.
Configure commandline:
Environment variables set:
A complete strace output is attached as gzipped textfile.
ldd output below:
System information: CentOS 5.6, fully updated, Kernel 2.6.18-238.19.1.el5, x86_64 system.
Please let me know if I can provide additional informations to fix this.
|