Errors compiling jpl

[Ben Engbers]

I didn't need to use library(jpl) before so I never noticed that the standard build procedure failed to compile the jpl package.

When building swipl 7.3.18 on my Fedora Linux, config.log contains the following lines:

Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux

Other lines I recognize which indicate that something is wrong with java, are:

warning: [options] bootstrap class path not set in conjunction with -source 1.5
warning: [options] source value 1.5 is obsolete and will be removed in a future release
warning: [options] target value 1.5 is obsolete and will be removed in a future release
warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
4 warnings
configure:5219: $? = 0
configure:5229: java  Test
Error: Could not find or load main class Test
configure:5232: $? = 1
configure: failed program was:
/* [#]line 5208 "configure" */
public class Test {
public static void main (String args[]) {
        System.exit (0);
} }
configure:5238: error: The Java VM java failed (see config.log, check the CLASSPATH?)

I use  /usr/java/jdk1.8.0_73/jre/bin/java for java-development.

How can I instruct build to use this version instead of java 1.5.0?
Ben

[Paul Singleton]

Ben

The 4 warnings are unrelated to the build issue and can be ignored.

You do not need to build with Java 1.8.0_73 in order to run with it - 1.5.0 should be fine (Java has good default forward compatibility) (and configurable backward compatibility).

I am barely familiar with 'configure' but it appears to be probing the Java (1.5.0) it has found, by exporting a tiny test source, compiling it (successfully?) then trying to run the generated .class file (but failing to find it).

Like it says: check the CLASSPATH, and where & whether Test.class was created.

Personally I prefer the App Store model of software installation ;-)

Paul Singleton

On Saturday, 12 March 2016 01:54:11 UTC, Ben Engbers wrote:

I didn't need to use library(jpl) before so I never noticed that the standard build procedure failed to compile the jpl package.

When building swipl 7.3.18 on my Fedora Linux, config.log contains the following lines:

...

[Ben Engbers]

Hi Paul,

These are my PATH and CLASSPATH:

echo $PATH
/usr/java/default/bin:/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/home/bengbers/.local/bin:/home/bengbers/bin:/home/bengbers/Programs/baseX/bin
echo $CLASSPATH
/home/bengbers/Downloads/Java/BaseX/BaseX73.jar:/home/bengbers/SGD

alternatives--config java returns the following installed JRE' s. /usr/java/default points to /usr/java/jdk1.8.0_73/jre/bin/java.

  Selectie    Commando
-----------------------------------------------
   1           /usr/lib/jvm/jre-1.5.0-gcj/bin/java
*  2           /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java
   3           /usr/java/jdk1.8.0_60/jre/bin/java
   4           /usr/java/jre1.8.0_60/bin/java
 + 5           /usr/java/jdk1.8.0_73/jre/bin/java

Test.java is succesfully compiled (Test.class exists).

The javase-documentation states that "The class path tells the JDK tools and applications where to find third-party and user-defined classes -- that is, classes that are not extensions or part of the Java platform."

This leads me to the following questions:
1: What classes should I add to CLASSPATH?
2:  How can I instruct configure to use the same java-version for testing Test.java and compiling the library?

Ben

Op zaterdag 12 maart 2016 14:38:16 UTC+1 schreef Paul Singleton:

Ben
....

[Jan Wielemaker]

On 03/12/2016 10:45 PM, Ben Engbers wrote:
> Hi Paul,
>
> These are my PATH and CLASSPATH:
>
> |
> echo $PATH
> /usr/java/default/bin:/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/home/bengbers/.local/bin:/home/bengbers/bin:/home/bengbers/Programs/baseX/bin
> echo $CLASSPATH
> /home/bengbers/Downloads/Java/BaseX/BaseX73.jar:/home/bengbers/SGD
> |
>
>
>
> alternatives--config java returns the following installed JRE' s.
> /usr/java/default points to /usr/java/jdk1.8.0_73/jre/bin/java.
>
> |
> SelectieCommando
> -----------------------------------------------
> 1/usr/lib/jvm/jre-1.5.0-gcj/bin/java
> *2/usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java
> 3/usr/java/jdk1.8.0_60/jre/bin/java
> 4/usr/java/jre1.8.0_60/bin/java
> +5/usr/java/jdk1.8.0_73/jre/bin/java
> |
>
> Test.java is succesfully compiled (Test.class exists).
>
> The javase-documentation states that "The class path tells the JDK tools
> and applications where to find third-party and user-defined classes --
> that is, classes that are not extensions

> <http://docs.oracle.com/javase/7/docs/technotes/guides/extensions/index.html>

> or part of the Java platform."
>
> This leads me to the following questions:
> 1: What classes should I add to CLASSPATH?
> 2: How can I instruct configure to use the same java-version for
> testing Test.java and compiling the library?

Just read what it says. It seems to have produced Test.class and fails
running `java Test` in that directory. I guess the classpath must include
"."? There are so many things to test and so many options to get Java
correctly configured (in particular the JNI binding) that this will always
be a delicate process. Typically, make sure no weird directories are in
$PATH that overrule system utilities and have weird environment settings.
The build process is designed to work in a fairly minimal environment.

> Personally I prefer the App Store model of software installation ;-)
>
> Paul Singleton

If you don't want trouble, get Ubuntu and use the PPA. Unfortunately
other Linux distros do not have a similar feature and thus you either
need to compile yourself or have to use an old version. I think gentoo
is pretty much up-to-date thanks to Keri.

Cheers --- Jan

[Ben Engbers]

After updating .bash_profile to:

export JAVA_HOME=/usr/java/default
PATH=$JAVA_HOME/bin:$PATH:$HOME/.local/bin:$HOME/bin:$HOME/Programs/BaseX/bin
CLASSPATH=.:$HOME/Programs/BaseX/Base.jar:$HOME/SGD:$HOME/Downloads/Prolog/swipl-devel/packages/jpl/jpl.jar

export PATH
export CLASSPATH

the java-part compiles without problems and a jpl.jar is build in /home/bengbers/Downloads/Prolog/swipl-devel/packages/jpl/

The build-process itself however fails when trying to create library(jlp) "% Loading library(jpl) ......................... FAILED
Warning: Cannot load required shared library"

In packages/jpl/config.logthere are some lines reporting that conftest.c can not becompiled.
conftest.c:9:28: fatal error: ac_nonexistent.h: No such file or directory
conftest.c: In function 'main':
conftest.c:55:21: error: expected expression before ')' token
conftest.c:22:9: error: unknown type name 'not'
conftest.c:22:15: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'universal'
conftest.c:22:15: error: unknown type name 'universal'
conftest.c: In function 'main':
conftest.c:28:4: error: unknown type name 'not'
conftest.c:28:12: error: expected

Running the examples produces this output:

JPL demo: Exceptions

calling

?- X is Y.

in Prolog to force a Prolog 'instantiation_error' exception,
which should be returned via Java as an uncaught org.jpl7.PrologException in thread "main":

Exception in thread "main" java.lang.UnsatisfiedLinkError: /home/bengbers/lib/swipl-7.3.18/lib/x86_64-linux/libjpl.so: libjsig.so: kan gedeeld objectbestand niet openen: Bestand of map bestaat niet
    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1938)
    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1854)
    at java.lang.Runtime.loadLibrary0(Runtime.java:870)
    at java.lang.System.loadLibrary(System.java:1122)
    at org.jpl7.JPL.loadNativeLibrary(JPL.java:97)
    at org.jpl7.fli.Prolog.<clinit>(Prolog.java:59)
    at org.jpl7.Query.open(Query.java:280)
    at org.jpl7.Util.textToTerm(Util.java:120)
    at org.jpl7.Query.<init>(Query.java:164)
    at org.jpl7.Query.hasSolution(Query.java:760)
    at Exceptions.main(Exceptions.java:13)

I have appended the outpuf from the build-process. Hope this helps.

Cheers -- Ben (who likes working with Fedora)


Op maandag 14 maart 2016 09:27:31 UTC+1 schreef Jan Wielemaker:

[Jan Wielemaker]

On 15/03/16 11:25, Ben Engbers wrote:

> The build-process itself however fails when trying to create
> library(jlp) "% Loading library(jpl) ......................... FAILED
> Warning: Cannot load required shared library"

The build seems to have ended fine. Before you can use it however, you
have to add the directory holding libjvm.so (or wheever it is called) to
your LD_LIBRARY_PATH. You can check by locating jpl.so and running:

ldd jpl.so

That will tell you whih components it cannot find. Find them, extend
LD_LIBRARY_PATH and try again until it stops complaining.

Cheers --- Jan

[Ben Engbers]

The shared library is named libjpl.so
Issuing the command 'ldd libjpl.so' learned that the following librarys.could not be found:
libjsig.so, libjava.so, libverify.so and libjvm.so.

The first 3 library's could be found in /usr/java/default/jre/lib/amd64. Libjvm.so was found in /usr/java/default/jre/lib/amd64/server.

In order to load these 4 library's I created a java.conf (touch /etc/ld.so.conf.d/java.conf) and added the following lines:
/usr/java/default/jre/lib/amd64
/usr/java/default/jre/lib/amd64/server

After the command 'ldconfig' all the jpl-examples can be executed.

Thanx for the help.

Ben

Op dinsdag 15 maart 2016 12:30:25 UTC+1 schreef Jan Wielemaker:

[Jan Wielemaker]

On 03/16/2016 09:52 AM, Ben Engbers wrote:
>
> The shared library is named libjpl.so
> Issuing the command 'ldd libjpl.so' learned that the following
> librarys.could not be found:
> libjsig.so, libjava.so, libverify.so and libjvm.so.
>
> The first 3 library's could be found in /usr/java/default/jre/lib/amd64.
> Libjvm.so was found in /usr/java/default/jre/lib/amd64/server.
>
> In order to load these 4 library's I created a java.conf (touch
> /etc/ld.so.conf.d/java.conf) and added the following lines:
> /usr/java/default/jre/lib/amd64
> /usr/java/default/jre/lib/amd64/server
>
> After the command 'ldconfig' all the jpl-examples can be executed.

Looks like an elegant solution. I typically add them to my ~/.bashrc
The Windows version tries to locate Java and updates %PATH%.
Unfortunately, updating LD_LIBRARY_PATH in a running program has no
effect.

Cheers --- Jan

> Thanx for the help.
>
> Ben
>
> Op dinsdag 15 maart 2016 12:30:25 UTC+1 schreef Jan Wielemaker:
>
> On 15/03/16 11:25, Ben Engbers wrote:
>
> > The build-process itself however fails when trying to create
> > library(jlp) "% Loading library(jpl) .........................
> FAILED
> > Warning: Cannot load required shared library"
>
> The build seems to have ended fine. Before you can use it however, you
> have to add the directory holding libjvm.so (or wheever it is
> called) to
> your LD_LIBRARY_PATH. You can check by locating jpl.so and running:
>
> ldd jpl.so
>
> That will tell you whih components it cannot find. Find them, extend
> LD_LIBRARY_PATH and try again until it stops complaining.
>
> Cheers --- Jan
>

> --
> You received this message because you are subscribed to the Google
> Groups "SWI-Prolog" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swi-prolog+...@googlegroups.com
> <mailto:swi-prolog+...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/swi-prolog.
> For more options, visit https://groups.google.com/d/optout.

[Ranjan Kumar]

But how to get the exact output of your bottom most code...As this exception is not
lallowing us to get the exact output that is really for it without any exception with output.