On Sat, 16 Nov 2013 08:54:55 -0800 Steve Kargl wrote: > On Sat, Nov 16, 2013 at 01:58:11PM +0100, Tijl Coosemans wrote: >> On Tue, 12 Nov 2013 14:40:42 -0800 Steve Kargl wrote: >>> On Tue, Nov 12, 2013 at 10:19:46PM +0100, Tijl Coosemans wrote: >>>> On Tue, 12 Nov 2013 12:19:22 -0800 Steve Kargl wrote: >>>>> This can't be good. And, unfortunately, testing math/octave shows >>>>> no better :( >>>>> >>>>> % octave >>>>> Segmentation fault (core dumped) >>>>> % ldd /usr/local/bin/octave-3.6.4 | grep ++ >>>>> libstdc++.so.6 => /usr/local/lib/gcc46/libstdc++.so.6 (0x3c92ec000) >>>>> libc++.so.1 => /usr/lib/libc++.so.1 (0x3c9801000) >>>> >>>> This could be because you enabled the OPENMP option in math/fftw3. >>> >>> Unfortuantely, that's not it. Just rebuilt fftw3 and octave still >>> dies. ldd shows that /usr/local/lib/octave/3.6.4/liboctinterp.so.1 >>> is bringing in both libc++ and libstdc++, but it is also linked >>> to 52 other libraries. >> >> USE_FORTRAN=yes currently implies USE_GCC=yes so the C++ code in >> math/octave links with libstdc++ while dependencies link with libc++. >> Gerald, is it possible to separate USE_FORTRAN from USE_GCC? > > This isn't the problem. gfortran does not pull libstdc++.so into > the build. As pointed out in another email, libGL, libGLU, fltk, > and libgraphite2 all were linked to libc++ and libstdc++. Recompiling > those ports with USE_GCC=any, fixed octave. The math/octave Makefile has USE_FORTRAN=yes (FC=gfortran46). This currently implies USE_GCC=yes (CC=gcc46, CXX=g++46) which pulls in libstdc++. If this could be changed (i.e. FC=gfortran46, CC=cc, CXX=c++) you would not have to add USE_GCC to the dependencies.Received on Sat Nov 16 2013 - 16:14:58 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:44 UTC