llvm dev - Jul 2014 - [LLVMdev] VMKit build problems; can't use LLVM3.4.2 ?

Greetings,

I've been using LLVM and Clang for some time, but I'm new to the list
and new to VMKit; please advise if I should post this elsewhere.

VMKit doesn't seem to build with LLVM/Clang 3.4.2 -- seems that one must use
LLVM3.3.  I see the following error:

VmkitGCPrinter.cpp:363:53: error: too many arguments to function call, expected
2, have 3
      AP.OutStreamer.EmitValue(address, IntPtrSize, 0);

I now see the vmkit build instructions (http://vmkit.llvm.org/get_started.html)
explicitly say to use LLVM and Clang 3.3; using that version fixes the above. 
It seems to be that the signature of (at least) one function from the LLVM
library (e.g., llvm/MC/MCStreamer.h::EmitValue(...)) changed from LLVM 3.3 =>
3.4.2 .

Is there any plan to migrate vmkit to build to build against LLVM >= 3.4.2 ? 
This is probably disruptive (ABI breakage?) but seems prudent; perhaps there are
other fundamental problems in this migration.  I'd be willing to contribute
to a 3.4.2-compatible branch if there is one (I don't see an obvious
candidate in svn repo http://llvm.org/svn/llvm-project/vmkit/branches).

Have I got this correct, or I missing something else?

Incidentally, this seems to be the same behavior/problem as reported on 20
January 2014 by neoedmund
(http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-January/069558.html), which is
solved by building using LLVM3.3 (no response seen).

Thank you!
Brian

On 21 July 2014 21:33, Brian Faull <bfaull at cog-e.com>
wrote:
> Incidentally, this seems to be the same behavior/problem as reported on 20
January 2014 by neoedmund
(http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-January/069558.html), which is
solved by building using LLVM3.3 (no response seen).
Hi Brian,

It's common for some projects to attach themselves to a specific
version of LLVM when the team doesn't have time to merge their code to
trunk every other week, which can be very costly in the long term.
However, any project that aims to be relevant in the LLVM community
has to follow trunk, not a specific release, not even the current
release. On projects whose aim is to present a proof-of-concept or to
focus on a completely unrelated issue (VMKit, LLVMpipe), this seems to
be the choice to stick to a release or even an SVN revision number.
But for any compilation tool, it should never be.

LLVM APIs do change considerably, even between a few commits apart.
So, even if you support 3.5svn trunk, you can become obsolete in a
matter of weeks. This dependency cannot be solved by LLVM supporting
old APIs, or the code would have more legacy than features, and has to
become a motto of the side projects themselves. Thus, unless VMKit
developers are willing to follow trunk and have buildbots following
the rest, it won't happen.

Of course, as with any open source project, *you* could be the person
to drive this, in case other VMKit developers are unwilling to take
the extra work. :)

cheers,
--renato

Hi Brian,

The development of VMKit is a little bit stuck because we don't have
any contributor. Basically, I'm alone on the project and I don't have
any time for development (the engineers and PhD students that were
involved in the project are all gone).

As you can see, we only support LLVM 3.3. If you are interested in
helping porting VMKit for a newer version, I can help to explain how
VMKit is designed and to explain how the tricky parts of the code
work? Otherwise, I have started an implementation of VMKit for MCJIT
and a newer version of LLVM one year ago (branch mcjit), but I'm
unable to find any time to continue since january. But it means that I
know what we have to do to follow the last changes made in LLVM :)

So, if you are interested in contributing, just tell me.

See you,
Gaël





Le 21 juil. 2014 23:19, "Renato Golin" <renato.golin at
linaro.org> a écrit :
>
> On 21 July 2014 21:33, Brian Faull <bfaull at cog-e.com> wrote:
> > Incidentally, this seems to be the same behavior/problem as reported
on 20 January 2014 by neoedmund
(http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-January/069558.html), which is
solved by building using LLVM3.3 (no response seen).
>
> Hi Brian,
>
> It's common for some projects to attach themselves to a specific
> version of LLVM when the team doesn't have time to merge their code to
> trunk every other week, which can be very costly in the long term.
> However, any project that aims to be relevant in the LLVM community
> has to follow trunk, not a specific release, not even the current
> release. On projects whose aim is to present a proof-of-concept or to
> focus on a completely unrelated issue (VMKit, LLVMpipe), this seems to
> be the choice to stick to a release or even an SVN revision number.
> But for any compilation tool, it should never be.
>
> LLVM APIs do change considerably, even between a few commits apart.
> So, even if you support 3.5svn trunk, you can become obsolete in a
> matter of weeks. This dependency cannot be solved by LLVM supporting
> old APIs, or the code would have more legacy than features, and has to
> become a motto of the side projects themselves. Thus, unless VMKit
> developers are willing to follow trunk and have buildbots following
> the rest, it won't happen.
>
> Of course, as with any open source project, *you* could be the person
> to drive this, in case other VMKit developers are unwilling to take
> the extra work. :)
>
> cheers,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev