wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)
Simon Peter Muwanga
smuwanga at gmail.com
Fri Aug 29 21:18:18 PDT 2008
Hi the WTK2.5.2 is now working well.
I fixed.
You can find the work around at
http://forums.sun.com/thread.jspa?messageID=10403593 .
Regards,
Simon.
On Fri, Aug 29, 2008 at 8:50 AM, Simon Peter Muwanga <smuwanga at gmail.com>wrote:
> Hi guys,
> Am using Linux 10.3, 64 bit. I get the following error with my wireless
> toolkit.
>
> *java.lang.UnsatisfiedLinkError: /home/smuwanga/WTK2.5.1/bin/sublime.so:
> /home/smuwanga/WTK2.5.1/bin/sublime.so: wrong ELF class: ELFCLASS32
> (Possible cause: architecture word width mismatch)
> at java.lang.ClassLoader$NativeLibrary.load(Native Method)
> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1778)
> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1674)
> at java.lang.Runtime.load0(Runtime.java:770)
> at java.lang.System.load(System.java:1005)
> at com.sun.kvem.Sublime.<init>(Unknown Source)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at java.lang.Class.newInstance0(Class.java:355)
> at java.lang.Class.newInstance(Class.java:308)
> at com.sun.kvem.Lime.createLime(Unknown Source)
> at com.sun.kvem.KVMBridge.<init>(Unknown Source)
> at com.sun.kvem.KVMBridge.getBridge(Unknown Source)
> at com.sun.kvem.midp.MIDP.run(Unknown Source)
> at com.sun.kvem.environment.EmulatorInvoker.runEmulatorImpl(Unknown
> Source)
> at com.sun.kvem.environment.EmulatorInvoker.main(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at com.sun.kvem.environment.JVM.main(Unknown Source)*
>
> Any help?
>
> Simon.
>
> On Thu, Aug 28, 2008 at 10:00 PM, <jdk6-dev-request at openjdk.java.net>wrote:
>
>> Send jdk6-dev mailing list submissions to
>> jdk6-dev at openjdk.java.net
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> http://mail.openjdk.java.net/mailman/listinfo/jdk6-dev
>> or, via email, send a message with subject or body 'help' to
>> jdk6-dev-request at openjdk.java.net
>>
>> You can reach the person managing the list at
>> jdk6-dev-owner at openjdk.java.net
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of jdk6-dev digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: splashscreen.so is missing pnggccrd.c (Mark Wielaard)
>> 2. Re: splashscreen.so is missing pnggccrd.c (Mark Wielaard)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Thu, 28 Aug 2008 19:35:32 +0200
>> From: Mark Wielaard <mark at klomp.org>
>> Subject: Re: splashscreen.so is missing pnggccrd.c
>> To: Anthony Petrov <Anthony.Petrov at Sun.COM>
>> Cc: awt-dev at openjdk.java.net, build-dev <build-dev at openjdk.java.net>,
>> jdk6-dev <jdk6-dev at openjdk.java.net>,
>> distro-pkg-dev at openjdk.java.net
>> Message-ID: <1219944932.23036.3.camel at hermans.wildebeest.org>
>> Content-Type: text/plain
>>
>> Hi Anthony,
>>
>> On Thu, 2008-08-28 at 14:23 +0400, Anthony Petrov wrote:
>> > 1. The patch cuts off the embedded versions of these libraries from
>> > OpenJDK source code. In fact, there may exist systems where these
>> > libraries are not installed. And currently OpenJDK runs perfectly on
>> > these systems since it have the libraries compiled in.
>>
>> Yes it does remove the upstream sources. But I admit to be slightly
>> confused about this practice of embedding upstream source code into your
>> own code repository. If we want to support static linking of libraries
>> wouldn't it be enough to configure and detect the static library .a
>> versions and link against those?
>>
>> > 2. The system libraries may contain issues/errors/bugs/whatever which
>> > our code cannot deal with (I think Java2D folks may collaborate on
>> > this). Throwing the libraries away from the OpenJDK code may reveal some
>> > of the issues, but we obviously can't fix the libraries as fast as our
>> > code. And also, we do guarantee some behavior (like understanding file
>> > format versions or whatever) that we wouldn't be able to guarantee if we
>> > can't ship our copies of the libraries.
>>
>> It would be good to have a list of the guarantees so we can write tests
>> and configure checks to make sure only correct libraries are linked in.
>>
>> Cheers,
>>
>> Mark
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Thu, 28 Aug 2008 19:41:59 +0200
>> From: Mark Wielaard <mark at klomp.org>
>> Subject: Re: splashscreen.so is missing pnggccrd.c
>> To: Martin Buchholz <martinrb at google.com>
>> Cc: awt-dev at openjdk.java.net, Anthony Petrov <Anthony.Petrov at sun.com>,
>> build-dev <build-dev at openjdk.java.net>, jdk6-dev
>> <jdk6-dev at openjdk.java.net>, distro-pkg-dev at openjdk.java.net
>> Message-ID: <1219945319.23036.11.camel at hermans.wildebeest.org>
>> Content-Type: text/plain
>>
>> On Thu, 2008-08-28 at 09:48 -0700, Martin Buchholz wrote:
>> > In its current form, the icedtea-libraries.patch
>> > would probably be rejected by Sun, because it
>> > unconditionally changes to using the system libraries.
>> > Instead it should be an option.
>>
>> Yeah, it would be interesting to look into that. Although I think the
>> option should be between linking static or shared libraries. Embedding
>> the sources seem a bit fragile and apparently hard to update inside
>> openjdk because of sun legal issues.
>>
>> > A quick look at the changes suggests
>> > they are insufficiently portable (i.e. a quick hack):
>> > e.g.
>> > + void *handle = dlopen("libjpeg.so.62", RTLD_LAZY | RTLD_GLOBAL);
>>
>> icedtea INSTALL explicitly mentions this version to use. But it would
>> indeed be better if configure does explicitly check for this version of
>> the library.
>>
>> Thanks,
>>
>> Mark
>>
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> jdk6-dev mailing list
>> jdk6-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/jdk6-dev
>>
>>
>> End of jdk6-dev Digest, Vol 8, Issue 9
>> **************************************
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20080830/1e90efc8/attachment.html
More information about the jdk6-dev
mailing list