wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)
Simon Peter Muwanga
smuwanga at gmail.com
Fri Aug 29 09:54:14 PDT 2008
Oh yeah.
I would like to know how the wireless tool kit can be successfully run
on a 64-bit linux machine. Some has suggested to me that it would be
nice to get the source for the sun wireless took kit(WTK2.5.2) and
compile it from my machine. Then later run it.
He noticed that the WTK2.5.2 appears to have been designed/compiled
from a 32 bit machine.
How can I access the source for WTK2.5,2 and compile it? Probably it
may work. More solutions are really welcome.
Thank you Joseph for your quick response!
Simon.
On 8/29/08, Joseph D. Darcy <Joe.Darcy at sun.com> wrote:
> Simon Peter Muwanga wrote:
>> Hi guys,
>> Am using Linux 10.3, 64 bit. I get the following error with my wireless
>> toolkit.
>
> Looks like your trying to use a 32-bit shared library on a 64 bit system...
>
> -Joe
>
>> /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
>> <mailto:jdk6-dev-request at openjdk.java.net>> wrote:
>>
>> Send jdk6-dev mailing list submissions to
>> jdk6-dev at openjdk.java.net <mailto: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
>> <mailto:jdk6-dev-request at openjdk.java.net>
>>
>> You can reach the person managing the list at
>> jdk6-dev-owner at openjdk.java.net
>> <mailto: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 <mailto: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 <mailto:awt-dev at openjdk.java.net>,
>> build-dev <build-dev at openjdk.java.net
>> <mailto:build-dev at openjdk.java.net>>,
>> jdk6-dev <jdk6-dev at openjdk.java.net
>> <mailto:jdk6-dev at openjdk.java.net>>, distro-pkg-dev at openjdk.java.net
>> <mailto:distro-pkg-dev at openjdk.java.net>
>> Message-ID: <1219944932.23036.3.camel at hermans.wildebeest.org
>> <mailto: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 <mailto:mark at klomp.org>>
>> Subject: Re: splashscreen.so is missing pnggccrd.c
>> To: Martin Buchholz <martinrb at google.com <mailto:martinrb at google.com>>
>> Cc: awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>,
>> Anthony Petrov <Anthony.Petrov at sun.com
>> <mailto:Anthony.Petrov at sun.com>>,
>> build-dev <build-dev at openjdk.java.net
>> <mailto:build-dev at openjdk.java.net>>, jdk6-dev
>> <jdk6-dev at openjdk.java.net
>> <mailto:jdk6-dev at openjdk.java.net>>, distro-pkg-dev at openjdk.java.net
>> <mailto:distro-pkg-dev at openjdk.java.net>
>> Message-ID: <1219945319.23036.11.camel at hermans.wildebeest.org
>> <mailto: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 <mailto:jdk6-dev at openjdk.java.net>
>> http://mail.openjdk.java.net/mailman/listinfo/jdk6-dev
>>
>>
>> End of jdk6-dev Digest, Vol 8, Issue 9
>> **************************************
>>
>>
>
>
More information about the jdk6-dev
mailing list