Date: Tue, 12 Jan 2016 17:31:32 -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, you.akira.noda@gmail.com, chat95@mac.com Subject: Re: svn commit: r405907 - head/Mk Message-ID: <201601130131.u0D1VWBL096791@gw.catspoiler.org> In-Reply-To: <56958B1A.8000602@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 05:03 PM, Montgomery-Smith, Stephen wrote: >> 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. >> > > > I tried building with clang, and it worked!!!!! Yeah. I'm adding maho@ > to the list if recipients. It appears to be a bug in the libc++ headers bundled with clang 3.4.1. I was able to build octave on HEAD with clang 3.7.0 without these patches. I'm not too surprised since I ran into problems with <map> when building devel/libxs on FreeBSD 10. I wasn't able to figure out a way to patch the source to work around the problem, so I ended up cloning the broken c++ header files and applying an upstream patch to them.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201601130131.u0D1VWBL096791>