Re: [Octave-bug-tracker] [bug #33927] Immediate "segmentation fault" when running octave 3.4.2 on CentOS 5.6

[Ken Nishimura]

All -

First,  I would love to be using Savannah to reply, but I have lost my password and the password reset isn't working (bug submitted)...

Second, 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:

../../run-octave -f -q -H ./mk_doc_cache.m doc-cache ../../scripts/DOCSTRINGS ../../src/DOCSTRINGS || { rm -f doc-cache; exit 1; }
/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 options passed are: 

$ ./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/li
b64 -Wl,-rpath-link -Wl,/opt/gcc-4.6.2/lib64 -L/opt/gcc-4.6.2/lib64 --prefix=/op
t/octave-3.6.1 --without-curl

ldd of liboctave/.libs/liboctave.so.1

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




Rik wrote:

Follow-up Comment #6, bug #33927 (project octave):

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

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?33927>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/