sosy-lab/llvm-j

Java bindings for LLVM libraries

llvm-j's Issues

Setup Travis CI

Setup a Travis CI environment running Findbugs, checkstyle, eclipse compile, future unit tests and other useful things.

Build with JDK 9 fails

Hi,

when I try to build the master branch I'm getting this error:

    [mkdir] Created dir: /home/mchalupa/src/llvm-j/.apt-generated
    [javac] Compiling 1 source file to /home/mchalupa/src/llvm-j/bin
    [javac] Compiling 18 source files to /home/mchalupa/src/llvm-j/bin
    [javac] /home/mchalupa/src/llvm-j/src/main/java/org/sosy_lab/llvm_j/Module.java:35: error: package com.sun.istack.internal does not exist
    [javac] import com.sun.istack.internal.Nullable;
    [javac]                               ^
    [javac] /home/mchalupa/src/llvm-j/src/main/java/org/sosy_lab/llvm_j/Utils.java:32: error: package com.sun.istack.internal does not exist
    [javac] import com.sun.istack.internal.Nullable;
    [javac]                               ^
    [javac] /home/mchalupa/src/llvm-j/src/main/java/org/sosy_lab/llvm_j/Module.java:187: error: cannot find symbol
    [javac]   public @Nullable String getOriginFileName() {
    [javac]           ^
    [javac]   symbol:   class Nullable
    [javac]   location: class Module
    [javac] /home/mchalupa/src/llvm-j/src/main/java/org/sosy_lab/llvm_j/Utils.java:45: error: cannot find symbol
    [javac]   static boolean llvmBoolToJavaBool(@Nullable LLVMLibrary.LLVMBool pBool) {
    [javac]                                      ^
    [javac]   symbol:   class Nullable
    [javac]   location: class Utils
    [javac] 4 errors

I guess I may have a different version of JDK?

openjdk version "9"
OpenJDK Runtime Environment (build 9+181)
OpenJDK 64-Bit Server VM (build 9+181, mixed mode)

Fix license declarations in package

The Ivy and Maven metadata claim that this package is under the MIT license, but actually it is under LGPL-3.0-or-later AND MIT, correct?

Furthermore, the Ivy metadata claims that libedit and libtinfo are under the LLVM Release License, but this is also not correct. According to the copyright info of the Debian package, libedit is under BSD-3-Clause, but the situation for libtinfo is more complex (if I read it correctly, it is BSD-3-Clause AND MIT AND X11 with a long list of copyright holders that need to be mentioned).
Maybe this is a reason to redecide #10 and stop bundling them?

Add documentation

Add a documentation for:

• how to install the library
• how to publish new versions of llvm-j and llvm-lib to ivy

and improve the readme to give a quick overview.
Make clear that this project includes two modules, llvm-j and llvm-lib.

We should also mention the importance of using correct LLVM versions.

Consistently fail on illegal operations.

Currently, we have different ways of handling illegal operations:

• just call the underlying C function and return its error value
• assert statements
• throwing an LLVMException

Only the last is an acceptable way of handling illegal operations, so this should be used everywhere.

Add tests

Add at least tests for loading the shared library and parsing a small bitcode file.

Update to newer version of LLVM

We're currently building bindings for LLVM 3.9 .
We could update to a newer version of LLVM, to get access to latest improvements.

We could try LLVM 4 first, and then proceed to LLVM 6 or even LLVM 10,
depending on how many breaking changes exist.

Add Javadoc

Add Javadoc descriptions for all public methods in org.sosy_lab.llvm_j .

Require Java 11?

CPAchecker is switching to Java 11, so from our point of view LLVM-J could do this as well. Newer Java brings some features and the build system could be simplified. Are there other users of LLVM-J who still require compatibility with Java 8?

Use jnaerator-runtime?

Currently the repo includes two classes from jnaerator-runtime. We could include jnaerator-runtime as a dependency (it is available as a JAR), but it includes a lot more classes.

If we don't do this, than we need to declare the license properly.

Library dependencies of libLLVM*so

We currently get the libLLVM-3.9.1.so from the the Ubuntu 12.04 package of LLVM.

This has the following two dependencies, that don't exist on Gentoo Linux, by default:

• libtinfo.so.5
• libedit.so.2

For libtinfo.so.5, it seems that USE-flag tinfo must be set for sys-libs/ncurses package.
This introduces other challenges, though.
While this is solvable, I don't think that we should pressure our users to introduce package-related
problems into their system, if avoidable.
Thus, as an alternative, we could ship the libLLVM*.so with the libtinfo.so.5 - it only depends on libraries
that are included with libc6:

> ldd /lib/x86_64-linux-gnu/libtinfo.so.5
	linux-vdso.so.1 =>  (0x00007fff189f2000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007efc96b9d000)
	/lib64/ld-linux-x86-64.so.2 (0x00007efc971a6000)

For libedit.so.2, there's a Gentoo package.
The dependencies of libedit.so.2 are the same as for libtinfo.so.5, though, + libtinfo.so.5:

> ldd /usr/lib/x86_64-linux-gnu/libedit.so.2
	linux-vdso.so.1 =>  (0x00007ffd77bf2000)
	libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f4a3ef15000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4a3eb35000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f4a3f375000)

Since libedit doesn't seem to be a universal Linux default (as stated by the Gentoo package),
I'd vote for also deploying the libedit.so.2 with the libLLVM*so .

Add CI checks for Java 14

Currently, all our CI checks use Java 11. That means that our project is not tested against newer Java versions.

The infrastructure provided by https://gitlab.com/sosy-lab/software/java-project-template/ already contains definitions for Java 14,
so we should use them.

To do so, we need a docker image that contains Java 14 and an installation of the llvm version used by us, currently 3.9.
Installation of Java 14 on Ubuntu 18 is not straightforward, but would be easy on newer Ubuntu 20.
Installation of LLVM 3.9 on Ubuntu 20 is not straightforward though, because of required, but outdated libraries.

Handling this should be easy once we upgrade to a later LLVM version (#14)