[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #33927] Immediate "segmentation fault" when ru
From: |
Ken Nishimura |
Subject: |
[Octave-bug-tracker] [bug #33927] Immediate "segmentation fault" when running octave 3.4.2 on CentOS 5.6 |
Date: |
Wed, 29 Feb 2012 04:31:27 +0000 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110927 Red Hat/3.6-1.el4 Firefox/3.6.23 |
Follow-up Comment #7, bug #33927 (project octave):
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
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?33927>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/