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.
|
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
|
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?
|
Fri 02 Oct 2015 05:14:14 PM UTC, comment #44:
Maybe the information at the link below can help?
http://www.alecjacobson.com/weblog/?p=2827
Alternatively, the Mac OS X Carbon framework supports off-screen rendering.
https://developer.apple.com/library/mac/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_offscreen/opengl_offscreen.html
I don't know how similar it is to OSMesa
|
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.
|
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.
|
Thu 01 Oct 2015 09:15:36 PM UTC, comment #41:
Sebastian,
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?
Ben
|
Thu 01 Oct 2015 08:48:06 PM UTC, comment #40:
I'm using the most recent Xcode on Yosemite (10.10.5).
And am also now able to build without the clang-libcc-fix.patch.
|
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
|
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)
|
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.
|
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?
|
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++.
|
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?
|
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.
|
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!
|
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?
|
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.
|
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?
|
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:
http://hydra.nixos.org/build/15885705/download/1/coverage/liboctave/util/oct-inttypes.cc.gcov.html
http://hydra.nixos.org/build/15885705/download/1/coverage/liboctave/util/oct-inttypes.h.gcov.html
(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.
|
Wed 15 Oct 2014 06:09:49 PM UTC, comment #27:
@john
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
@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.
|
Wed 15 Oct 2014 03:55:55 PM UTC, comment #26:
Has anyone tried removing the double and float conversions? What breaks?
|
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.
|
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.
|
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?
- 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:
- 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)
- liboctave: replace the nasty macro of
with
(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.
|
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:
http://llvm.org/bugs/show_bug.cgi?id=21083
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?
|
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.)
|
Fri 26 Sep 2014 11:56:32 AM UTC, comment #17:
I configured using LLVM 3.5,
Configure reported
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.
|
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.
|
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.
|
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?
|
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
|
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:
http://pastebin.com/YEyHzU2W
|
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
Octave's configure doesn't use LLVM, and hence there is no JIT on MacOSX.
|
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:
Carlo,
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).
I haven't done much testing ... is some particular action/event needed to cause a crash.
|
Thu 25 Sep 2014 11:00:20 AM UTC, comment #6:
Hi,
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?
c.
|
Thu 25 Sep 2014 07:22:48 AM UTC, comment #5:
Oh,
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:
http://sourceforge.net/projects/octave/files/Octave%20MacOSX%20Binary/test/2014-09-25-Binary-of-GNU-Octave-3.8.2-for-OSX-10.9.5/GNU_Octave_3.8.2-1.dmg/download
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.
|
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:
|
Thu 25 Sep 2014 07:12:49 AM UTC, comment #3:
Yes,
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
HTH
c.
|
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:
Hi,
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.
c.
|
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.
|