[vmkit] Errors compiling vmkt

Hi all,

I hope this is the correct place to post such questions? I am building
vmkit for the first time, following the instructions on the get_started
page (with one deviation: in step 4 I ran ./configure in my vmkit
directory and therefore did not need to cd at the start of step 5. Is
this correct?). Build platform is 64-bit CrunchBang Linux 11 "Waldorf",
based on Debian Wheezy.

I get some compilation warnings, which could be harmless, followed by an
error:

chris@forbesy:~/vmkit$ make ENABLE_OPTIMIZED=1llvm[0]: Constructing
LLVMBuild project information.
make[1]: Entering directory `/home/chris/vmkit/lib/vmkit/StaticGCPass'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/chris/vmkit/lib/vmkit/StaticGCPass'
make[1]: Entering directory `/home/chris/vmkit/lib/vmkit/StaticGCPrinter'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/chris/vmkit/lib/vmkit/StaticGCPrinter'
make[1]: Entering directory `/home/chris/vmkit/lib'
make[2]: Entering directory `/home/chris/vmkit/lib/vmkit'
make[3]: Entering directory `/home/chris/vmkit/lib/vmkit/CommonThread'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/home/chris/vmkit/lib/vmkit/CommonThread'
make[3]: Entering directory `/home/chris/vmkit/lib/vmkit/MMTk'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/home/chris/vmkit/lib/vmkit/MMTk'
make[3]: Entering directory `/home/chris/vmkit/lib/vmkit/Runtime'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/home/chris/vmkit/lib/vmkit/Runtime'
make[3]: Entering directory `/home/chris/vmkit/lib/vmkit/Compiler'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/home/chris/vmkit/lib/vmkit/Compiler'
make[3]: Entering directory `/home/chris/vmkit/lib/vmkit/JITGCPass'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/home/chris/vmkit/lib/vmkit/JITGCPass'
make[2]: Leaving directory `/home/chris/vmkit/lib/vmkit'
make[2]: Entering directory `/home/chris/vmkit/lib/j3'
make[3]: Entering directory `/home/chris/vmkit/lib/j3/LLVMRuntime'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/home/chris/vmkit/lib/j3/LLVMRuntime'
make[3]: Entering directory `/home/chris/vmkit/lib/j3/VMCore'
llvm[3]: Compiling JnjvmClassLoader.cpp for Release+Asserts build (bytecode)
warning: unknown warning option '-Wno-maybe-uninitialized'; did you mean
      '-Wno-uninitialized'? [-Wunknown-warning-option]
In file included from JnjvmClassLoader.cpp:30:
/home/chris/vmkit/lib/j3/VMCore/../ClassLib/GNUClasspath/ClasspathReflect.h:153:8:
warning:
      private field 'running' is not used [-Wunused-private-field]
  bool running;
       ^
/home/chris/vmkit/lib/j3/VMCore/../ClassLib/GNUClasspath/ClasspathReflect.h:206:15:
warning:
      private field 'nextOnQueue' is not used [-Wunused-private-field]
  JavaObject* nextOnQueue;
              ^
3 warnings generated.
llvm[3]: Compiling JnjvmClassLoader.ll to JnjvmClassLoader.bc for
Release+Asserts build (bytecode)
llvm[3]: Compiling JnjvmClassLoader.bc to JnjvmClassLoader.s for
Release+Asserts build
llvm[3]: Compiling JnjvmClassLoader.s for Release+Asserts build
llvm[3]: Building Release+Asserts Archive Library libJ3.a
make[3]: Leaving directory `/home/chris/vmkit/lib/j3/VMCore'
make[3]: Entering directory `/home/chris/vmkit/lib/j3/ClassLib'
make[4]: Entering directory `/home/chris/vmkit/lib/j3/ClassLib/GNUClasspath'
llvm[4]: Compiling JavaUpcalls.cpp for Release+Asserts build (bytecode)
warning: unknown warning option '-Wno-maybe-uninitialized'; did you mean
      '-Wno-uninitialized'? [-Wunknown-warning-option]
In file included from JavaUpcalls.cpp:10:
/home/chris/vmkit/lib/j3/ClassLib/GNUClasspath/ClasspathReflect.h:153:8:
warning:
      private field 'running' is not used [-Wunused-private-field]
  bool running;
       ^
/home/chris/vmkit/lib/j3/ClassLib/GNUClasspath/ClasspathReflect.h:206:15:
warning:
      private field 'nextOnQueue' is not used [-Wunused-private-field]
  JavaObject* nextOnQueue;
              ^
3 warnings generated.
llvm[4]: Compiling JavaUpcalls.ll to JavaUpcalls.bc for Release+Asserts
build (bytecode)
llvm[4]: Compiling JavaUpcalls.bc to JavaUpcalls.s for Release+Asserts build
llvm[4]: Compiling JavaUpcalls.s for Release+Asserts build
llvm[4]: Building Release+Asserts Archive Library libClasspath.a
make[4]: Leaving directory `/home/chris/vmkit/lib/j3/ClassLib/GNUClasspath'
make[3]: Leaving directory `/home/chris/vmkit/lib/j3/ClassLib'
make[3]: Entering directory `/home/chris/vmkit/lib/j3/Compiler'
llvm[3]: Compiling JavaJIT.cpp for Release+Asserts build (bytecode)
warning: unknown warning option '-Wno-maybe-uninitialized'; did you mean
      '-Wno-uninitialized'? [-Wunknown-warning-option]
JavaJIT.cpp:1262:23: error: no member named 'removeFnAttr' in
'llvm::Function'
        llvmFunction->removeFnAttr(
        ~~~~~~~~~~~~ ^
1 warning and 1 error generated.
make[3]: ***
[/home/chris/vmkit/lib/j3/Compiler/Release+Asserts/JavaJIT.ll] Error 1
make[3]: Leaving directory `/home/chris/vmkit/lib/j3/Compiler'
make[2]: *** [all] Error 1
make[2]: Leaving directory `/home/chris/vmkit/lib/j3'
make[1]: *** [j3/.makeall] Error 2
make[1]: Leaving directory `/home/chris/vmkit/lib'
make: *** [all] Error 1

Did I do something wrong?

Regards

Chris

Hi Chris,

For the moment you can install VMKit following these instructions:

     http://vmkit2.gforge.inria.fr/start.php

VMKit's web page and repository will be updated soon.

Harris Bakiras

Hi Harris,

A question has arisen, what is the difference between VMKit2 and VMKit,
and why, in the first place the new VMKit2 fork was been created?

Thanks for answer :slight_smile:

Best regards,
Minas

Hi Minas,

Basically, you should not have any difference between the two projects
:slight_smile: (it's not really the case, but we are working on this problem). To
explain (sorry for my long email!), I work for a french research
institution (Inria) and, as we have an Inria research project around
VMKit, I had to create a repository inside my institution (a
researcher has always to make his institution happy:)).

At the beginning (6 month ago), it was more easy to have two different
repositories, one with a stable version hosted by llvm, the other one
with unstable contributions for the research project hosted by inria.
Now, the problem is that we have a lot of developments on the inria
repository because several PhD students and engineers are
contributing, and these contributions are not only strange research
ideas. As a result, VMKit2 (the inria version) is currently more
advanced than the llvm one. For example, we use the last version of
gnu classpath inside the inria repository while the llvm resository
still relies on an older version.

Fundamentally, I think that for the VMKit project, it's important to
be hosted as a subproject of llvm because VMKit heavily relies on llvm
(and because llvm is maybe a little bit more attractive than inria:)).
So, we will quickly re-merge the two projects and continuously
integrates the stable (and interesting) contributions of the inria
research project inside the llvm repository. We will also merge the
web pages and forget this stupid idea of VMKit2 (I will still keep a
separated repository hosted by inria for unstable or too specific
developments).

To conclude, we were a little bit overloaded these last weeks and we
have delayed the merge, but we will work on this soon (probably before
the end of march). For the moment, you should use the VMKit2
repository as it's probably the most advanced one.

See you,
Gaël

Fundamentally, I think that for the VMKit project, it's important to
be hosted as a subproject of llvm because VMKit heavily relies on llvm
(and because llvm is maybe a little bit more attractive than inria:)).
So, we will quickly re-merge the two projects and continuously
integrates the stable (and interesting) contributions of the inria
research project inside the llvm repository. We will also merge the
web pages and forget this stupid idea of VMKit2 (I will still keep a
separated repository hosted by inria for unstable or too specific
developments).

To conclude, we were a little bit overloaded these last weeks and we
have delayed the merge, but we will work on this soon (probably before
the end of march). For the moment, you should use the VMKit2
repository as it's probably the most advanced one.

Hi Gael,

   does it mean vmkit will based on the latest llvm after the merge finished?

   I run into the same issue Chris meet when trying to verify tilegx backend by compiling vmkit.

  JavaJIT.cpp:1262:23: error: no member named 'removeFnAttr' in
  'llvm::Function'
         llvmFunction->removeFnAttr(

   then I change to vmkit2, but found it's based on 3.2 only, failed compile with latest llvm

Fundamentally, I think that for the VMKit project, it's important to
be hosted as a subproject of llvm because VMKit heavily relies on llvm
(and because llvm is maybe a little bit more attractive than inria:)).
So, we will quickly re-merge the two projects and continuously
integrates the stable (and interesting) contributions of the inria
research project inside the llvm repository. We will also merge the
web pages and forget this stupid idea of VMKit2 (I will still keep a
separated repository hosted by inria for unstable or too specific
developments).

To conclude, we were a little bit overloaded these last weeks and we
have delayed the merge, but we will work on this soon (probably before
the end of march). For the moment, you should use the VMKit2
repository as it's probably the most advanced one.

Hi Gael,

  does it mean vmkit will based on the latest llvm after the merge finished?

  I run into the same issue Chris meet when trying to verify tilegx backend by compiling vmkit.

JavaJIT.cpp:1262:23: error: no member named 'removeFnAttr' in
'llvm::Function'
        llvmFunction->removeFnAttr(

  then I change to vmkit2, but found it's based on 3.2 only, failed compile with latest llvm

Hi Jiong,

on VMKit2 repository, there is a branch named llvm_svn which is the closest branch to LLVM's trunk.
You will need to apply the following patch to LLVM or disable assertions to compile VMKit with lastest version of LLVM.
I am actually working on fixing the problem.

In a short time, VMKit repository (LLVM host) will be also synchronized.

Harris Bakiras

llvm.patch (559 Bytes)