bugGNU Octave - Bugs: bug #41061, building with --enable-jit with...

 
 

bug #41061: building with --enable-jit with libllvm 3.5 fails to compile

Submitter:  Albert <aaahaaah>
Submitted:  Wed 01 Jan 2014 10:28:03 PM UTC
   
 
Category:  Configuration and Build System Severity:  1 - Wish
Priority:  1 - Later Item Group:  Build Failure
Status:  Wont Fix Assigned to:  None
Originator Name:  Albert Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 05 Feb 2019 06:36:04 PM UTC, comment #39: 

Minimum version for LLVM is probably 3.8 at this point.  The LLVM API is contantly changing.  Maybe it will eventually settle down, or Octave may switch to a different means of suppling a JIT compiler.

In any case, marking as Won't Fix and closing report.

Rik <rik5>
Group administrator
Fri 09 Oct 2015 08:42:44 PM UTC, comment #38: 

Now building Octave 4.0.0 with LLVM 3.5 with all options, including JIT. Implemented the latest patch (manually). It still fails with following errors:  

>>>===<<<

CXX      octave_gui-main-gui.o
CXXLD    octave-gui
../libinterp/.libs/liboctinterp.so: undefined reference to `llvm::ExecutionEngine::createJIT(llvm::Module*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, llvm::JITMemoryManager*, llvm::CodeGenOpt::Level, bool, llvm::Reloc::Model, llvm::CodeModel::Model)'
../libinterp/.libs/liboctinterp.so: undefined reference to `llvm::raw_fd_ostream::raw_fd_ostream(char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, llvm::sys::fs::OpenFlags)'
collect2: error: ld returned 1 exit status

>>>===<<<

Tried different versions of gcc, same errors. Now I am using gcc5.2 and llvm/clang 3.5. LLVM libraries in LD_LIBRARY_PATH have missed modules, it seems something else causing problem to the linker....

Any help will be appreciated. I think having JIT is important for future of Octave, especially after great new release of 4.0.0

Oleg <oleg_mikul>
Sun 03 May 2015 08:57:49 PM UTC, comment #37: 

There you go: file #33887

Used the AX_CHECK_COMPILE_FLAG macro. The file #33888 ax_compare_version.m4 needs to be included in the m4/ directory.

http://www.gnu.org/software/autoconf-archive/ax_check_compile_flag.html

Seems to work but couldn't test with older version of gcc.

Josué Mercado <mpad>
Sun 03 May 2015 07:32:04 PM UTC, comment #36: 

You're still checking for versions instead of features. It doesn't matter what the compiler is or its version. All that matters is if it accepts -std=c++11 or -stc=c++0x. Indeed, gcc versions earlier to 4.7 have quite a bit of C++11 implemented, back when it was still known as C++0x.

But I really think this is a waste of time, at least as it pertains to LLVM. Why are you so interested in compiling JIT support into Octave?

Jordi Gutiérrez Hermoso <jordigh>
Group Member
Sat 02 May 2015 12:34:55 PM UTC, comment #35: 

Added file #33878: Now checks the LVMM features (DataLayoutPass) instead of the version macros. No change to c++11.
Regarding the gnulib-hg patch it just checks if _GCC_MAX_ALIGN_T is already defined which is the case on my system.

Josué Mercado <mpad>
Fri 01 May 2015 09:24:01 PM UTC, comment #34: 

Jordi:  As you point out, this is not a happy
situation. Someday, RHEL may move up, but I would
not hold my breath. They are VERY "conservative."
And, to make matters worse, many major sites are one
or two levels behind the current release of RHEL.
For a large production site, moving up is a very major
effort. It would be helpful to continue to provide
Octave that they can use.

However, note that the default for LLVM is to NOT
attempt to include it.  Only ./configure --enable-jit
attempts to turn it on. So, I see no need to remove
the, normally unused, code.

So, obviously, the recent patch should not be applied
in its present form or probably not at all.

This should be preserved in case someone shows up to
put serious work into the implementation.

On the brighter side, I was surprised that the current
system does compile "correctly" using C++11. The various
warnings do not apparently prevent it from generating
correct code.

Michael Godfrey <godfrey>
Group Member
Fri 01 May 2015 09:08:38 PM UTC, comment #33: 

Agree with Jordi, these patches are not appropriate.

I already opened a separate bug about optionally enabling C++11 features in the compiler if the compiler supports it, see bug #44965. That is the appropriate place to talk about how to add the right compiler flags, and it's basically a solved problem, but will not be done until after 4.0.0 is out.

The first patch should also not look at LLVM_VERSION macros, it should add a configure.ac test for llvm::DataLayoutPass vs llvm::DataLayout, if that's what is failing.

And agree about the gnulib patch, can you show an error message or demonstrate a small example showing what the problem is and why a change is needed?

Mike Miller <mtmiller>
Group Member
Fri 01 May 2015 09:02:35 PM UTC, comment #32: 

We don't generally check versions. We check for features.

But we also don't use C++11, not as long as RHEL doesn't have a C++11 compiler. If LLVM 3.5 will not compile without C++11, the right thing to do would be to check if we can compile an LLVM program, and if not, check that the compiler, whatever compiler it may be, can accept a -std=c++11 flag and then try to compile an LLVM program again with -std=c+11.

This is all awfully complicated and for almost no benefit. It's far easier to just drop the LLVM dependency completely, since we don't really have any interesting JIT compiling at all.

I would be happy to see either (1) someone come along and actually implement JIT compiling or (2) someone come along and remove all traces of LLVM from our codebase.

Finally, the gnulib patch should be pushed upstream to gnulib. I don't understand what it does, though, can you explain more?

Jordi Gutiérrez Hermoso <jordigh>
Group Member
Fri 01 May 2015 08:22:53 PM UTC, comment #31: 

Added two patches:
file #33858
Added GCC check. If version is >= 4.7 then uses c++11 flag (LLVM).
Added LLVM version check (preprocesor macro check)

file #33859
Minor fix (gnulib-hg sub-repo) to avoid conflicting declarations.

Tested on OpenSuse 12.3 (GCC 4.7/LLVM 3.2) and OpenSuse 13.2 (GCC 4.8/LLVM 3.5).

Josué Mercado <mpad>
Thu 30 Apr 2015 05:05:46 PM UTC, comment #30: 

Well, I am one of those who has complained a lot about
the API and other incompatibilities with llvm. But, there
is a very definite need to improve Octave performance.

So, giving up on llvm should only be done if something better
can be found. Right now llvm seems to be the "mainstream"
system -- it is a part of clang for instance.

Also, some of the benefits of JIT have not been realized.
The current implementation is incomplete.

It would be good if someone could be found to do more
work on it.

Michael Godfrey <godfrey>
Group Member
Thu 30 Apr 2015 02:44:27 PM UTC, comment #29: 

We probably should drop the JIT compiler white elephant at this point. It has turn out to be a huge annoyance for almost no benefit.

Jordi Gutiérrez Hermoso <jordigh>
Group Member
Thu 30 Apr 2015 02:27:32 AM UTC, comment #28: 

Oh so LLVM 3.5 and newer requires C++11 now?

I've been thinking it might be time to conditionally add the compiler flags needed to enable C++11 if the compiler supports it.

Just opened bug #44965, adding as a dependency.

Mike Miller <mtmiller>
Group Member
Thu 30 Apr 2015 01:44:43 AM UTC, comment #27: 

On Fedora 21 this patch works after one minor
patch and a number of new warnings.

It obviously needs more work, but should be
kept around as a valid base for llvm 3.5 support.

Make check result was:

  PASS     13002
  FAIL         0
  XFAIL       14
  SKIPPED      1


Michael Godfrey <godfrey>
Group Member
Wed 29 Apr 2015 06:06:12 PM UTC, comment #26: 

The use of '-std=c++11' isn't supported by some, just modestly old, gcc versions like 4.6.  Rather than just adding it to the LLVM flags in configure.ac, I think one would need more extensive tests in configure to determine if LLVM3.5 is being used AND if the compiler supports it.

LLVM has been incredibly bad about changing their API all the time resulting in lots of failures to compile perfectly good old code.  They really seem to scoff at the concept of code re-use.

Anyways, after applying the patch the JIT code fails to compile with LLVM3.2.  This can be fixed, but it would need more work with configure.ac and using #ifdefs in the code to support the multiple versions of LLVM.

Rik <rik5>
Group administrator
Wed 29 Apr 2015 01:43:37 PM UTC, comment #25: 

Added file #33837

make check:
  jit.tst ..................................................... PASS     42/44 
                                                                  XFAIL   2

Anonymous
Mon 02 Feb 2015 04:23:03 AM UTC, comment #24: 

Re-titling to reflect the remaining problem is with LLVM 3.5.  I've lowered the Priority and Severity since LLVM is only required for JIT which isn't going to be a gating item for the 4.0 release.

Rik <rik5>
Group administrator
Thu 01 Jan 2015 09:08:05 PM UTC, comment #23: 

A bit more information: After setting,
CPPFLAGS=-std=c++11
./configure --enable-jit
make
gets to:

                 from corefcn/jit-typeinfo.cc:46:
/usr/include/llvm/ADT/Twine.h: In constructor 'jit_typeinfo::jit_typeinfo(llvm::Module*, llvm::ExecutionEngine*)':
/usr/include/llvm/ADT/Twine.h:187:12: error: 'llvm::Twine& llvm::Twine::operator=(const llvm::Twine&)' is private
     Twine &operator=(const Twine &Other) LLVM_DELETED_FUNCTION;
            ^
corefcn/jit-typeinfo.cc:1211:15: error: within this context
       fn_name = fn_name + llvm::Twine (op);
               ^
corefcn/jit-typeinfo.cc:1211:15: error: use of deleted function 'llvm::Twine& llvm::Twine::operator=(const llvm::Twine&)'
In file included from /usr/include/llvm/IR/GlobalVariable.h:23:0,
                 from corefcn/jit-typeinfo.cc:46:
/usr/include/llvm/ADT/Twine.h:187:12: note: declared here
     Twine &operator=(const Twine &Other) LLVM_DELETED_FUNCTION;
  ===============================
So, a code change is needed.

Michael Godfrey <godfrey>
Group Member
Sat 20 Dec 2014 10:54:18 PM UTC, comment #22: 

It was hoped that the patch below would work for the
llvm 3.5 release, but it does not, from onfig.log:

3693: configure:15342: g++ -c  -g -O2 -pthread -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -isystem /usr/include  conftest.cpp >&5
3694: In file included from /usr/include/c++/4.9.2/type_traits:35:0,
3695:                  from /usr/include/llvm/Support/MathExtras.h:21,
3696:                  from /usr/include/llvm/ADT/SmallVector.h:20,
3697:                  from /usr/include/llvm/ADT/ArrayRef.h:14,
3698:                  from /usr/include/llvm/IR/Attributes.h:19,
3699:                  from /usr/include/llvm/IR/Argument.h:19,
3700:                  from /usr/include/llvm/IR/Function.h:22,
3701:                  from conftest.cpp:83:
3702: /usr/include/c++/4.9.2/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
3703:  #error This file requires compiler and library support for the \
3704:   ^

Michael Godfrey <godfrey>
Group Member
Sun 15 Jun 2014 04:52:44 AM UTC, comment #21: 

I applied Stefan's patch to development branch.  Closing report.

Rik <rik5>
Group administrator
Sun 11 May 2014 08:04:20 PM UTC, comment #20: 

This patch works correctly on current Fedora 20
using llvm 3.4.6

Michael Godfrey <godfrey>
Group Member
Sun 11 May 2014 10:20:11 AM UTC, comment #19: 

If this patch is likely to work for the 3.5 release
it might be helpful to push it to the dev system.

I will verity that it works for the current Fedora 20 (3.4).

Michael Godfrey <godfrey>
Group Member
Sun 11 May 2014 09:12:40 AM UTC, comment #18: 

I forgot to mention: Tested on Ubuntu 14.04 with LLVM 3.4 (default LLVM) and LLVM 3.3 and 3.5 as alternative build (LLVM_CONFIG=llvm-config-3.3/3.5)

Stefan Mahr <dac922>
Sun 11 May 2014 09:10:49 AM UTC, comment #17: 

I added autoconf checks to queueram's patch and an additional headerfile check for LLVM 3.5 pre version as distributed with Ubuntu 14.04.

Patch is attached and can be found here too: http://inversethought.com/hg/octave-nkf/rev/81472221adc3

(file #31351)

Stefan Mahr <dac922>
Mon 21 Apr 2014 10:35:33 PM UTC, comment #16: 

Now that Fedora 20 has been updated to llvm
3.4.6 the patch (#30296) below is needed to
compile the current dev system with
--enable-jit.  The system builds and
passes make check. The patch finds the
"legacy" files needed to make 3.4 act like
3.3. So, it is definitely not a long-term
solution.

However, note that this patch will cause
systems using llvm < 3.4 to fail to build.

Probably should check on when 3.5 is coming
so as not to waste too much time trying to
track the effervescent llvm.

Michael Godfrey <godfrey>
Group Member
Tue 01 Apr 2014 08:41:06 PM UTC, comment #15: 

Exactly, JIT is experimental, and LLVM 3.5 will probably bring a new set of incompatible changes, and I'm not very motivated to work on this :)

Mike Miller <mtmiller>
Group Member
Tue 01 Apr 2014 05:18:04 PM UTC, comment #14: 

If you think you can make the changeset work then go ahead and commit it.  Otherwise, JIT is experimental and I wouldn't spend too much time on it until we have someone who wants to work on that section of code.

Rik <rik5>
Group administrator
Tue 01 Apr 2014 02:33:21 PM UTC, comment #13: 

Just noting that I have done a test build using this proof-of-concept patch and LLVM 3.4 and it works for me (Debian unstable). In Debian we will either have to adapt Octave to build for LLVM 3.4 or turn off JIT completely, since there is a library conflict with the Mesa graphics stack now being linked with LLVM 3.4.

Mike Miller <mtmiller>
Group Member
Fri 17 Jan 2014 02:37:18 PM UTC, comment #12: 


> Note that this patch will break building with LLVM < 3.4, but
> perhaps someone with more understanding of the octave build system
> can clean it up so that it still builds successfully with older LLVM
> versions.


Yeah, it's not that difficult to figure out how to adapt to the latest version of their ever-changing API. It's more difficult to adapt to all of them at once. Can you please look at the following commits for examples of what needs to be done in order to support all LLVM versions at once?


hg log --verbose --rev '(file(configure.ac) or file(m4/acinclude.m4)) and keyword(LLVM)'


Jordi Gutiérrez Hermoso <jordigh>
Group Member
Fri 17 Jan 2014 12:50:02 AM UTC, comment #11: 

The LLVM folks appear to have made significant changes to the PassManager class to warrant moving the 3.3 one into a 'legacy' namespace in 3.4.  I didn't see anything in the release notes or documentation, but these changes are evident in the header files.  I'm attaching a patch file that allows octave 3.8.0 to be built against LLVM 3.4 under Arch Linux.  Note that this patch will break building with LLVM < 3.4, but perhaps someone with more understanding of the octave build system can clean it up so that it still builds successfully with older LLVM versions.

(file #30296)

M.S. <queueram>
Thu 16 Jan 2014 09:53:49 PM UTC, comment #10: 

Compiling against LLVM 3.0 works. (Recently tested with armel/debian wheezy.)

Stefan Mahr <dac922>
Thu 16 Jan 2014 07:37:32 PM UTC, comment #9: 

We definitely support LLVM 3.2 and 3.3. I personally don't know about LLVM 3.0 or 3.1. We definitely fail to compile against LLVM 2.9, 3.4, and 3.5.

Mike Miller <mtmiller>
Group Member
Thu 16 Jan 2014 06:00:14 PM UTC, comment #8: 

What is the current situation with Octave?  I know we don't build with LLVM < 3.0.  Do we build with LLVM 3.0?  I see from cset 36fd98b9ce48 that Max added support for LLVM 3.3 so I think we might work only with 3.1, 3.2, and 3.3.

Rik <rik5>
Group administrator
Thu 16 Jan 2014 02:53:14 AM UTC, comment #7: 

Either way, confirmed that I get the same set of errors with LLVM 3.4 (as packaged for Debian). Retitling to reflect this.

Mike Miller <mtmiller>
Group Member
Wed 15 Jan 2014 05:59:31 PM UTC, comment #6: 

Right, it is very foolish that the LLVM folks
live in their own world where changing the API
and file locations, etc., even within a "release"
does not matter.

But, the libgccjit seems right now to be just beyond
an idea. When it may become defined and stable is not
clear.

Our present JIT, but only for x86 and subject to
the continuing configuration and API issues, does
actually work, at least for me.

So, maybe patience is required for a while.

And, someone might ask the LLVM folks if they ever
plan to support users like us. And, if so, how.

Michael Godfrey <godfrey>
Group Member
Wed 15 Jan 2014 03:14:00 PM UTC, comment #5: 

I think we might want work towards using something other than LLVM. It's ridiculous that every damn LLVM release is breaking their API. Our autoconf checks are getting stupid. They obviously do not want anyone but themselves to be using LLVM as a JIT library.

We wouldn't lose much at this point. It's not like our JIT is compiling any interesting loops. There's libgccjit, which is kind of experimental right now, but might be a perfect fit for us.

Jordi Gutiérrez Hermoso <jordigh>
Group Member
Wed 15 Jan 2014 02:34:11 PM UTC, comment #4: 

Hmm, could be. I went back to an earlier bug that was about porting to 3.3 and 3.4, but apparently I had been testing a 3.4 svn prerelease at the time. I'll have to do another test build with 3.4 now to confirm.

Mike Miller <mtmiller>
Group Member
Wed 15 Jan 2014 09:41:08 AM UTC, comment #3: 

I compiled today with the llvm binary shipped with my distribution (ArchLinux); that is 3.4 according to llvm-config --version and was released on 02 Jan 2014 [1].

I get the same errors with this - stable - version.

[1] http://llvm.org/releases/

Lasse Schuirmann <sils1297>
Thu 02 Jan 2014 05:07:45 PM UTC, comment #2: 

I lowered the priority to "later".  LLVM seems to drastically change their API for every release and it is a pain in the ass to keep up with.  When they have a stable release we can think about modifying Octave to build with it.

Rik <rik5>
Group administrator
Thu 02 Jan 2014 03:21:22 AM UTC, comment #1: 

Confirmed on the development version as well, attempting to build on Debian testing with LLVM 3.5. Yet another API change. LLVM 3.5 is not yet released, there is probably not much point attempting to chase their in-development API changes until it is a stable release.

Mike Miller <mtmiller>
Group Member
Wed 01 Jan 2014 10:28:03 PM UTC, original submission:  

This is the first time I cannot build Octave on RedHat/Fedora system. The problem resides in LLVM/JIT related files.
RedHat 6.4, 64 bit
The very fresh LLVM/CLang distribution (3.5) compiled from the source (the version compiled few months ago had the same failure).
./configure --prefix=/home/albert/soft/octave
make
...
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I.. -I../liboctave/cruft/misc -I../liboctave/array -I../liboctave/numeric -I../liboctave/numeric -I../liboctave/operators -I../liboctave/operators -I../liboctave/system -I../liboctave/util -I./octave-value -I./operators -Iparse-tree -I./parse-tree -Icorefcn -I./corefcn -I../libgnu -I../libgnu -I/usr/include/freetype2 -isystem /usr/local/include -Wall -W -Wshadow -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -g -O2 -pthread -MT corefcn/corefcn_libcorefcn_la-pt-jit.lo -MD -MP -MF corefcn/.deps/corefcn_libcorefcn_la-pt-jit.Tpo -c corefcn/pt-jit.cc  -fPIC -DPIC -o corefcn/.libs/corefcn_libcorefcn_la-pt-jit.o
In file included from corefcn/pt-jit.cc:55:
/usr/local/include/llvm/PassManager.h:34: error: 'PassManager' is already declared in this scope
/usr/local/include/llvm/PassManager.h:35: error: 'FunctionPassManager' is already declared in this scope
corefcn/pt-jit.cc: In member function 'bool tree_jit::initialize()':
corefcn/pt-jit.cc:1891: error: cannot convert 'llvm::legacy::PassManager*' to 'llvm::PassManager*' in assignment
corefcn/pt-jit.cc:1892: error: invalid use of incomplete type 'struct llvm::PassManager'
corefcn/jit-util.h:46: error: forward declaration of 'struct llvm::PassManager'
corefcn/pt-jit.cc:1894: error: cannot convert 'llvm::legacy::FunctionPassManager*' to 'llvm::FunctionPassManager*' in assignment
corefcn/pt-jit.cc:1896: error: invalid use of incomplete type 'struct llvm::FunctionPassManager'
corefcn/jit-util.h:45: error: forward declaration of 'struct llvm::FunctionPassManager'
corefcn/pt-jit.cc:1900: error: invalid use of incomplete type 'struct llvm::FunctionPassManager'
corefcn/jit-util.h:45: error: forward declaration of 'struct llvm::FunctionPassManager'
corefcn/pt-jit.cc:1901: error: invalid use of incomplete type 'struct llvm::FunctionPassManager'
corefcn/jit-util.h:45: error: forward declaration of 'struct llvm::FunctionPassManager'
corefcn/pt-jit.cc:1902: error: invalid use of incomplete type 'struct llvm::FunctionPassManager'
corefcn/jit-util.h:45: error: forward declaration of 'struct llvm::FunctionPassManager'
corefcn/pt-jit.cc:1903: error: invalid use of incomplete type 'struct llvm::FunctionPassManager'
corefcn/jit-util.h:45: error: forward declaration of 'struct llvm::FunctionPassManager'
corefcn/pt-jit.cc:1904: error: invalid use of incomplete type 'struct llvm::FunctionPassManager'
corefcn/jit-util.h:45: error: forward declaration of 'struct llvm::FunctionPassManager'
corefcn/pt-jit.cc:1905: error: invalid use of incomplete type 'struct llvm::FunctionPassManager'
corefcn/jit-util.h:45: error: forward declaration of 'struct llvm::FunctionPassManager'
corefcn/pt-jit.cc:1906: error: invalid use of incomplete type 'struct llvm::FunctionPassManager'
corefcn/jit-util.h:45: error: forward declaration of 'struct llvm::FunctionPassManager'
corefcn/pt-jit.cc:1907: error: invalid use of incomplete type 'struct llvm::FunctionPassManager'
corefcn/jit-util.h:45: error: forward declaration of 'struct llvm::FunctionPassManager'
corefcn/pt-jit.cc: In member function 'void tree_jit::optimize(llvm::Function*)':
corefcn/pt-jit.cc:2003: error: invalid use of incomplete type 'struct llvm::PassManager'
corefcn/jit-util.h:46: error: forward declaration of 'struct llvm::PassManager'
corefcn/pt-jit.cc:2004: error: invalid use of incomplete type 'struct llvm::FunctionPassManager'
corefcn/jit-util.h:45: error: forward declaration of 'struct llvm::FunctionPassManager'
corefcn/pt-jit.cc:2010: error: 'F_Binary' is not a member of 'llvm::raw_fd_ostream'
make[3]: * [corefcn/corefcn_libcorefcn_la-pt-jit.lo] Error 1
make[3]: Leaving directory `/home/albert/Downloads/octave-3.8.0/libinterp'
make[2]: * [all] Error 2
make[2]: Leaving directory `/home/albert/Downloads/octave-3.8.0/libinterp'
make[1]: * [all-recursive] Error 1
make[1]: Leaving directory `/home/albert/Downloads/octave-3.8.0'
make: * [all] Error 2

Albert <aaahaaah>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #33887:  llvm-3.5.0_4.patch added by mpad (4KiB - text/x-patch - patch for octave 4.0.0-rc3 to build against LLVM 3.5 (checks if gcc accepts -std=c++11 ))
file #33888:  ax_compare_version.m4 added by mpad (6KiB - application/x-m4 - patch for octave 4.0.0-rc3 to build against LLVM 3.5 (checks if gcc accepts -std=c++11 ))
file #33878:  llvm-3.5.0_3.patch added by mpad (4KiB - text/x-patch - patch for octave 4.0.0-rc3 to build against LLVM 3.5)
file #33858:  llvm-3.5.0_2.patch added by mpad (3KiB - text/x-patch - patch for octave 4.0.0-rc3 to build against LLVM 3.5))
file #33859:  llvm-3.5.0_gnulib-hg.patch added by mpad (431B - text/x-patch - patch for octave 4.0.0-rc3 to build against LLVM 3.5))
file #33837:  llvm-3.5.0.patch added by None (3KiB - text/x-patch - patch for octave 4.0.0-rc3 to build against LLVM 3.5)
file #31351:  llvm-3.4-3.5pre.patch added by dac922 (7KiB - text/x-patch)
file #30296:  llvm-3.4.patch added by queueram (2KiB - application/octet-stream - patch for octave 3.8.0 to build against LLVM 3.4)
file #30144:  config.output.txt added by aaahaaah (68KiB - text/plain - Output of configuration script)

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by oleg_mikul (Posted a comment)
  • -email is unavailable- added by mpad (Updated the item)
  • -email is unavailable- added by queueram (Updated the item)
  • -email is unavailable- added by dac922 (Posted a comment)
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by jordigh (Posted a comment)
  • -email is unavailable- added by jordigh
  • -email is unavailable- added by sils1297 (Posted a comment)
  • -email is unavailable- added by aaahaaah (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 group members can vote.

     

    Follow 25 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-02-05 mtmiller Carbon-CopyRemoved 80942 -
    2019-02-05 rik5 StatusPostponed Wont Fix
        Open/ClosedOpen Closed
    2016-03-29 mtmiller Operating SystemGNU/Linux Any
        SummaryOctave fails to build with LLVM 3.5 building with --enable-jit with libllvm 3.5 fails to compile
    2016-03-01 rik5 Dependencies- bugs #43298 is dependent
    2015-10-09 rik5 Carbon-CopyRemoved 72865 -
    2015-05-03 mpad Attached File- Added llvm-3.5.0_4.patch, #33887
        Attached File- Added ax_compare_version.m4, #33888
    2015-05-02 mpad Attached File- Added llvm-3.5.0_3.patch, #33878
    2015-05-01 mtmiller StatusNone Postponed
    2015-05-01 mpad Attached File- Added llvm-3.5.0_2.patch, #33858
        Attached File- Added llvm-3.5.0_gnulib-hg.patch, #33859
    2015-04-30 mtmiller Dependencies- Depends on bugs #44965
    2015-04-29 None Attached File- Added llvm-3.5.0.patch, #33837
    2015-04-27 mtmiller Dependencies- bugs #44937 is dependent
    2015-02-02 rik5 Severity3 - Normal 1 - Wish
        SummaryOctave fails to build with LLVM 3.4 and 3.5-pre-release Octave fails to build with LLVM 3.5
    2015-01-02 rik5 StatusFixed None
        Open/ClosedClosed Open
    2014-06-15 rik5 StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2014-05-11 dac922 Attached File- Added llvm-3.4-3.5pre.patch, #31351
    2014-01-17 queueram Attached File- Added llvm-3.4.patch, #30296
    2014-01-16 mtmiller SummaryOctave fails to build with LLVM 3.5 (pre-release) Octave fails to build with LLVM 3.4 and 3.5-pre-release

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code