All of your assumptions below are correct-- the patch/flags didn't quite get me there, though I thank you very much for your help at the time.
I would be happy to give you access to my devel instance, if that would assist you in assembling a GDAL 1.5.3 - Image I/O Ext stack. It's a 64-bit Fedora Core VMWare virtual instance with sufficient power for most development tasks. Please contact me off-list if you'd like that.
Hi,
I have found an old email (16 august) where I have sent to you a patch for gdal swig java bindings for 1.5.x as well as some instructions about setting optimization flags to prevent JVM SIGSEGV crashes .
Actually, I suppose neither the patch nor the flags settings solved your problem since they still exist (Supposing you have applied patch and tips, right?).
Anyway, as you could have noticed in the imageio-ext devel ML, I'm working on building an imageio-ext version leveraging on gdal 1.5.3, therefore I will back with additional info. (However I haven't a 64 bit machine to test)
Regards,
Daniele
On Mon, Oct 27, 2008 at 8:10 PM, ajs6f <ajs6f@anonymised.com> wrote:
I think I may have caught my problem (only to run across another, an
old friend). In my Tomcat logs, hidden away there was this:
Oct 24, 2008 7:08:40 AM
it.geosolutions.imageio.gdalframework.GDALUtilities loadGDAL
WARNING: Native library load failed.java.lang.UnsatisfiedLinkError: /
usr/java/jdk1.6.0_06/jre/lib/amd64/libgdaljni.so: /usr/java/
jdk1.6.0_06/jre/lib/amd64/libgdaljni.so: wrong ELF class: ELFCLASS32
(Possible cause: architecture word width mismatch)
Unless I read that wrongly, it looks like the prebuilt libs are not
going to work with a 64-bit arch.
I've shifted back to my locally-built libs and Tomcat comes up error-
less and best of all: the Coverage Plugins List now includes all of
the new types.
Unfortunately, actually trying to create a coverage (a MrSID) crashes
out Tomcat with a segfault I've seen before:
# An unexpected error has been detected by Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00002aab00490039, pid=16639, tid=1099176272
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (10.0-b22 mixed mode
linux-amd64)
# Problematic frame:
# C [libgdal.so+0x270039] GDALGetMetadata+0x9
I think this is now an Image I/O Ext question, not so much a GeoServer
question.
However, I do think it would be lovely to have a set of known-good 64-
bit compatible libs distributed for those of us who run 64-bit
systems. I'm usually very happy to compile my own libraries, but it's
been many months (with kind help from GeoSolutions people) and I have
never been able to get the complete GeoServer -> Image I/O Ext -> GDAL
> MrSID SDK stack working, on account of this same segfault. I'd be
happy to contribute such libraries, if I could only get them working
myself. {grin}
---
A. Soroka / Digital Scholarship Services R & D
the University of Virginia Library
On Oct 27, 2008, at 11:13 AM, ajs6f wrote:
> Yikes!
>
> I just reread the instructions more carefully (as carefully as I
> should have read them originally) and now I understand what Andrea
> means by copying the jars into WEB_INF/lib. I failed to do that. I'll
> try that before asking any more dumb questions... {grin}
>
> ---
> A. Soroka / Digital Scholarship Services R & D
> the University of Virginia Library
>
> On Oct 27, 2008, at 11:04 AM, ajs6f wrote:
>
>> Please see inlined responses to Andrea...
>> On Oct 27, 2008, at 10:46 AM, Andrea Aime wrote:
>>
>>> ajs6f ha scritto:
>>>> <snipped>
>>>> Oct 24, 2008 2:20:55 AM
>>>> org.apache.catalina.core.AprLifecycleListener init
>>>> INFO: The APR based Apache Tomcat Native library which allows
>>>> optimal performance in production environments was not found on
>>>> the java.library.path: /tmp/linux-gdal-mrsid_1.7.0_onwards
>>>> in the Tomcat log. Of course, running with my own built libs I saw
>>>> a different path there, but the point is that the JVM clearly had
>>>> access to the appropriate libs, whether those available from the
>>>> GeoServer site or ones I built locally.
>>>
>>> Don't get confused by this error, The APR based Apache Tomcat
>>> Native library is just a way to accelerate serving data out of
>>> Tomcat,
>>> especially static files, but has nothing to do with GDAL.
>>> More information about it here:
>>> http://tomcat.apache.org/tomcat-5.5-doc/apr.html
>>> http://tomcat.apache.org/native-doc/index.html
>>
>> Oh, I understand that, Andrea. I was offering the error as evidence
>> that Java has access to the directory in which the libs are stored.
>> I run my production instance with the Native Connector but my devel
>> instance without. Pure laziness on my part. {grin}
>>
>> Actually, on that topic, I was recently reading the O'Reilly Tomcat
>> book and the authors suggest that the Java Connector may actually be
>> faster than the Native Connector in many circumstances. They
>> compared the Native Connector, the Java Connector, and the Apache
>> Portable Runtime as well as examining different options for
>> connecting through Apache HTTPD. It's an interesting question, with
>> real consequences for people doing high-performance work like many
>> GeoServer users. I recommend the book heartily:
>>
>> http://oreilly.com/catalog/9780596003180/
>>
>>>
>>>> Then I went ahead and copied the libs to the jre/lib directory
>>>> and restarted Tomcat. That's exactly the method described on the
>>>> page referenced below. No difference, though: still the same
>>>> Coverage Plugins List. Incidentally, in the Tomcat startup, I'm
>>>> seeing:
>>>
>>> Hum, did you copy the contentes of the GDAL extensions inside
>>> geoserver/WEB-INF/lib?
>>
>> I did not, because they appear to all be native code and not .jars.
>> Is that something I need to do? That would be a bit unusual and it's
>> not mentioned in the instructions.
>>
>> ---
>> A. Soroka / Digital Scholarship Services R & D
>> the University of Virginia Library
>>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Geoserver-users mailing list
> Geoserver-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
--
-------------------------------------------------------
Eng. Daniele Romagnoli
Software Engineer
GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 328 0559267
http://www.geo-solutions.it
-------------------------------------------------------
