wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)
Joseph D. Darcy
Joe.Darcy at Sun.COM
Fri Aug 29 08:54:41 PDT 2008
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