Open sanados opened 4 years ago
@sanados hi there! I haven't done active maintenance on java-gnome for years, but as it happened I installed a new computer the other day and attempted to build & install one of my old programs. Without knowing better I tried Java 10 and yeah, it didn't work.
I spent a brief moment ripping out the javah
stuff out of ./configure and replacing it with calls to javac -h
but this didn't work as it generated stubs for files for which there was no implementation and the build broke.
I didn't have more time to investigate; installing Java 1.8.0 worked as a fallback but obviously that isn't sustainable long term.
I saw that there is no active maintenance, just wanted to document it here for others to see if they run into this. Thanks for coming back and giving an update!
FWIW I was able to build using openjdk-11 on debian. I happened to have javah
on my PATH
from an openjdk-8 install. This was an accident -- didn't realize I still had openjdk-8 installed.
$ readlink /usr/bin/javah /etc/alternatives/javah
/etc/alternatives/javah
/usr/lib/jvm/java-8-openjdk-amd64/bin/javah
$ dpkg-query -S /usr/lib/jvm/java-8-openjdk-amd64/bin/javah
openjdk-8-jdk-headless:amd64: /usr/lib/jvm/java-8-openjdk-amd64/bin/javah
Here's the .config
:
# This is an automatically generated Makefile fragment which is used
# to configure java-gnome for building. Do not edit (your changes will
# be overwritten next time ./configure is run), do not commit to
# repository. Anyone packaging java-gnome on any operating system:
# please do not override this file by patching it! Figure out what the
# problem is, and let us know so we can improve the ./configure perl
# script which generates it.
OS=debian
# The lists of jars are colon separated, suitable for being
# concatenated into a CLASSPATH
JUNIT_JARS=/usr/share/java/junit.jar
# the JAVAC variable contains the path to the java source compiler,
# the JAVA variable contains the path to the java runtime virtual
# machine. In both cases, the _CMD variable is for the terse output
# when make commands are running.
JAVAC=/usr/lib/jvm/java-11-openjdk-amd64/bin/javac -g -source 1.6 -target 1.6
JAVAC_CMD=JAVAC
# the JAVAH, JAR, and JAVADOC variables simply contains a usable jar
# and javah executable, respectively, while the JAVAH_CMD, JAR_CMD,
# and JAVADOC_CMD variables is for display purposes, matching the
# pattern above.
JAVAH=/usr/lib/jvm/java-8-openjdk-amd64/bin/javah -jni
JAVAH_CMD=JAVAH
JAR=/usr/bin/fastjar
JAR_CMD=JAR
JAVADOC=/usr/lib/jvm/java-11-openjdk-amd64/bin/javadoc
JAVADOC_CMD=JAVADOC
JAVA=/usr/lib/jvm/java-11-openjdk-amd64/bin/java -client -ea -Djava.awt.headless=true
JAVA_CMD=JAVA
# the path to the C compiler
CCACHE=/usr/bin/ccache
CC=/usr/bin/x86_64-linux-gnu-gcc-10 -g -Wall -fPIC -I/usr/lib/jvm/java-11-openjdk-amd64/include -I/usr/lib/jvm/java-11-openjdk-amd64/include/linux -Wno-int-to-pointer-cast -Wno-pointer-to-int-cast -Werror-implicit-function-declaration -Wfatal-errors
CC_CMD=GCC
LINK=/usr/bin/x86_64-linux-gnu-gcc-10 -g -shared -Wall -fPIC
LINK_CMD=LINK
# the install prefix. This *only* affects the location that installed
# files are sent to during the `make install` step. You can, as it
# happens, override it on the make command line the same way you
# specify DESTDIR, ie by doing `make PREFIX=/blah install`.
PREFIX=/home/dvogel/opt/java-gnome
LIBDIR=/home/dvogel/opt/java-gnome/lib
JARDIR=/home/dvogel/opt/java-gnome/share/java
# finally, we extract the version strings from the source code, for
# use in naming the target library files.
APIVERSION=4.1
VERSION=4.1.4-dev
I've managed to make the project compile with openjdk-11 on debian in this branch: https://github.com/dvogel/java-gnome/tree/jdk-11. I don't use java a lot so I'm less familiar with the other build tools (e.g. ./configure compiler=ecj
). As such, I suspect it will need quite a bit of additional work before I can push it upstream. Hopefully the WIP is helpful to anyone else who runs into this issue though.
javah was deprecated since long ago and was removed.
Replace javah with javac -h