Re: Build error w. JIT

[Max Brister]

On Sat, Aug 25, 2012 at 9:42 AM, Philip Nienhuis
<address@hidden> wrote:
> libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../octave/libinterp -I..
> -I../../octave/libcruft/misc -I../liboctave -I../../octave/liboctave
> -I../../octave/libinterp/octave-value -I../../octave/libinterp/operators
> -Iparse-tree -I../../octave/libinterp/parse-tree -Iinterp-core
> -I../../octave/libinterp/interp-core -Iinterpfcn
> -I../../octave/libinterp/interpfcn -Icorefcn -I../libgnu
> -I../../octave/libgnu -g -O2 -pthread -mieee-fp -isystem /usr/include
> -I/usr/include/freetype2 -Wall -W -Wshadow -Wold-style-cast -Wformat
> -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -g -O2 -pthread -MT
> parse-tree/pt-eval.lo -MD -MP -MF parse-tree/.deps/pt-eval.Tpo -c
> ../../octave/libinterp/parse-tree/pt-eval.cc  -fPIC -DPIC -o
> parse-tree/.libs/pt-eval.o
> In file included from ../../octave/libinterp/interp-core/pt-jit.h:28,
>                  from ../../octave/libinterp/parse-tree/pt-eval.cc:49:
> ../../octave/libinterp/interp-core/jit-ir.h: In member function 'void
> jit_use::stash_value(jit_value*, jit_instruction*, size_t)':
> ../../octave/libinterp/interp-core/jit-ir.h:308: error: 'template<class
> HOLDER_T, class SUB_T> class jit_internal_node' used without template
> parameters
> ../../octave/libinterp/interp-core/jit-ir.h: In copy constructor
> 'jit_phi_incomming::jit_phi_incomming(const jit_phi_incomming&)':
> ../../octave/libinterp/interp-core/jit-ir.h:799: error: class
> 'jit_phi_incomming' does not have any field named 'jit_internal_node'
> make[3]: *** [parse-tree/pt-eval.lo] Error 1
> make[3]: Leaving directory `/home/philip/devel/oct-3.7/libinterp'
> make[2]: *** [all] Error 2
> make[2]: Leaving directory `/home/philip/devel/oct-3.7/libinterp'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/philip/devel/oct-3.7'
> make: *** [all] Error 2
>
> Mandriva 2010.2, LLVM 2.6
>
> The class name "......incomming" seems to be consistent.
>
> Philip

Currently, only LLVM 3.0 and 3.1 are supported. The problem is that
the configure check does not test for this [1]. I should have time to
fix this today.

[1] http://savannah.gnu.org/bugs/?37050

-- 
Max Brister