[Gdal-dev] GDAL 1.6 Java binding, Windows

[Matthew Cole]

I've created java bindings for GDAL 1.6 in Windows and it seemed to work but
I'm getting linker errors whenever I try to access any gdal functions.

java.lang.UnsatisfiedLinkError:
C:\build182\gdal-1.6.0\swig\java\apps\gdaljni.dl
l: Can't find dependent libraries
Exception in thread "main" java.lang.UnsatisfiedLinkError:
org.gdal.gdal.gdalJNI.AllRegister()V
at org.gdal.gdal.gdalJNI.AllRegister(Native Method)
at org.gdal.gdal.gdal.AllRegister(gdal.java:255)
at R2gcpinfo.R2ExtractFootprint(R2gcpinfo.java:100)
at R2gcpinfo.main(R2gcpinfo.java:78)

I've got it working for version 1.4, with the dlls in the same places, so
I'm not sure what the problem is. II don't think the java binding are
officially supported for 1.6 but has anyone gottem them working?

Thanks for your help,
Matt

[Even Rouault]

Yes, I've managed to build them, but with Linux. Have you verified that the
gdal.jar is generated and at the right place ?
There are instructions here :
http://trac.osgeo.org/gdal/wiki/GdalOgrInJavaBuildInstructions

It would be great if you could update the wiki page in case something has
really change in the build process since that page was written.

You should also be warned that due to missing SWIG typemaps, quite a few
methods in 1.6 bindings have wrong signature, which will hopefully be fixed
in the future in 1.7dev once I've commited the code.

Post by Matthew Cole
I've created java bindings for GDAL 1.6 in Windows and it seemed to work
but I'm getting linker errors whenever I try to access any gdal functions.
C:\build182\gdal-1.6.0\swig\java\apps\gdaljni.dl
l: Can't find dependent libraries
org.gdal.gdal.gdalJNI.AllRegister()V
at org.gdal.gdal.gdalJNI.AllRegister(Native Method)
at org.gdal.gdal.gdal.AllRegister(gdal.java:255)
at R2gcpinfo.R2ExtractFootprint(R2gcpinfo.java:100)
at R2gcpinfo.main(R2gcpinfo.java:78)
I've got it working for version 1.4, with the dlls in the same places, so
I'm not sure what the problem is. II don't think the java binding are
officially supported for 1.6 but has anyone gottem them working?
Thanks for your help,
Matt

[Matthew Cole]

Thanks Evan. It turned out the problem had to do with including HDF4 and
HDF5 support. Once I removed those the binding worked.

I had used the instructions at
http://trac.osgeo.org/gdal/wiki/GdalOgrInJavaBuildInstructions and will
update them for the newer program versions.

Matt

Post by Even Rouault
Yes, I've managed to build them, but with Linux. Have you verified that the
gdal.jar is generated and at the right place ?
http://trac.osgeo.org/gdal/wiki/GdalOgrInJavaBuildInstructions
It would be great if you could update the wiki page in case something has
really change in the build process since that page was written.
You should also be warned that due to missing SWIG typemaps, quite a few
methods in 1.6 bindings have wrong signature, which will hopefully be fixed
in the future in 1.7dev once I've commited the code.

Post by Matthew Cole
I've created java bindings for GDAL 1.6 in Windows and it seemed to work
but I'm getting linker errors whenever I try to access any gdal functions.
C:\build182\gdal-1.6.0\swig\java\apps\gdaljni.dl
l: Can't find dependent libraries
org.gdal.gdal.gdalJNI.AllRegister()V
at org.gdal.gdal.gdalJNI.AllRegister(Native Method)
at org.gdal.gdal.gdal.AllRegister(gdal.java:255)
at R2gcpinfo.R2ExtractFootprint(R2gcpinfo.java:100)
at R2gcpinfo.main(R2gcpinfo.java:78)
I've got it working for version 1.4, with the dlls in the same places, so
I'm not sure what the problem is. II don't think the java binding are
officially supported for 1.6 but has anyone gottem them working?
Thanks for your help,
Matt

_______________________________________________
gdal-dev mailing list
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[Even Rouault]

Matthew,

For the record, I just commited yesterday in GDAL SVN trunk a substantial
update to the java bindings I was mentionning. Now all necessary typemaps
have been created, so it looks rather good (no more SWIGTYPE_p_* classes). I
would be interested in having early feedback from people already using the
Java bindings to check if I haven't broken existing API. It shouldn't
hopefully (at least the 2 test applications still run against the bindings).
It also adds methods with default argument values, for example
ogr.Open(String filename) in addition to the full ogr.Open(String filename,
int update). Some facilities that look more java'ish have been added, like
String Geometry.ExportToWkt(), in addition to the existing int
Geometry.ExportToWkt(String[] argout), etc. A previous commit already added
support for progress callbacks in GDAL API.

Best regards

Post by Matthew Cole
Thanks Evan. It turned out the problem had to do with including HDF4 and
HDF5 support. Once I removed those the binding worked.
I had used the instructions at
http://trac.osgeo.org/gdal/wiki/GdalOgrInJavaBuildInstructions and will
update them for the newer program versions.
Matt

Post by Even Rouault
Yes, I've managed to build them, but with Linux. Have you verified that the
gdal.jar is generated and at the right place ?
http://trac.osgeo.org/gdal/wiki/GdalOgrInJavaBuildInstructions
It would be great if you could update the wiki page in case something has
really change in the build process since that page was written.
You should also be warned that due to missing SWIG typemaps, quite a few
methods in 1.6 bindings have wrong signature, which will hopefully be fixed
in the future in 1.7dev once I've commited the code.

Post by Matthew Cole
I've created java bindings for GDAL 1.6 in Windows and it seemed to work
but I'm getting linker errors whenever I try to access any gdal functions.
C:\build182\gdal-1.6.0\swig\java\apps\gdaljni.dl
l: Can't find dependent libraries
org.gdal.gdal.gdalJNI.AllRegister()V
at org.gdal.gdal.gdalJNI.AllRegister(Native Method)
at org.gdal.gdal.gdal.AllRegister(gdal.java:255)
at R2gcpinfo.R2ExtractFootprint(R2gcpinfo.java:100)
at R2gcpinfo.main(R2gcpinfo.java:78)
I've got it working for version 1.4, with the dlls in the same places,
so I'm not sure what the problem is. II don't think the java binding
are officially supported for 1.6 but has anyone gottem them working?
Thanks for your help,
Matt

_______________________________________________
gdal-dev mailing list
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[Matthew Cole]

Sure, I'd be happy to try them to make sure they don't break anything.
Where would I get the updated version?

Matt


Matthew,

For the record, I just commited yesterday in GDAL SVN trunk a substantial
update to the java bindings I was mentionning. Now all necessary typemaps
have been created, so it looks rather good (no more SWIGTYPE_p_* classes). I
would be interested in having early feedback from people already using the
Java bindings to check if I haven't broken existing API. It shouldn't
hopefully (at least the 2 test applications still run against the bindings).
It also adds methods with default argument values, for example
ogr.Open(String filename) in addition to the full ogr.Open(String filename,
int update). Some facilities that look more java'ish have been added, like
String Geometry.ExportToWkt(), in addition to the existing int
Geometry.ExportToWkt(String[] argout), etc. A previous commit already added
support for progress callbacks in GDAL API.

Best regards

[Even Rouault]

Hi Matt,

You'll have to build GDAL and the Java bindings from the latest daily snapshot
of the SVN trunk head. You can download the source at
http://download.osgeo.org/gdal/daily/
(download the gdal-svn-trunk*.tar.gz or gdal-svntrunk*.zip at your
convenience)

Thanks

Post by Matthew Cole
Sure, I'd be happy to try them to make sure they don't break anything.
Where would I get the updated version?
Matt
Matthew,
For the record, I just commited yesterday in GDAL SVN trunk a substantial
update to the java bindings I was mentionning. Now all necessary typemaps
have been created, so it looks rather good (no more SWIGTYPE_p_* classes).
I would be interested in having early feedback from people already using
the Java bindings to check if I haven't broken existing API. It shouldn't
hopefully (at least the 2 test applications still run against the
bindings). It also adds methods with default argument values, for example
ogr.Open(String filename) in addition to the full ogr.Open(String filename,
int update). Some facilities that look more java'ish have been added, like
String Geometry.ExportToWkt(), in addition to the existing int
Geometry.ExportToWkt(String[] argout), etc. A previous commit already added
support for progress callbacks in GDAL API.
Best regards

[trailcode]

I got gdal java binding to work with win32. I downloaded the jre from:
http://udig.refractions.net/files/downloads/jre/

And used it to execute my test program. For the java .jar files I am not
using gdal.jar but the jars which come with: imageio-ext

The thing which is strange is if I copy the gdaljni.dll gdal14.dll and other
.dll files from the jdk downloaded above to my project dir and set my
java.library.path to point to them I get the same old unsatisfied link
error. I even tried copying over all .dll files in the JDK tree but got the
same message.

Does anyone have any idea what is going on here?

I would like to create an application distributable via jnlp.

Thanks,
Matthew Tang

[Daniele Romagnoli]

Hi,
please read below.

Post by trailcode
http://udig.refractions.net/files/downloads/jre/

Note that these libraries have been built against GDAL 1.4.4.
Where do you have placed the DLLs to let them work during your first test?

Post by trailcode
<http://udig.refractions.net/files/downloads/jre/>
And used it to execute my test program. For the java .jar files I am not
using gdal.jar but the jars which come with: imageio-ext
The thing which is strange is if I copy the gdaljni.dll gdal14.dll and other
.dll files from the jdk downloaded above to my project dir and set my
java.library.path to point to them I get the same old unsatisfied link
error. I even tried copying over all .dll files in the JDK tree but got the
same message.
Does anyone have any idea what is going on here?

On Windows, we have sometime noticed similar issues on DLL native libs
loading. Not sure what is happening when this occurs. (Be sure that all
required libraries are together with these DLLs (A check with "Dependency
walker" may be helpful)).
A solution could be putting them on your JDK/bin being sure that the same
libs aren't somewhere on folders linked by your PATH env. (Be sure you
don't have old GDAL Libs somewhere hidden on your machine)
This could be helpful to do some initial testings. See my next feeddback
about JNLP.

Post by trailcode
I would like to create an application distributable via jnlp.

We are working on creating a web start application involving other native
libraries (not GDAL related).
Therefore we will handle native DLLs loading and some feedbacks on this
topic will come in the near future (we are working on it this week).

Cheers,
Daniele

Post by trailcode
Thanks,
Matthew Tang
--
http://n2.nabble.com/GDAL-1.6-Java-binding%2C-Windows-tp2299600p2369562.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
_______________________________________________
gdal-dev mailing list
http://lists.osgeo.org/mailman/listinfo/gdal-dev

--
-------------------------------------------------------
Eng. Daniele Romagnoli
Software Engineer

GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: [phone]
fax: [phone]
mob: [phone]


http://www.geo-solutions.it

-------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090223/d62c8da6/attachment.html

[Collins, Benjamin]

If one native library (DLL) loads another, the "java.library.path" variable will not be honored, since it's not Java doing the load, but the OS trying to resolve the dependencies for the DLL. As Daniele suggested, Dependency Walker is a great tool for finding out the relationships between libraries.
To solve this problem in software I write, I often do a "defensive load". You can call System.loadLibrary() with the secondary library and have Java load it up from the "java.library.path". Then, when the JNI library is loaded, the library it depends on will already be in memory ready to go. Using this technique I have never had to place native libraries in the JDK itself. This method work only on windows, where DLLs are reused in a process by default, and will most likely not work on other platforms.

--
Ben

From: gdal-dev-***@lists.osgeo.org [mailto:gdal-dev-***@lists.osgeo.org] On Behalf Of Daniele Romagnoli
Sent: Monday, February 23, 2009 6:24 AM
To: trailcode
Cc: gdal-***@lists.osgeo.org
Subject: Re: [Gdal-dev] GDAL 1.6 Java binding, Windows

Hi,
please read below.
On Mon, Feb 23, 2009 at 12:06 AM, trailcode <***@gmail.com<mailto:***@gmail.com>> wrote:

I got gdal java binding to work with win32. I downloaded the jre from:
http://udig.refractions.net/files/downloads/jre/

Note that these libraries have been built against GDAL 1.4.4.
Where do you have placed the DLLs to let them work during your first test?




And used it to execute my test program. For the java .jar files I am not
using gdal.jar but the jars which come with: imageio-ext

The thing which is strange is if I copy the gdaljni.dll gdal14.dll and other
.dll files from the jdk downloaded above to my project dir and set my
java.library.path to point to them I get the same old unsatisfied link
error. I even tried copying over all .dll files in the JDK tree but got the
same message.

Does anyone have any idea what is going on here?

On Windows, we have sometime noticed similar issues on DLL native libs loading. Not sure what is happening when this occurs. (Be sure that all required libraries are together with these DLLs (A check with "Dependency walker" may be helpful)).
A solution could be putting them on your JDK/bin being sure that the same libs aren't somewhere on folders linked by your PATH env. (Be sure you don't have old GDAL Libs somewhere hidden on your machine)
This could be helpful to do some initial testings. See my next feeddback about JNLP.



I would like to create an application distributable via jnlp.

We are working on creating a web start application involving other native libraries (not GDAL related).
Therefore we will handle native DLLs loading and some feedbacks on this topic will come in the near future (we are working on it this week).

Cheers,
Daniele




Thanks,
Matthew Tang
--
View this message in context: http://n2.nabble.com/GDAL-1.6-Java-binding%2C-Windows-tp2299600p2369562.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.

_______________________________________________
gdal-dev mailing list
gdal-***@lists.osgeo.org<mailto:gdal-***@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/gdal-dev



--
-------------------------------------------------------
Eng. Daniele Romagnoli
Software Engineer

GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: [phone]
fax: [phone]
mob: [phone]


http://www.geo-solutions.it

-------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090223/3511b2af/attachment-0001.html