bugGNU Octave - Bugs: bug #43298, llvm libc++ 3.5 fails to resolve...


bug #43298: llvm libc++ 3.5 fails to resolve the pow(octave_int<int>, octave_Int<int>) function overload

Submitter:  None
Submitted:  Thu 25 Sep 2014 03:31:54 AM UTC
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  3 - Low Item Group:  Build Failure
Status:  Postponed Assigned to:  None
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * dev
Operating System:  * Any Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


( Jump to the original submission )

Mon 08 Aug 2016 06:09:01 PM UTC, comment #47: 

Closing report.  This seems to have been fixed by upgrades to Xcode by Apple, and there is no one with interest to write the backport for LLVM 3.5 anyways.

Rik <rik5>
Project Administrator
Fri 01 Jul 2016 05:48:01 AM UTC, comment #46: 

The patch is applied by the Mac package managers if an old version of clang is detected, see [1-2]. I recall that you did not like this. However, a proper solution as you described in #37 was not implemented.

[1] https://trac.macports.org/browser/trunk/dports/math/octave/Portfile
[2] https://github.com/Homebrew/homebrew-science/blob/master/octave.rb

Sebastian <sschoeps>
Fri 01 Jul 2016 02:41:18 AM UTC, comment #45: 

It's been several months since anyone has expressed any interest in working on this bug. Have the mac tools advanced (and users upgraded their systems) to the point that we don't care about fixing this anymore?

Mike Miller <mtmiller>
Project Administrator
Fri 02 Oct 2015 05:14:14 PM UTC, comment #44: 

Maybe the information at the link below can help?


Alternatively, the Mac OS X Carbon framework supports off-screen rendering.


I don't know how similar it is to OSMesa

Ben Abbott <bpabbott>
Project Member
Fri 02 Oct 2015 12:59:30 PM UTC, comment #43: 

Ok, so it seems that latest updates to the Mac developer tools pulled in a fixed version of llvm libc++ so a lot of affected users don't need this fixed any more. But it would still affect users on llvm 3.5, e.g. current Debian stable.

It would not be unprecedented to have a workaround in Octave for an older compiler or tool, if someone is still motivated to work up a fix for this. Most of the pieces needed to fix this are here, just needs someone to combine them into an acceptable changeset. Leaving open for now.

Mike Miller <mtmiller>
Project Administrator
Fri 02 Oct 2015 06:43:17 AM UTC, comment #42: 

Yes, same here; "include-fix.patch" is not necessary anymore (clang 7, darwin15). However, still no good solution for linking with mesalib.

Sebastian <sschoeps>
Thu 01 Oct 2015 09:15:36 PM UTC, comment #41: 


I just reversed include-fix.patch and was able to build without errors.

Can you confirm that this problem has also be fixed for you?

diff --git a/libinterp/corefcn/comment-list.h b/libinterp/corefcn/comment-list.h
index 2f2c4d5..18df774 100644
--- a/libinterp/corefcn/comment-list.h
+++ b/libinterp/corefcn/comment-list.h
@@ -25,7 +25,7 @@

 #include <string>

-#include <base-list.h>
+#include "base-list.h"

 extern std::string get_comment_text (void);

diff --git a/libinterp/corefcn/oct.h b/libinterp/corefcn/oct.h
index c6d21ad..db06357 100644
--- a/libinterp/corefcn/oct.h
+++ b/libinterp/corefcn/oct.h
@@ -28,7 +28,7 @@
 // config.h needs to be first because it includes #defines that can */
 // affect other header files.

-#include <config.h>
+#include "config.h"

 #include "Matrix.h"


Ben Abbott <bpabbott>
Project Member
Thu 01 Oct 2015 08:48:06 PM UTC, comment #40: 

I'm using the most recent Xcode on Yosemite (10.10.5).

$ clang --version
Apple LLVM version 7.0.0 (clang-700.0.72)
Target: x86_64-apple-darwin14.5.0
Thread model: posix

And am also now able to build without the clang-libcc-fix.patch.

Ben Abbott <bpabbott>
Project Member
Thu 01 Oct 2015 06:24:36 PM UTC, comment #39: 

This was a bug in LLVM 3.5 (?) so the problem might also affect non-apple platforms. However, good news: apple fixed it (finally). The latest xcode (e.g. shipped with El Capitan) does not need the patch anymore.

I will update the homebrew formula such that clang-libcxx-fix.patch is only applied if clang_version < 7.0

Sebastian <sschoeps>
Wed 23 Sep 2015 11:38:00 PM UTC, comment #38: 

In the interest of the "bus factor" mention at OctConf recently, attaching my unfinished work so far done during the code sprint session.

(file #34968)

Mike Miller <mtmiller>
Project Administrator
Sat 12 Sep 2015 09:40:52 PM UTC, comment #37: 

Since I just pushed the fix for bug #41178, I assume solving this one will be next for OSX users.

What I'm hoping for is an approach similar to the solution for bug #40436, with a configure.ac check that determines whether the std::pow error is present or not. As I said before, see the OCTAVE_CHECK_BROKEN_STL_ALGO_H macro for something to base this on.

Mike Miller <mtmiller>
Project Administrator
Wed 29 Jul 2015 05:51:39 PM UTC, comment #36: 

We definitely don't want to inflict pain on other users or ourselves for Apple's shortcomings.

Can segregate this patch to only apply on Mac systems with the _APPLE_ macro?

Rik <rik5>
Project Administrator
Wed 29 Jul 2015 12:29:03 AM UTC, comment #35: 

Ugh, so this means Apple is still shipping libc++ at some 3.5 version with clang 3.6? This should really be fixed by the vendor, how much do we want to work around Apple's shortcomings?

If we really have to, the supplied patch seems mostly harmless to me, except it would be much nicer to use a feature test for this failure instead of applying it unconditionally for all libc++. For example, on my Debian system, _LIBCPP_VERSION is 1101, but this patch is not needed. So the current #if condition is not correct for me.

We have a similar check for a bug in some intermediate version of gcc, that could be adapted to this compiler bug. See OCTAVE_CHECK_BROKEN_STL_ALGO_H in m4/acinclude.m4. I would like to see something similar if we're going to patch around this bug in the LLVM libc++.

Mike Miller <mtmiller>
Project Administrator
Mon 27 Jul 2015 04:58:10 PM UTC, comment #34: 

Mike/All, I've reopened this one, changed the status to "Postponed", and changed the OS to "Mac OS".

This clang bug remains in Apple's version of clang 3.6.

Except for the API, does applying the patch break anything in Octave?

If not can some preprocessor magic be used to only apply this fix on Mac OS X?

Ben Abbott <bpabbott>
Project Member
Sun 12 Apr 2015 04:08:48 AM UTC, comment #33: 

I can confirm that upgrading to the clang 3.6 compiler resolves this particular error (the bug fix referenced in comment #30). I think we can call this one a compiler bug that has been resolved, not a bug in Octave. Marking as invalid because the fix is external to Octave.

Mike Miller <mtmiller>
Project Administrator
Tue 17 Feb 2015 11:49:48 PM UTC, comment #32: 

The current devel system cannot be configured
as --with-jit due to changes in the llvm files.
If this is fixed, the compile fails due to other
changes in the API.

So, without considerable work, JIT cannot be made
functional for 4.0. Ugh!

Michael Godfrey <godfrey>
Project Member
Tue 17 Feb 2015 11:41:50 PM UTC, comment #31: 

Has this been resolved upstream by LLVM?  Is there anything Octave should do before the 4.0 release?

Rik <rik5>
Project Administrator
Fri 17 Oct 2014 01:26:18 PM UTC, comment #30: 

LLVM has fixed the bug of http://llvm.org/bugs/show_bug.cgi?id=21083 .

so from the "less is more"'s perspective, the investigation for removing double/float conversion is still interesting, but it's not relavent to this bug anymore, IMHO.

Kefu Chai <tchaikov>
Thu 16 Oct 2014 03:13:19 PM UTC, comment #29: 

> Can you verify in the Octave interpreter that both double(int32(42)) and single(int32(42)) give you 42?

warning: docstring file '/Users/kefu/dev/octave/build/libinterp/DOCSTRINGS' not found
warning: readline is not linked, so history control is not available
GNU Octave, version 3.9.0+
Copyright (C) 2013 John W. Eaton and others.
This is free software; see the source code for copying conditions.
FITNESS FOR A PARTICULAR PURPOSE.  For details, type 'warranty'.

Octave was configured for "x86_64-apple-darwin14.0.0".

Additional information about Octave is available at http://www.octave.org.

Please contribute if you find this software useful.
For more information, visit http://www.octave.org/get-involved.html

Read http://www.octave.org/bugs.html to learn how to submit bug reports.
For information about changes from previous versions, type 'news'.

octave:1> double(int32(42))
ans =  42
octave:2> single(int32(42))
ans =  42

Kefu Chai <tchaikov>
Thu 16 Oct 2014 01:36:10 PM UTC, comment #28: 

I'm not sure that our test coverage is complete. In fact, we know it's not:


(People of the future: these links are not stable. You can find them again from following the coverage links from here: http://hydra.nixos.org/jobset/gnu/octave-default#tabs-jobs )

I'm actually surprised that you simply removed both double and float conversions and managed to get it to compile with clang. I would have thought the double conversion needed to remain. Also note how our tests aren't testing the pow codepath for single, but this may be unintentionally dead code.

Can you verify in the Octave interpreter that both double(int32(42)) and single(int32(42)) give you 42? John, can you give of other operations that would have exercised the double and float octave_int conversions?

The number of failed tests is a bit alarming, but that's a problem for different bug reports.

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Wed 15 Oct 2014 06:09:49 PM UTC, comment #27: 


the source tree compiles fine with clang 3.5 after removing these conversions. and i ran the tests using `make -C test check`. i have


  PASS     11450
  FAIL        19
  XFAIL        7
  SKIPPED    216

@jordi, thanks for your comment. i am the author of the patch.

> We test for features. Can you write the corresponding autoconf check?

will pull together one. once we are confirmed that to remove the double and float conversion operator does not work out.

> but if the bug only happens with an LLVM version that also has C++11 enabled, it may be ok.

yes. the libc++'s `pow()` template function implementation uses `std::enable_if` also. so i guess it's safe to use C++11 features in the patch.

> the autoconf check would need to verify that C++11 constructs like std::enable_if are available.

agreed. maybe the simpler way is to reevaluate if we really need the `octave_int::operator` of double and float.

Kefu Chai <tchaikov>
Wed 15 Oct 2014 03:55:55 PM UTC, comment #26: 

Has anyone tried removing the double and float conversions?  What breaks?

John W. Eaton <jwe>
Project Administrator
Wed 15 Oct 2014 02:09:45 PM UTC, comment #25: 

Oh, and one more thing (sorry, I'm not finding all of these issues all at once). There's a further thing you would have to check if indeed your original route is the correct one: your patch uses C++11. We don't use C++11 in Octave yet in general, but if the bug only happens with an LLVM version that also has C++11 enabled, it may be ok. In order to be complete, the autoconf check would need to verify that C++11 constructs like std::enable_if are available.

This again makes me think it may be simpler to avoid the checks and just change the octave_int type.

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Wed 15 Oct 2014 02:05:22 PM UTC, comment #24: 

> so you are suggesting an approach something like this?

Yes, that's how autoconf checks work.

I responded on the patch thread, but I'll repeat myself here: I think if we just get rid of the float conversions for octave_int, we might not need any autoconf checks at all. I'm not sure we need both double and float conversions, and I think that having both of them is what triggers the LLVM bug.

The LLVM devs also seem reluctant to fix their bug, since they think that having both conversion types is a weird thing that we don't need to be doing to begin with.

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Sat 11 Oct 2014 05:55:56 PM UTC, comment #23: 

hi john,

thanks for looking at my patch. i am posting it in this bug. will see if i can close the one in patch tracker.

> but rather than testing for library version numbers, we would prefer feature tests in the configure script.

so you are suggesting an approach something like this?

  1. m4: have another m4 macro (CHECK_FOR_BAD_LIBCXX_POW) which includes a minimal c++ test which reproduces this issue. if the c++ file fails to compile, a variable named "BAD_LIBCXX_POW" is defined:
  2. configure.ac: use AM_CONDITION to propagate this variable in the way of "-DWITH_LIBCXX_POW_WORKAROUND) to related makefiles (i.e. {array, numeric, operators}/module.mk)
  3. liboctave: replace the nasty macro of

    #if defined(_LIBCPP_VERSION) && (_LIBCPP_VERSION >= 1101)



(file #32255)

Sat 11 Oct 2014 04:56:49 PM UTC, comment #22: 

If you have a fix for a bug, it's probably best to just attach the change to the bug report instead of posting a separate issue in the patch tracker.  The patch tracker is generally used for patches that implement new features.  Thanks.

Also, I looked at the patch.  It may be OK as a workaround, but rather than testing for library version numbers, we would prefer feature tests in the configure script.

John W. Eaton <jwe>
Project Administrator
Sat 11 Oct 2014 04:50:14 PM UTC, comment #21: 

i posted a patch at https://savannah.gnu.org/patch/index.php?8551. it fixes this issue on octave side.

Fri 26 Sep 2014 07:50:39 PM UTC, comment #20: 

With the help of Agustín Bergé and others in IRC, we have reduced the problem the test case in the following bug report:


Can we wait to see if the LLVM devs can release a bugfix quickly and only implement a workaround in Octave if they take more than a couple of weeks?

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Fri 26 Sep 2014 04:35:58 PM UTC, comment #19: 

Ben: you're compiling with gcc not llvm. I don't think anyone has had a problem doing that. The problem arises when we try to build octave with llvm 3.5 or what is now the current apple compiler (based on 3.5).

(You also have it running with magick, which is a known bug, so if you could explain Id appreciate it, but that's a conversation for outside this bug track.)

Fri 26 Sep 2014 12:48:00 PM UTC, comment #18: 

LLVM 3.4/3.5 is not supported in stable branch. It was fixed for dev branch here: https://savannah.gnu.org/bugs/?41061
(However, missing file TargetData.h is not the error I would expect in this case.)

Stefan Mahr <dac922>
Fri 26 Sep 2014 11:56:32 AM UTC, comment #17: 

I configured using LLVM 3.5,

./configure                                               \
   CC=/opt/local/bin/gcc-mp-4.7                           \
   CFLAGS="-pipe -O2 -m64"                                \
   CPPFLAGS="-D_THREAD_SAFE -I/opt/local/include"         \
   LDFLAGS="-L/opt/local/lib -m64 "                       \
   CXX=/opt/local/bin/g++-mp-4.7                          \
   CXXFLAGS="-pipe -O2 -m64"                              \
   F77=/opt/local/bin/gfortran-mp-4.7                     \
   FFLAGS="-pipe -O2 -m64"                                \
   LLVM_CONFIG=/opt/local/bin/llvm-config-mp-3.5          \
   --disable-jit                                           \
   --with-magick=GraphicsMagick                           \
   --with-lapack="-llapack -latlas -lgfortran"            \
   --with-blas="-lcblas -lf77blas -latlas -lgfortran"     \
   --prefix=/usr/local/octave/3.8.2                       \
   --enable-gui                                           \
   --disable-java                                         \
   --with-framework-carbon                                \
   --with-arpack                                          \
   --enable-docs                                          \
   --with-opengl                                          \
   --without-x                                            \

Configure reported

Octave is now configured for x86_64-apple-darwin13.4.0

  Source directory:            .
  Installation prefix:         /usr/local/octave/3.8.2
  C compiler:                  /opt/local/bin/gcc-mp-4.7   -Wall -W -Wshadow -Wformat -Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings -Wcast-align -Wcast-qual -pipe -O2 -m64 -D_THREAD_SAFE -pthread
  C++ compiler:                /opt/local/bin/g++-mp-4.7   -Wall -W -Wshadow -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -pipe -O2 -m64 -D_THREAD_SAFE -pthread
  Fortran compiler:            /opt/local/bin/gfortran-mp-4.7 -pipe -O2 -m64
  Fortran libraries:            -L/opt/local/lib -L/opt/local/lib/gcc47/gcc/x86_64-apple-darwin13/4.7.4 -L/opt/local/lib/gcc47/gcc/x86_64-apple-darwin13/4.7.4/../../.. -lgfortran -lquadmath -lm
  Lex libraries:
  LIBS:                        -lm

  AMD libraries:               -lamd
  ARPACK libraries:            -larpack
  BLAS libraries:              -lcblas -lf77blas -latlas -lgfortran
  CAMD libraries:              -lcamd
  CARBON libraries:            -Wl,-framework -Wl,Carbon
  CCOLAMD libraries:           -lccolamd
  CHOLMOD libraries:           -lcholmod
  COLAMD libraries:            -lcolamd
  CURL libraries:              -lcurl
  CXSPARSE libraries:          -lcxsparse
  DL libraries:                -ldl
  FFTW3 libraries:             -lfftw3_threads -lfftw3
  FFTW3F libraries:            -lfftw3f_threads -lfftw3f
  fontconfig CFLAGS:           -I/opt/local/include -I/opt/local/include/freetype2 -I/opt/local/include -I/opt/local/include/freetype2 -I/opt/local/include -I/opt/local/include/libpng16
  fontconfig libraries:        -L/opt/local/lib -lfontconfig -lfreetype
  FreeType2 CFLAGS:            -I/opt/local/include/freetype2 -I/opt/local/include -I/opt/local/include/libpng16
  FreeType2 libraries:         -L/opt/local/lib -lfreetype
  GLPK libraries:              -lglpk
  graphics CFLAGS:             -I/opt/local/include -pipe -Os -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT
  graphics libraries:          -L/opt/local/lib -Wl,-headerpad_max_install_names -lfltk_gl -framework AGL -framework OpenGL -framework ApplicationServices -lfltk -lpthread -framework Cocoa
  HDF5 libraries:              -lhdf5
  Java home:
  Java JVM path:
  Java libraries:
  LAPACK libraries:            -llapack -latlas -lgfortran
  LLVM libraries:
  Magick++ CPPFLAGS:           -I/opt/local/include/GraphicsMagick
  Magick++ LDFLAGS:            -L/opt/local/lib
  Magick++ libraries:          -lGraphicsMagick++ -lGraphicsMagick
  OPENGL libraries:            -L/opt/local/lib -lfontconfig -lfreetype  -Wl,-framework -Wl,OpenGL
  PCRE CPPFLAGS:               -I/opt/local/include
  PCRE libraries:              -L/opt/local/lib -lpcre
  PTHREAD flags:               -D_THREAD_SAFE -pthread
  PTHREAD libraries:
  QHULL libraries:             -lqhull
  QRUPDATE libraries:          -lqrupdate
  Qt CPPFLAGS:                 -I/opt/local/include -I/opt/local/include/QtGui -I/opt/local/include -I/opt/local/include/QtNetwork -I/opt/local/include -I/opt/local/include/QtCore
  Qt LDFLAGS:                  -L/opt/local/lib
  Qt libraries:                -lQtGui -lQtNetwork -lQtCore  -lqscintilla2
  READLINE libraries:          -lreadline
  TERM libraries:              -lncurses
  UMFPACK libraries:           -lumfpack
  X11 include flags:
  X11 libraries:
  Z libraries:                 -lz

  Default pager:               less
  gnuplot:                     gnuplot

  Build Octave GUI:                   yes
  JIT compiler for loops:             no
  Build Java interface:               no
  Do internal array bounds checking:  no
  Use octave_allocator:               no
  Build static libraries:             no
  Build shared libraries:             yes
  Dynamic Linking:                    yes (dlopen)
  Include support for GNU readline:   yes
  64-bit array dims and indexing:     no

configure: WARNING: Missing LLVM file TargetData.h.  JIT compiler is disabled.
configure: NOTE: Libraries or auxiliary programs may be skipped if they are
configure: NOTE: not found OR if they are missing required features on your
configure: NOTE: system.

I haven't tracked down the missing TargetData.h problem, but I am able to build and run Octave-3.8.2.  Notice, I'm using gcc-4.7, not Apple's clang, as my compiler.

Ben Abbott <bpabbott>
Project Member
Thu 25 Sep 2014 10:24:37 PM UTC, comment #16: 

I'm at home with no firewall and can see the paste bin stuff.  I'll try llvm-3.5 on Macports and report back.

Ben Abbott <bpabbott>
Project Member
Thu 25 Sep 2014 08:33:56 PM UTC, comment #15: 

Can you please guys split up this bug report? It started with a problem about building with LLVM 3.5, and now you guys are talking about linking with Fortran libraries, about, bug #43171, which should be discussed over there, and now you're talking about why pastebin isn't accessible behind some firewall.

Let's please try to keep the discussion relevant to the LLVM 3.5 build problem, and discuss separate issues in other bug reports or off the bug tracker.

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Thu 25 Sep 2014 06:43:57 PM UTC, comment #14: 

I'm not sure what I can do to help... If there's some other site you'd like me to paste it to, please test there first, but I'm happy to.

Thu 25 Sep 2014 06:42:14 PM UTC, comment #13: 

Still doesn't work ... maybe a firewall problem?

Ben Abbott <bpabbott>
Project Member
Thu 25 Sep 2014 06:41:21 PM UTC, comment #12: 

That's very odd...  but not today's problem.  Here's the same thing in a new pastebin:  http://pastebin.com/MMUDYD52

Thu 25 Sep 2014 06:39:09 PM UTC, comment #11: 

The link doesn't work for me

Ben Abbott <bpabbott>
Project Member
Thu 25 Sep 2014 06:37:40 PM UTC, comment #10: 

Ben - octave configured with llvm a week ago.  Anyway, here's a pastebin of how the compile ends, with llvm and all of the optional features and libraries on octave disabled:


Thu 25 Sep 2014 06:34:35 PM UTC, comment #9: 

As far as I know, LLVM doesn't work properly with Octave on MacOSX. Although I do include the LLVM stuff in configure

./configure                                               \
   CC=/opt/local/bin/gcc-mp-4.7                           \
   CFLAGS="-pipe -O2 -m64"                                \
   CPPFLAGS="-D_THREAD_SAFE -I/opt/local/include"         \
   LDFLAGS="-L/opt/local/lib -m64 "                       \
   CXX=/opt/local/bin/g++-mp-4.7                          \
   CXXFLAGS="-pipe -O2 -m64"                              \
   F77=/opt/local/bin/gfortran-mp-4.7                     \
   FFLAGS="-pipe -O2 -m64"                                \
   LLVM_CONFIG=/opt/local/bin/llvm-config-mp-3.3          \
   --enable-jit                                           \
   --with-magick=GraphicsMagick                           \
   --with-lapack="-llapack -latlas -lgfortran"            \
   --with-blas="-lcblas -lf77blas -latlas -lgfortran"     \
   --prefix=/usr/local/octave/3.8.2                       \
   --enable-gui                                           \
   --disable-java                                         \
   --with-framework-carbon                                \
   --with-arpack                                          \
   --enable-docs                                          \
   --with-opengl                                          \
   --without-x                                            \

Octave's configure doesn't use LLVM, and hence there is no JIT on MacOSX.

Ben Abbott <bpabbott>
Project Member
Thu 25 Sep 2014 06:06:36 PM UTC, comment #8: 

I haven't figured llvm out so haven't worked-around the bug, but, with all of the source changes discussed here, I got it to build with

 ./configure CC=gcc-4.9 CFLAGS="-g0 -O2 -m64 -march=native -mtune=native" CPPFLAGS="-I/usr/local/opt/readline/include -D_THREAD_SAFE -I/usr/local/include -I/usr/include" LDFLAGS="-L/usr/local/opt/readline/lib -L/usr/local/lib -m64" CXX="g++-4.9" LLVM_CONFIG=/usr/local/bin/llvm-config-3.5 --with-blas="-framework Accelerate -lgfortran" --enable-gui --disable-jit --disable-java --with-framework-carbon --with-arpack --with-opengl --without-x --without-magick

(Octave has never liked to build against magick on my system.)

However, when I try to get octave compiling with libc++ and gcc, (halfway to llvm), it blows up from missing includes (which are, in fact, in the path).

Thu 25 Sep 2014 03:41:08 PM UTC, comment #7: 


I'm also running Mavericks with Xcode 6.0.1, but am using gcc-4.7.

I'm able to build and run Octave and octave-gui with the following change to libgnu/stdio.h (no other changes needed).

1029 /* It is very rare that the developer ever has full control of stdin,
1030    so any use of gets warrants an unconditional warning; besides, C11
1031    removed it.
1032 #undef gets
1034 _GL_WARN_ON_USE (gets, "gets is a security hole - use fgets instead");
1035 #endif  */

I haven't done much testing ... is some particular action/event needed to cause a crash.

Ben Abbott <bpabbott>
Project Member
Thu 25 Sep 2014 11:00:20 AM UTC, comment #6: 


One more correction, I have compiled with gcc all dependencies
EXCEPT Qt4 and qscintilla-2.7.2.

So if you say you are using gcc to compile Octave and clang++ to build Qt4 and qscintilla, then we seem to have a quite similar setup.

Can you try applying the fixes I described below (#43171 and patching qscintilla headers) and compile again?


Carlo de Falco <cdf>
Project Member
Thu 25 Sep 2014 07:22:48 AM UTC, comment #5: 


and on the stable branch I also need the fix described in
bug #43171

this is not required when building 4.1+ as the patch has been applied there.

If you want to try out my build I packaged it as a .dmg and uploaded it for testing here:


I am almost sure I did forget some dependency so I'd appreciate
help in trying whether it works.

I would in particular be interested in knowing whether it can install Forge packages.

be aware that the install is quite big, a few GB, and an unistaller is not yet included.

Carlo de Falco <cdf>
Project Member
Thu 25 Sep 2014 07:16:15 AM UTC, comment #4: 

Oh, one more thing.
In order for GUI to work I have to patch all qscintilla headers removing the following lines from all of them:

#ifdef __APPLE__
extern "C++" {


#ifdef __APPLE__

Carlo de Falco <cdf>
Project Member
Thu 25 Sep 2014 07:12:49 AM UTC, comment #3: 


There is indeed a problem with building Octave on OSX
with apple distributed compilers and system tools.

In the past this has often been tracked down to the inability
of apple compilers to link reliably to fortran libraries, I
don't know whether this is the case now.

Here is my configure line, all dependencies were installed via MacPorts, forcing the compiler to be gcc-4.9

../octave/configure                                    \
    CC=gcc                                             \
    CFLAGS="-pipe -O2 -m64"                            \
    CPPFLAGS="-D_THREAD_SAFE -I/opt/local/include"     \
    LDFLAGS="-L/opt/local/lib -m64 "                   \
    CXX=g++                                            \
    CXXFLAGS="-pipe -O2 -m64"                          \
    F77=gfortran                                       \
    FFLAGS="-pipe -O2 -m64"                            \
    LLVM_CONFIG=/opt/local/bin/llvm-config-mp-3.4      \
    --with-lapack="-llapack -latlas -lgfortran"        \
    --with-blas="-lcblas -lf77blas -latlas -lgfortran" \
    --prefix=/opt/octave/                              \
    --enable-gui                                       \
    --disable-jit                                      \
    --disable-java                                     \
    --with-framework-carbon                            \
    --with-arpack                                      \
    --enable-docs                                      \
    --with-opengl                                      \
    --without-x                                        \


Carlo de Falco <cdf>
Project Member
Thu 25 Sep 2014 06:39:32 AM UTC, comment #2: 

That may be true (I was able to get most options working, even though they were compiled with llvm, but not the gui) but I don't think it changes the status of this as a bug in the build. 

If every dependency has to be built using gcc, then all of the Mac package managers are broken at their foundations.

Right now this appears to be the only package (or one of a tiny number of packages) in homebrew and macports that will break when Apple releases Yosemite.  That's octave's bug to fix.

That said, I wouldn't mind if you e-mailed me your configure line and environment variables. 

Thu 25 Sep 2014 06:23:35 AM UTC, comment #1: 


Just to correct one point in your description.

I just completed a build of Octave 3.8.2 with gcc-4.9
and most optional dependencies enabled on Mavericks with the latest update of XCode installed.

I only have java and jit disabled (more for historical reasons than anything else) I'll eventually try to activate those as well.

So it seams you can activate all dependencies AS LONG AS they are also compiled with gcc-4.9.


Carlo de Falco <cdf>
Project Member
Thu 25 Sep 2014 03:31:54 AM UTC, original submission:  

See discussion here:  https://github.com/Homebrew/homebrew-science/issues/1193

See also https://trac.macports.org/ticket/45011

This has become a widespread issue since Apple pushed an update to Xcode a few days ago.  It is not clear whether anyone has been able to build octave since the update, at least with any toolchain installed afterwards. 

Building with gcc-4.9 does work with all optional packages and features disabled.  But gcc-4.9 is not a standard compiler on Mac, is not generally installed, and is not the default compiler for any package manager. (Disabling the gui, as in the first thread above, may be necessary for the compile to complete but is not sufficient.  I'm trying to track down which features and options work and which kill the build, but that's going to take some time.

Anyway, not being able to enable the gui, or use the standard compiler on the OS and for the package managers, is a problem. 

The Yosemite update is expected to be free, and if it follows the pattern of prior OS X updates, almost mandatory.  When Apple releases it to the public in a few weeks, we can expect the issue to become close-to-universal among Mac OS X users. 



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #34968:  oct-llvm-config.diff added by mtmiller (2KiB - text/x-diff)
file #32278:  fntests.log.bz2 added by tchaikov (1MiB - application/x-bzip2 - i am posting the test result for your reference.)
file #32255:  clang-libcxx-fix.patch added by None (3KiB - application/octet-stream - a workarounds for this issue)


   bug dependencies.

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by rik5 (Updated the item)
  • -email is unavailable- added by sschoeps (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by tchaikov (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by febeling
  • -email is unavailable- added by dac922 (Posted a comment)
  • -email is unavailable- added by jordigh (Posted a comment)
  • -email is unavailable- added by bpabbott (Posted a comment)
  • -email is unavailable- added by cdf (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only project members can vote.





    Follow 24 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-08-08 rik5 Severity4 - Important 3 - Normal
        Open/ClosedOpen Closed
    2016-07-01 rik5 Severity3 - Normal 4 - Important
    2016-03-29 mtmiller Summaryllvm clang 3.5 cannot resolve the pow(octave_int<int>, octave_Int<int>) function overload llvm libc++ 3.5 fails to resolve the pow(octave_int, octave_Int) function overload
    2016-03-29 mtmiller Severity2 - Minor 3 - Normal
        SummaryLLVM 3.5.0 cannot resolve the pow(octave_int<int>, octave_Int<int>) function overload llvm clang 3.5 cannot resolve the pow(octave_int, octave_Int) function overload
    2016-03-01 rik5 Dependencies- Depends on bugs #41061
    2015-10-02 rik5 Carbon-CopyRemoved 72865 -
    2015-10-02 mtmiller Severity3 - Normal 2 - Minor
        Priority5 - Normal 3 - Low
        Operating SystemMac OS Any
    2015-09-23 mtmiller Attached File- Added oct-llvm-config.diff, #34968
    2015-07-27 bpabbott StatusInvalid Postponed
        Open/ClosedClosed Open
        Operating SystemAny Mac OS
    2015-04-12 mtmiller StatusConfirmed Invalid
        Open/ClosedOpen Closed
        Release3.8.2 dev
        Operating SystemMac OS Any
    2014-10-15 tchaikov Attached File- Added fntests.log.bz2, #32278
    2014-10-11 None Attached File- Added clang-libcxx-fix.patch, #32255
    2014-10-06 febeling Carbon-Copy- Added -email is unavailable-
    2014-09-26 jordigh StatusNone Confirmed
    2014-09-25 jordigh SummaryOctave 3.8.1 & 3.8.2 Will Not Build With OS X 10.10 Yosemite or Xcode 6.0.1 or later LLVM 3.5.0 cannot resolve the pow(octave_int, octave_Int) function overload

    Back to the top

    Powered by Savane 3.9