svn commit: r405907 - head/Mk

[Montgomery-Smith, Stephen]

On 01/12/2016 04:52 PM, Don Lewis wrote:
> 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.

I got this email from Noda Akira, who submitted the original PR.  (I
added his email address to the receipients.)  I just tried it, and it
didn't fix it.  But now I am trying it using clang instead of gcc to
build it.

Hi
I think some patch file is missed.

patch-libinterp-octave-value-ov-classdef.cc
patch-libinterp-octave-value-ov-classdef.h
#
#Please see this attachment of the PR site
#https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201737
#

Without this, you will always have core dump (with gcc)
I think clang can not build this source with out patch.