From owner-svn-ports-all@freebsd.org Tue Jan 12 22:53:10 2016 Return-Path: Delivered-To: svn-ports-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 72B07A6DACA; Tue, 12 Jan 2016 22:53:10 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4A8C515ED; Tue, 12 Jan 2016 22:53:10 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id u0CMqwxo087657; Tue, 12 Jan 2016 14:53:02 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201601122253.u0CMqwxo087657@gw.catspoiler.org> Date: Tue, 12 Jan 2016 14:52:58 -0800 (PST) From: Don Lewis Subject: Re: svn commit: r405907 - head/Mk To: stephen@missouri.edu cc: stephen@FreeBSD.org, ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org In-Reply-To: <56957DCF.3090209@missouri.edu> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: svn-ports-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the ports tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 22:53:10 -0000 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 , dst_type=0x8033ecd40 >, src2dst=0) at ../../.././../gcc-4.8.5/libstdc++-v3/libsupc++/dyncast.cc:72 #2 0x0000000803188650 in std::has_facet > (__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 >::_M_cache_locale (this=this@entry=0x803406ea8 , __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 >::init ( this=this@entry=0x803406ea8 , __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 >::basic_ostream (__sb=, this=, __in_chrg=, __vtt_parm=) 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=) 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') to 'const_iterator' (aka '__map_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 >, std::__1::less, std::__1::allocator > > > >::end' req uested here insert(__m.begin(), __m.end()); ^