Created attachment 791258 [details] emerge --info gdal When I build GDAL with USE=java, starting with version 3.5.0, the Java SWIG bindings are no longer built and installed. Upgrading from gdal-3.4.2, it looks like there was a switch from autotools to cmake, and the build log now shows: > -- Could NOT find JNI (missing: JAVA_AWT_LIBRARY JAVA_JVM_LIBRARY JAVA_INCLUDE_PATH JAVA_INCLUDE_PATH2 JAVA_AWT_INCLUDE_PATH) > ... > -- Found SWIG: /usr/bin/swig (found version "4.0.2") > -- Found Perl: /usr/bin/perl (found version "5.34.1") > -- Could NOT find JNI (missing: JAVA_AWT_LIBRARY JAVA_JVM_LIBRARY JAVA_INCLUDE_PATH JAVA_INCLUDE_PATH2 JAVA_AWT_INCLUDE_PATH) > -- Found Java: /usr/bin/java (found version "17.0.3") found components: Runtime Development > > ... > > -- The following OPTIONAL packages have been found: > > * Java > > -- The following OPTIONAL packages have not been found: > > * JNI > SWIG_JAVA: Java binding I looked at GDAL's CMakeLists and didn't see anything obviously wrong, so maybe this is a problem with cmake's FindJNI module not knowing how to find the system JVM. gdal-3.5.1 has the same problem. The build log is 1.8M, let me know if I should upload it compressed. Current package versions: dev-util/cmake-3.22.4::gentoo dev-java/openjdk-bin-17.0.3_p7:17::gentoo sci-libs/gdal-3.5.0-r4:0/31::gentoo > ~ # eselect java-vm list > Available Java Virtual Machines: > [1] openjdk-bin-8 > [2] openjdk-bin-11 > [3] openjdk-bin-17 system-vm
Please include the full build.log and CMake output files referenced in the log.
Created attachment 791261 [details] build.log.gz
In the ebuild I don't see the \"$(java-pkg_javac-args)\" which is recommended in https://wiki.gentoo.org/wiki/Java_Developer_Guide#Using_java-pkg-opt-2.eclass if use java; then myconf="${myconf} --with-javac-args=\"$(java-pkg_javac-args)\"" fi
(In reply to Khumba from comment #0) > [...] > > ~ # eselect java-vm list > > Available Java Virtual Machines: > > [1] openjdk-bin-8 > > [2] openjdk-bin-11 > > [3] openjdk-bin-17 system-vm Is the problem specific to openjdk-17 or does it also happen with -8 or -11?
It happens on openjdk-bin-11 too. My program depends on Java 11+ so I didn't try with -8. Looking for references in the tree to JAVA_JVM_LIBRARY and JAVA_INCLUDE_PATH, I see only one file, portmidi-234-cmake.patch. I don't see what should be setting these variables though. If I set all three variables manually in mycmakeargs, then JNI detection is fixed, and the build completes, with proper source and javadoc JARs too which the ad hoc 3.4.2 Java install code didn't do, that's exciting: > # Bindings > -DBUILD_PYTHON_BINDINGS=$(usex python) > -DBUILD_JAVA_BINDINGS=$(usex java) > + $(usex java -DJAVA_AWT_LIBRARY=/etc/java-config-2/current-system-vm/lib '') > + $(usex java -DJAVA_JVM_LIBRARY=/etc/java-config-2/current-system-vm/lib '') > + $(usex java -DJAVA_INCLUDE_PATH=/etc/java-config-2/current-system-vm/include '') > -- Found JNI: /etc/java-config-2/current-system-vm/lib > >>> Merging sci-libs/gdal-3.5.0-r5 to / > --- /usr/ > --- /usr/share/ > >>> /usr/share/java/ > >>> /usr/share/java/libgdalalljni.so > >>> /usr/share/java/gdal-3.5.0.jar > >>> /usr/share/java/gdal-3.5.0-javadoc.jar > >>> /usr/share/java/gdal-3.5.0-sources.jar > >>> /usr/share/java/gdal-3.5.0.pom I haven't tested whether this build runs yet, I'll do that tomorrow. Also not sure if there's a better way than hard coding the current JVM path.
Maybe cmake.eclass could set these variables automatically if USE=java, since FindJNI.cmake is a standard cmake module, then the gdal ebuild wouldn't need to be adjusted at all.
The new build works for me, apart from libgdalalljni.so not being in java.library.path by default and needing 'java -Djava.library.path=...' at runtime, since my program isn't packaged as a Gentoo ebuild. I thought I'd try using java-pkg_doso, and while /usr/lib64/gdal still isn't in the default library path, it seems to be following Gentoo policy more closely now. Attaching my current working ebuild. > $ java -XshowSettings:properties |& grep -A5 java.library.path > java.library.path = /usr/java/packages/lib > /usr/lib64 > /lib64 > /lib > /usr/lib > java.runtime.name = OpenJDK Runtime Environment
Created attachment 791336 [details] gdal-3.5.0-r5.ebuild
*** Bug 906119 has been marked as a duplicate of this bug. ***
(In reply to Khumba from comment #8) > Created attachment 791336 [details] > gdal-3.5.0-r5.ebuild Would you mind rebasing this? I'm sorry I missed it at the time.
Created attachment 862620 [details] gdal-3.7.0.ebuild with JAVA_* set Sure thing, here's a patched 3.7.0 ebuild. I've taken inspiration from the sun-jai-bin ebuild and added a postinst message about the need to invoke java with -Djava.library.path to be able to use the bindings. This ebuild builds for me, but unfortunately on the project we were using this for, we migrated away from GDAL, so I am not able to test it at runtime. I would appreciate if someone else could do so. Thanks!
Created attachment 862621 [details] gdal-3.7.0.ebuild with JAVA_* set Sorry, uploaded the wrong file.
Created attachment 862622 [details, diff] Patch for gdal-3.7.0.ebuild with JAVA_* set
(In reply to Khumba from comment #13) > Created attachment 862622 [details, diff] [details, diff] > Patch for gdal-3.7.0.ebuild with JAVA_* set Did setting --with-javac-args and moving jdk-1.8:* to DEPEND not help?
I'm going to merge this for now (thank you!) given it's currently pretty broken and I feel bad for leaving it that way.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cf214682cf6f27a30d12877ecb98c8e9e4255ff0 commit cf214682cf6f27a30d12877ecb98c8e9e4255ff0 Author: Bryan Gardiner <bog@khumba.net> AuthorDate: 2023-05-26 04:47:39 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-05-26 08:28:06 +0000 sci-libs/gdal: fix the build of the Java bindings GDAL uses FindJNI.cmake which is unable to find a Java VM on its own. This change passes in the system VM symlink explicitly, and also installs the JNI shared library in the proper location for Gentoo via 'java-pkg_doso', rather than in the same directory as the JAR. Bug: https://bugs.gentoo.org/857816 Signed-off-by: Bryan Gardiner <bog@khumba.net> Signed-off-by: Sam James <sam@gentoo.org> sci-libs/gdal/gdal-3.7.0.ebuild | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)
Hi Volkmar, thanks for your suggestion and sorry for not responding to it earlier. I'm not sure --with-javac-args="$(java-pkg_javac-args)" is applicable because --with-javac-args appears to be some autoconf-style option, and GDAL uses cmake. As far as I can tell, this flag is just an example, I don't see it anywhere in the tree (or am I missing something?). Also, java-pkg_javac-args() seems to only produce "-source 1.8 -target 1.8" and I'm not sure this helps with the library run path. At least, I think a better fix (than my patch) is to make gdal inherit from one of the java eclasses and use the logic there to retrieve the VM, so that e.g. it respects JAVA_PKG_FORCE_VM. Even better might be to make cmake.eclass detect USE=java and pass these -D... options itself, but I'm not sure what the best way is to get cmake.eclass and java-*.eclass to cooperate. Is it acceptable style for cmake.eclass to check for java-utils in INHERITED from a phase function (and then call its functions)? Making cmake.eclass unconditionally inherit a Java eclass seems wrong. Thanks for merging, Sam!
Created attachment 862683 [details, diff] patch for moving jdk-1.8:* to DEPEND (In reply to Khumba from comment #17) > [...] > At least, I think a better fix (than my patch) is to make gdal inherit from > one of the java eclasses and use the logic there to retrieve the VM, [...] That's why I proposed »moving jdk-1.8:* to DEPEND«.
Okay, I have to apologize, that works, I had missed a few things in seeing why. Let's apply Volkmar's patch please.
(In reply to Khumba from comment #19) > Okay, I have to apologize, that works, I had missed a few things in seeing > why. Let's apply Volkmar's patch please. The reason why Volkmar is right (not his fault!) is because the Java eclasses are insane and don't follow conventions. We want to fix them soon (TM). (They do weird things like parsing *DEPEND instead of using normal options to control behaviour. They don't actually let you use the full spectrum of legal dependencies either.)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1070f871662ac888cbe769ea3f1e2337f3652e1b commit 1070f871662ac888cbe769ea3f1e2337f3652e1b Author: Volkmar W. Pogatzki <gentoo@pogatzki.net> AuthorDate: 2023-05-30 03:37:14 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-05-30 03:37:34 +0000 sci-libs/gdal: move jdk dependency from BDEPEND to BDEPEND Closes: https://bugs.gentoo.org/857816 Signed-off-by: Volkmar W. Pogatzki <gentoo@pogatzki.net> Signed-off-by: Sam James <sam@gentoo.org> sci-libs/gdal/gdal-3.7.0.ebuild | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-)
Maybe not quite fixed?
still run into this nowadays.
(In reply to Toralf Förster from comment #23) > still run into this nowadays. Which version? ~sci-libs/gdal-3.5.0 is gone. Don't you run into trouble with jdk:21? See https://github.com/gentoo/gentoo/pull/35165.
*** This bug has been marked as a duplicate of bug 903107 ***
