svn commit: r405907 - head/Mk
Don Lewis
truckman at FreeBSD.org
Tue Jan 12 22:53:10 UTC 2016
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 at 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 at 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());
^
More information about the svn-ports-head
mailing list