#2288 closed task (fixed)
libgdal-java needs to be added to the nightly osgeo repo
Reported by: | misev | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | OSGeoLive15.0 |
Component: | OSGeoLive | Keywords: | |
Cc: | pebau, kalxas |
Description
On OSGeoLive 14, libgdal-java
is the standard Ubuntu 20.04 version 3.0.4, but the rest of GDAL libs and tools is 3.2.0. So there's an incompatibility which causes errors in applications that use libgdal-java, e.g. rasdaman gets this bogus error:
java.lang.RuntimeException: OGR Error: General Error
Change History (20)
comment:1 by , 4 years ago
comment:2 by , 4 years ago
The OSGeoLive 14.0 supports Java fine though, and installs GDAL from an unofficial package repo. This needs to be resolved somehow on OSGeoLive: either add libgdal-java to this package repo, or install GDAL from the standard Ubuntu 20.04 repos. Otherwise GDAL is broken, as it's missing the Java bindings.
comment:3 by , 4 years ago
Cc: | added |
---|
I had to compile gdal 3.2 manually, include libgdalalljni.so in the rasdaman package, and then copy it in the install_rasdaman.sh script to fix this.
comment:5 by , 3 years ago
Milestone: | OSGeoLive14.0 → OSGeoLive15.0 |
---|
Ticket retargeted after milestone closed
comment:6 by , 2 years ago
wrt. OSGeoLive15, current alpha1 iso
just wanted to check OpenJUMP gdal support and noticed gdal-jni is missing. seems like the above still stands or even worse, there isn't even a libgdal-java package anymore in Ubuntu 22 Jammy https://packages.ubuntu.com/search?suite=all&arch=any&searchon=names&keywords=gdal-java
the installer can probably download and build it, but it'll probably easier just to provide it.
opinions?
comment:7 by , 2 years ago
just took some spare time to try and build the missing java jni. i succeeded for simplicity sake with Lubuntu22's default gdal 3.4.1
- install in a virtual machine
- activate deb+src apt entries,
apt get update
now pretty much as explained here https://www.ducea.com/2008/03/06/howto-recompile-debian-packages/ patch/rebuild the package
apt-get install devscripts build-essential
,apt-get build-dep gdal-bin
we need java and ant for the java-bindings
apt-get install openjdk-8-jdk openjdk-8-source ant
- as user,
apt-get source gdal-bin
cd gdal-3.4.1+dfsg/
- edit
debian/rules
, add--with-java
afteroverride_dh_auto_configure:
- edit
swig/java/java.opt
JAVA_HOME to point to/usr/lib/jvm/java-1.8.0-openjdk-amd64
- build
debuild -us -uc
this resulted in the deb packages built, but java-jni was still missing. so i ran that explicitely
cd swig/java/
make
dunno why i needed to run it explicitely. the resulting swig/java/libgdalalljni.so
however worked as expected.
not sure if that can be integrated into the updated gdal-3.4.3 package on https://launchpad.net/~osgeolive/+archive/ubuntu/nightly/+packages
although the above result will likely work for all 3.4.x versions, the java-binding can probably be built from the updated package as well.
comment:8 by , 2 years ago
Reverting this change should be your starting point to get Java support back into the gdal package:
https://salsa.debian.org/debian-gis-team/gdal/-/commit/936e50e1a9e5eb3d1bd10147b5d5c25476845b23
From 3.5.0 onwards that will need to be adapted to CMake.
follow-up: 10 comment:9 by , 2 years ago
thx Bas,
looks like lot to just build it for a one arch LiveCD :). simply prebuilding it for amd64 and place the prebuilt binaries looks like the way to go.
@kalxas do you agree? if so i'd be willing to build/zip and place it in our OJ/osgeo file space.
follow-up: 13 comment:10 by , 2 years ago
This is what we did as well for rasdaman, use prebuilt binaries for amd64. In case you want to reuse it: https://download.rasdaman.org/installer/tpinstaller/ubuntu2204/
comment:11 by , 2 years ago
Not building libgdal-java from the gdal source package will make it go out of sync quickly.
If you don't want to hassle to maintain the gdal packaging changes for OSGeoLive, you could download the JAR from Maven Central in install_rasdaman.sh
or install_openjump.sh
:
For example:
cd /usr/share/java GDAL_VERSION=$(apt-cache show libgdal-dev | grep Version | awk -F': ' '{print $2}' | sort | tail -1 | awk -F'.' '{print $1"."$2".0"}') wget https://repo1.maven.org/maven2/org/gdal/gdal/${GDAL_VERSION}/gdal-${GDAL_VERSION}.jar ln -s gdal-${GDAL_VERSION}.jar gdal.jar cd $OLDPWD
comment:12 by , 2 years ago
Not building libgdal-java from the gdal source package will make it go out of sync quickly.
shouldn't be an issue, as the gdal version is fixed on OSGeo-LiveCD and won't change after release. maybe it's worth spending some effort when gdal 3.5 will be used (wrt. to the cmake switch you mentioned)
If you don't want to hassle to maintain the gdal packaging changes for OSGeoLive, you could download the JAR from Maven Central in install_rasdaman.sh or install_openjump.sh
from my experience, the issue usually isn't the gdal's lightweight jar binding, but the JNI, which isn't contained in it and needs to match the system's gdal. that's what's currently missing.
comment:13 by , 2 years ago
Replying to misev:
This is what we did as well for rasdaman, use prebuilt binaries for amd64. In case you want to reuse it: https://download.rasdaman.org/installer/tpinstaller/ubuntu2204/
as it mentions no version, i'll assume this was built for/with gdal-3.4.1 then too, right?
comment:14 by , 2 years ago
Sounds ok to use a pre-build archive for the java bindings, please keep in mind that we have gdal 3.4.3 in our ppa.
comment:17 by , 2 years ago
downloading https://download.osgeo.org/livedvd/nightly/osgeolive-nightly-build110-amd64-2514c6c-master.iso is slow.
will have a look later.
comment:19 by , 2 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:20 by , 7 months ago
I just had to do the manual build for Ubuntu 24.04 as well, following similar steps as in comment:7 except in debian/rules
you append a CMake option now -DBUILD_JAVA_BINDINGS=ON
.
The
libgdal-java
binary package is no longer built sincegdal (3.1.0~rc1+dfsg-1~exp1)
because it prevented building gdal and its reverse dependencies on architectures for which Java is not available (Debian Bug #947960 - gdal: Doesn't build on ports without java).