| Summary: | dev-db/mysql-workbench-8.0.36: java version should support bytecode of antlr classes | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Fabio Rossi <rossi.f> |
| Component: | Current packages | Assignee: | Hans de Graaff <graaff> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | gentoo, harrisl, rossi.f, scott |
| Priority: | Normal | Keywords: | PATCH, PullRequest |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://github.com/gentoo/gentoo/pull/41056 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
By using this patch I solved the problem:
--- /usr/portage/dev-db/mysql-workbench/mysql-workbench-8.0.38.ebuild 2024-07-03 07:41:22.000000000 +0200
+++ /usr/portage/dev-db/mysql-workbench/mysql-workbench-8.0.38-r1.ebuild 2024-07-06 12:58:13.333185688 +0200
@@ -9,7 +9,13 @@
ANTLR_VERSION=4.11.1
-inherit gnome2 flag-o-matic python-single-r1 cmake
+# Doesn't build with jre-8
+_JAVA_PKG_WANT_BUILD_VM=( openjdk{,-jre}{,-bin}-{17,21} )
+JAVA_PKG_WANT_BUILD_VM=${_JAVA_PKG_WANT_BUILD_VM[@]}
+JAVA_PKG_WANT_SOURCE="11"
+JAVA_PKG_WANT_TARGET="11"
+
+inherit gnome2 flag-o-matic java-utils-2 python-single-r1 cmake
MY_P="${PN}-community-${PV}-src"
@@ -71,6 +77,11 @@
"${FILESDIR}/${PN}-8.0.33-gcc13.patch"
)
+pkg_setup() {
+ java-pkg_init
+ python-single-r1_pkg_setup
+}
+
src_unpack() {
unpack ${PN}-community-${PV}-src.tar.gz
}
(In reply to Fabio Rossi from comment #1) > +JAVA_PKG_WANT_SOURCE="11" > +JAVA_PKG_WANT_TARGET="11" This would lock the ebuild to version 11 only when 17 (and perhaps 21) is also a viable option. (In reply to Hans de Graaff from comment #2) > (In reply to Fabio Rossi from comment #1) > > > +JAVA_PKG_WANT_SOURCE="11" > > +JAVA_PKG_WANT_TARGET="11" > > This would lock the ebuild to version 11 only when 17 (and perhaps 21) is > also a viable option. Unfortunately this is how is implemented java-utils-2.eclass in java-pkg_switch-vm(). Do you know a better way? the real problem is that antlr-tool was built with a newer java version than the one which is used to build mysql-workbench (In reply to Fabio Rossi from comment #0) > I get a build error because antlr is downloaded precompiled instead of using > the system version. > > [342/788] cd > /var/tmp/portage/dev-db/mysql-workbench-8.0.36/work/mysql-workbench- > community-8.0.36-src/library/parsers/grammars && /etc/java-config-2/current- > system-vm/bin/java -Xmx1024m -jar > /var/tmp/portage/dev-db/mysql-workbench-8.0.36/distdir/antlr-4.11.1-complete. > jar -Dlanguage=Cpp -listener -visitor -o ../my > sql -package parsers > /var/tmp/portage/dev-db/mysql-workbench-8.0.36/work/mysql-workbench- > community-8.0.36-src/library/parsers/grammars/MySQLLexer.g4 /var/tmp > /portage/dev-db/mysql-workbench-8.0.36/work/mysql-workbench-community-8.0.36- > src/library/parsers/grammars/MySQLParser.g4 > FAILED: > /var/tmp/portage/dev-db/mysql-workbench-8.0.36/work/mysql-workbench- > community-8.0.36-src/library/parsers/mysql/MySQLLexer.h > /var/tmp/portage/dev-db/m > ysql-workbench-8.0.36/work/mysql-workbench-community-8.0.36-src/library/ > parsers/mysql/MySQLLexer.tokens > /var/tmp/portage/dev-db/mysql-workbench-8.0.36/work/m > ysql-workbench-community-8.0.36-src/library/parsers/mysql/ > MySQLParserBaseListener.h > /var/tmp/portage/dev-db/mysql-workbench-8.0.36/work/mysql-workbench-commu > nity-8.0.36-src/library/parsers/mysql/MySQLParserBaseVisitor.h > /var/tmp/portage/dev-db/mysql-workbench-8.0.36/work/mysql-workbench- > community-8.0.36-src/libra > ry/parsers/mysql/MySQLParser.h > /var/tmp/portage/dev-db/mysql-workbench-8.0.36/work/mysql-workbench- > community-8.0.36-src/library/parsers/mysql/MySQLParserList > ener.h > /var/tmp/portage/dev-db/mysql-workbench-8.0.36/work/mysql-workbench- > community-8.0.36-src/library/parsers/mysql/MySQLParser.tokens > /var/tmp/portage/dev > -db/mysql-workbench-8.0.36/work/mysql-workbench-community-8.0.36-src/library/ > parsers/mysql/MySQLParserVisitor.h > /var/tmp/portage/dev-db/mysql-workbench-8.0.3 > 6/work/mysql-workbench-community-8.0.36-src/library/parsers/mysql/MySQLLexer. > cpp > /var/tmp/portage/dev-db/mysql-workbench-8.0.36/work/mysql-workbench-communit > y-8.0.36-src/library/parsers/mysql/MySQLParserBaseListener.cpp > /var/tmp/portage/dev-db/mysql-workbench-8.0.36/work/mysql-workbench- > community-8.0.36-src/libra > ry/parsers/mysql/MySQLParserBaseVisitor.cpp > /var/tmp/portage/dev-db/mysql-workbench-8.0.36/work/mysql-workbench- > community-8.0.36-src/library/parsers/mysql/My > SQLParser.cpp > /var/tmp/portage/dev-db/mysql-workbench-8.0.36/work/mysql-workbench- > community-8.0.36-src/library/parsers/mysql/MySQLParserListener.cpp /var/tmp > /portage/dev-db/mysql-workbench-8.0.36/work/mysql-workbench-community-8.0.36- > src/library/parsers/mysql/MySQLParserVisitor.cpp > cd > /var/tmp/portage/dev-db/mysql-workbench-8.0.36/work/mysql-workbench- > community-8.0.36-src/library/parsers/grammars && > /etc/java-config-2/current-system-vm/ > bin/java -Xmx1024m -jar > /var/tmp/portage/dev-db/mysql-workbench-8.0.36/distdir/antlr-4.11.1-complete. > jar -Dlanguage=Cpp -listener -visitor -o ../mysql -packa > ge parsers > /var/tmp/portage/dev-db/mysql-workbench-8.0.36/work/mysql-workbench- > community-8.0.36-src/library/parsers/grammars/MySQLLexer.g4 > /var/tmp/portage/d > ev-db/mysql-workbench-8.0.36/work/mysql-workbench-community-8.0.36-src/ > library/parsers/grammars/MySQLParser.g4 > [...] this looks like there is java code generation involved. and then, what would it do with the freshly generated *.java files? to compile them, something would call javac which is available in a jdk but not in jre. On a new system I am building, I have just faced the same problem with mysql-workbench 8.0.40, I have seen that now we have in DEPEND =virtual/jre-11 but that doesn't solve the problem. The system vm is instead openjdk-bin-8 and that is returned when java-config is called below. So I still get the same error reported initially.
cd /var/tmp/portage/dev-db/mysql-workbench-8.0.40/work/mysql-workbench-community-8.0.40-src/library/parsers/grammars && /etc/java-config-2/current-system-vm/
bin/java -Xmx1024m -jar /var/tmp/portage/dev-db/mysql-workbench-8.0.40/distdir/antlr-4.13.2-complete.jar -Dlanguage=Cpp -listener -visitor -o ../mysql -packa
ge parsers /var/tmp/portage/dev-db/mysql-workbench-8.0.40/work/mysql-workbench-community-8.0.40-src/library/parsers/grammars/MySQLLexer.g4 /var/tmp/portage/d
ev-db/mysql-workbench-8.0.40/work/mysql-workbench-community-8.0.40-src/library/parsers/grammars/MySQLParser.g4
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.UnsupportedClassVersionError: org/antlr/v4/Tool has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:473)
at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:621)
The part "this version of the Java Runtime only recognizes class file versions up to 52.0" of the error message is related to the system vm (1.8). org/antlr/v4/Tool is instead coming from a binary package, and not from the system, which has been compiled using jdk-11, in fact:
$ unzip /var/cache/distfiles/antlr-4.13.2-complete.jar org/antlr/v4/Tool.class
$ javap -verbose org/antlr/v4/Tool.class | grep "major version"
major version: 55
Again, the problem is not solved because the java compiler used to build this package should be enforced to have the same version of org/antlr/v4/Tool. Or antlr-4.13.2 should be integrated in portage and built with another vm version.
Thinking more in general, this situation is related on how Gentoo manages java libraries, it is actually possible to mix bytecode coming from different vm versions and this kind of errors is frequently visible as soon as you add more libraries (not only from portage). IMHO the only reliable solution would be to implement an infrastructure like the one adopted for python packages, i.e. to build many versions of the same library.
I have packaged antlr-*-4.11.1 to be able to use system version of antlr, I patched mysql-workbench ebuild to use system antlr. In this way it's possible to remove the binary dependency. I still need a reliable way to verify the bytecode compatibility between the jvm used by the ebuild and the one used to compile antlr, this can be done in pkg_setup(). To discover the bytecode version I can use $ java-config --query SOURCE --package antlr-tool-4 @Volkmar: which is a reliable way to force the jvm version used in the ebuild? By using the >=virtual/jdk-11 in DEPEND/RDEPEND as in the current ebuild it should only fix the source/target values and not the jvm, in fact on my system I got version 1.8 leading to the failure described above. The problem is that there is no way with the dependencies to ask for the jvm used to build another package. Good news is that antlr-4.11.1 is compatible with all mysql-workbench versions in portage. (In reply to Fabio Rossi from comment #7) > [...] For discussion pls come on irc channel #gentoo-java. (In reply to Fabio Rossi from comment #1) > By using this patch I solved the problem: > [...] > +inherit gnome2 flag-o-matic java-utils-2 python-single-r1 cmake Do not inherit java-utils-2 directly. Inherit java-pkg-2 instead (or java-pkg-opt-2 for optional java) (In reply to Volkmar W. Pogatzki from comment #9) > (In reply to Fabio Rossi from comment #1) > > By using this patch I solved the problem: > > [...] > > +inherit gnome2 flag-o-matic java-utils-2 python-single-r1 cmake > Do not inherit java-utils-2 directly. Inherit java-pkg-2 instead > (or java-pkg-opt-2 for optional java) I need only java-pkg_init which I explicitly call in pkg_setup and other helper functions from java-utils, this package needs only the runtime. If you think is violating any rule I can amend that. In the PR here linked I added new versions of antlr* tools to remove binary dep from mysql-workbench |
I get a build error because antlr is downloaded precompiled instead of using the system version. [342/788] cd /var/tmp/portage/dev-db/mysql-workbench-8.0.36/work/mysql-workbench-community-8.0.36-src/library/parsers/grammars && /etc/java-config-2/current- system-vm/bin/java -Xmx1024m -jar /var/tmp/portage/dev-db/mysql-workbench-8.0.36/distdir/antlr-4.11.1-complete.jar -Dlanguage=Cpp -listener -visitor -o ../my sql -package parsers /var/tmp/portage/dev-db/mysql-workbench-8.0.36/work/mysql-workbench-community-8.0.36-src/library/parsers/grammars/MySQLLexer.g4 /var/tmp /portage/dev-db/mysql-workbench-8.0.36/work/mysql-workbench-community-8.0.36-src/library/parsers/grammars/MySQLParser.g4 FAILED: /var/tmp/portage/dev-db/mysql-workbench-8.0.36/work/mysql-workbench-community-8.0.36-src/library/parsers/mysql/MySQLLexer.h /var/tmp/portage/dev-db/m ysql-workbench-8.0.36/work/mysql-workbench-community-8.0.36-src/library/parsers/mysql/MySQLLexer.tokens /var/tmp/portage/dev-db/mysql-workbench-8.0.36/work/m ysql-workbench-community-8.0.36-src/library/parsers/mysql/MySQLParserBaseListener.h /var/tmp/portage/dev-db/mysql-workbench-8.0.36/work/mysql-workbench-commu nity-8.0.36-src/library/parsers/mysql/MySQLParserBaseVisitor.h /var/tmp/portage/dev-db/mysql-workbench-8.0.36/work/mysql-workbench-community-8.0.36-src/libra ry/parsers/mysql/MySQLParser.h /var/tmp/portage/dev-db/mysql-workbench-8.0.36/work/mysql-workbench-community-8.0.36-src/library/parsers/mysql/MySQLParserList ener.h /var/tmp/portage/dev-db/mysql-workbench-8.0.36/work/mysql-workbench-community-8.0.36-src/library/parsers/mysql/MySQLParser.tokens /var/tmp/portage/dev -db/mysql-workbench-8.0.36/work/mysql-workbench-community-8.0.36-src/library/parsers/mysql/MySQLParserVisitor.h /var/tmp/portage/dev-db/mysql-workbench-8.0.3 6/work/mysql-workbench-community-8.0.36-src/library/parsers/mysql/MySQLLexer.cpp /var/tmp/portage/dev-db/mysql-workbench-8.0.36/work/mysql-workbench-communit y-8.0.36-src/library/parsers/mysql/MySQLParserBaseListener.cpp /var/tmp/portage/dev-db/mysql-workbench-8.0.36/work/mysql-workbench-community-8.0.36-src/libra ry/parsers/mysql/MySQLParserBaseVisitor.cpp /var/tmp/portage/dev-db/mysql-workbench-8.0.36/work/mysql-workbench-community-8.0.36-src/library/parsers/mysql/My SQLParser.cpp /var/tmp/portage/dev-db/mysql-workbench-8.0.36/work/mysql-workbench-community-8.0.36-src/library/parsers/mysql/MySQLParserListener.cpp /var/tmp /portage/dev-db/mysql-workbench-8.0.36/work/mysql-workbench-community-8.0.36-src/library/parsers/mysql/MySQLParserVisitor.cpp cd /var/tmp/portage/dev-db/mysql-workbench-8.0.36/work/mysql-workbench-community-8.0.36-src/library/parsers/grammars && /etc/java-config-2/current-system-vm/ bin/java -Xmx1024m -jar /var/tmp/portage/dev-db/mysql-workbench-8.0.36/distdir/antlr-4.11.1-complete.jar -Dlanguage=Cpp -listener -visitor -o ../mysql -packa ge parsers /var/tmp/portage/dev-db/mysql-workbench-8.0.36/work/mysql-workbench-community-8.0.36-src/library/parsers/grammars/MySQLLexer.g4 /var/tmp/portage/d ev-db/mysql-workbench-8.0.36/work/mysql-workbench-community-8.0.36-src/library/parsers/grammars/MySQLParser.g4 Error: A JNI error has occurred, please check your installation and try again Exception in thread "main" java.lang.UnsupportedClassVersionError: org/antlr/v4/Tool has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:756) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:473) at java.net.URLClassLoader.access$100(URLClassLoader.java:74) at java.net.URLClassLoader$1.run(URLClassLoader.java:369) at java.net.URLClassLoader$1.run(URLClassLoader.java:363) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:362) at java.lang.ClassLoader.loadClass(ClassLoader.java:418) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352) at java.lang.ClassLoader.loadClass(ClassLoader.java:351) at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:621) I have the following configuration on my system: # eselect java-vm list Available Java Virtual Machines: [1] openjdk-bin-8 system-vm [2] openjdk-bin-17 It seems that the downloaded antlr version has been compiled with java-11 while version 8 is used during src_compile()