Date: Tue, 12 Jan 2016 14:52:58 -0800 (PST) From: Don Lewis <truckman@FreeBSD.org> To: stephen@missouri.edu Cc: stephen@FreeBSD.org, ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: Re: svn commit: r405907 - head/Mk Message-ID: <201601122253.u0CMqwxo087657@gw.catspoiler.org> In-Reply-To: <56957DCF.3090209@missouri.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12 Jan, Montgomery-Smith, Stephen wrote: > On 01/12/2016 03:48 PM, Don Lewis wrote: >> On 12 Jan, Stephen Montgomery-Smith wrote: >>> Author: stephen >>> Date: Tue Jan 12 19:56:13 2016 >>> New Revision: 405907 >>> URL: https://svnweb.freebsd.org/changeset/ports/405907 >>> >>> Log: >>> - Svn revision 405533 upgraded /math/octave to version 4.0.0. This version >>> of octave segfaults with FreeBSD. Many of the octave-forge-* ports don't >>> build, and those that build don't work. So they are all being marked >>> broken until it is fixed. >> >> It's actually octave-gui that is segfaulting. The cause is that the >> executable is bringing in both libstdc++ and libc++, and the reason for >> that is likely the addition of USE_GCC=yes to the port Makefile that was >> done at the same time as the version upgrade. >> >> I have no idea what happens if USE_GCC=yes is removed from the Makefile. >> there may be problems with compiling the source with the combination of >> clang and gfortran. I'll give it a try, though. >> >> Another possibility would be do disable the gui. Looking at configure, >> there is a --disable-gui option that we don't expose as a port option. I >> don't know what libraries are needed by the gui, but of all the >> libraries in LIB_DEPENDS, libfltk.so, libftgl.so, and libqscintilla2.so >> are the ones that are linked to libc++.so. >> >> Unfortunately, "octave --no-gui" doesn't work. It still tries to run >> octave-gui and dies. >> >> >> > > > I had a different experience. The octave-cli command segfaulted for me. > I run it through gdb (version 7.10) and valgrind after building octave > with the "-g" option set. It looks like the error takes place before > any code is actually run, indicating that probably global data > allocation may be the problem. The error is freeing the NULL pointer. I can confirm that octave-cli also segfaults in the same wat. It looks like a call to a NULL function pointer, though. (gdb) run Starting program: /usr/local/bin/octave-cli [New Thread 80fc06400 (LWP 101439)] [New Thread 80fc06c00 (LWP 100931)] [New Thread 80fc06800 (LWP 100718)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 80fc06400 (LWP 101439)] 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? () #1 0x000000080315c8c8 in __cxxabiv1::__dynamic_cast ( src_ptr=0x8034081c0 <(anonymous namespace)::ctype_c>, src_type=0x8033ecfb0 <typeinfo for std::locale::facet>, dst_type=0x8033ecd40 <typeinfo for std::ctype<char>>, src2dst=0) at ../../.././../gcc-4.8.5/libstdc++-v3/libsupc++/dyncast.cc:72 #2 0x0000000803188650 in std::has_facet<std::ctype<char> > (__loc=...) at /wrkdirs/usr/ports/lang/gcc/work/build/x86_64-portbld-freebsd10.2/libstdc++-v3/include/bits/locale_classes.tcc:110 #3 0x000000080317d634 in std::basic_ios<char, std::char_traits<char> >::_M_cache_locale (this=this@entry=0x803406ea8 <std::cout+8>, __loc=...) at /wrkdirs/usr/ports/lang/gcc/work/build/x86_64-portbld-freebsd10.2/libstdc++-v3/include/bits/basic_ios.tcc:159 #4 0x000000080317d780 in std::basic_ios<char, std::char_traits<char> >::init ( this=this@entry=0x803406ea8 <std::cout+8>, __sb= 0x803406780 <__gnu_internal::buf_cout_sync>) at /wrkdirs/usr/ports/lang/gcc/work/build/x86_64-portbld-freebsd10.2/libstdc++-v3/include/bits/basic_ios.tcc:132 #5 0x000000080316fb91 in std::basic_ostream<char, std::char_traits<char> >::basic_ostream (__sb=<optimized out>, this=<optimized out>, __in_chrg=<optimized out>, __vtt_parm=<optimized out>) at /wrkdirs/usr/ports/lang/gcc/work/build/x86_64-portbld-freebsd10.2/libstdc++-v3/include/ostream:85 #6 std::ios_base::Init::Init (this=<optimized out>) at ../../../.././../gcc-4.8.5/libstdc++-v3/src/c++98/ios_init.cc:91 #7 0x0000000801e3e590 in _GLOBAL__sub_I_Array_b.cc () from /usr/local/lib/octave/4.0.0/liboctave.so.3 #8 0x0000000800605b77 in ?? () from /libexec/ld-elf.so.1 #9 0x00000008006050ee in ?? () from /libexec/ld-elf.so.1 #10 0x0000000800603439 in ?? () from /libexec/ld-elf.so.1 #11 0x0000000000000000 in ?? () octave-gui is also linked to both libstdc++ and libc++: %ldd /usr/local/bin/octave-cli | grep ++ libstdc++.so.6 => /usr/local/lib/gcc48/libstdc++.so.6 (0x803100000) libc++.so.1 => /usr/lib/libc++.so.1 (0x80d49d000) and the segfault at startup time is the typical symptom of that. Even though it is only a command-line version, it does link to some X11 stuff, including: libGL.so.1 => /usr/local/lib/libGL.so.1 (0x805859000) libGLU.so.1 => /usr/local/lib/libGLU.so.1 (0x805b55000) libX11.so.6 => /usr/local/lib/libX11.so.6 (0x805dd7000) libnvidia-tls.so.1 => /usr/local/lib/libnvidia-tls.so.1 (0x80ad16000) libnvidia-glcore.so.1 => /usr/local/lib/libnvidia-glcore.so.1 (0x80b000000) libXext.so.6 => /usr/local/lib/libXext.so.6 (0x80d28c000) libXi.so.6 => /usr/local/lib/libXi.so.6 (0x80dda1000) libXmu.so.6 => /usr/local/lib/libXmu.so.6 (0x80dfaf000) libXau.so.6 => /usr/local/lib/libXau.so.6 (0x80e849000) libXdmcp.so.6 => /usr/local/lib/libXdmcp.so.6 (0x80ec4c000) libXt.so.6 => /usr/local/lib/libXt.so.6 (0x80ee51000) libSM.so.6 => /usr/local/lib/libSM.so.6 (0x80f0b3000) libICE.so.6 => /usr/local/lib/libICE.so.6 (0x80f2ba000) In this case, libGLU appears to be what is bringing in libc++. My attempt at removing USE_GCC=yes failed. I'm getting this compile error: In file included from corefcn/defun.h:30: In file included from corefcn/defun-int.h:28: In file included from ./octave-value/ov-builtin.h:28: In file included from ./octave-value/ov-fcn.h:34: In file included from corefcn/symtab.h:29: /usr/include/c++/v1/map:976:50: error: no viable conversion from 'const_iterator ' (aka '__tree_const_iterator<value_type, __node_pointer, difference_type>') to 'const_iterator' (aka '__map_const_iterator<typename __base::const_iterator>') const_iterator end() const _NOEXCEPT {return __tree_.end();} ^~~~~~~~~~~~~ /usr/include/c++/v1/map:885:37: note: in instantiation of member function 'std:: __1::map<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> >, std::__1::less<cdef_class>, std::__1::allocator<std::__1::pair<const cdef_cla ss, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > > > >::end' req uested here insert(__m.begin(), __m.end()); ^
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201601122253.u0CMqwxo087657>