Prev: OutOfMemory using ThreadPoolExecutor
Next: Menu in Swing
From: cr88192 on 22 Apr 2010 11:01

"EJP" <esmond.not.pitt(a)not.bigpond.com> wrote in message
news:bLVzn.20720$pv.9107(a)news-server.bigpond.net.au...
> On 22/04/2010 6:10 PM, junyoung wrote:
>> libadscli.so: wrong ELF class: ELFCLASS32 (Possible cause:
>> architecture word width mismatch)
>
> Bit of a giveaway, don't you think?

yeah, it is not likely possible apart from using some kind of emulator (say,
an x86 emulator with JNI support).

easier would be, if possible, to compile/request/... 64-bit libraries (as
well as libs for whatever other arch it may need to run on), and use these
in addition to the 32-bit libs.

for example:
libfoo.i386.so
libfoo.x86-64.so
libfoo.ppc64.so
....

and then load the version appropriate for the correct arch.


sadly, with Java, one is almost better off just rewriting whatever library
functionality in Java, and then possibly sidestepping the issue.

or such...


From: RedGrittyBrick on 22 Apr 2010 12:30
On 22/04/2010 09:10, junyoung wrote:
> I have a 64bit jvm now, [... for GNU/Linux 2.4.0]
....
> and, my java applications are using 32bit shared libraries to be run
> normally.
....
> Is there any way to use 32bit shared libraries on 64 bit platforms
> without installing proper jvm version ( in case of, 32bit jvm ).

"It is not currently possible in Linux for a 64-bit program to
dynamically load a 32-bit library."
- http://www.redhat.com/magazine/009jul05/features/multilib/

--
RGB
From: Joshua Cranmer on 22 Apr 2010 13:52
On 04/22/2010 11:01 AM, cr88192 wrote:
> "EJP"<esmond.not.pitt(a)not.bigpond.com> wrote in message
> news:bLVzn.20720$pv.9107(a)news-server.bigpond.net.au...
>> On 22/04/2010 6:10 PM, junyoung wrote:
>>> libadscli.so: wrong ELF class: ELFCLASS32 (Possible cause:
>>> architecture word width mismatch)
>>
>> Bit of a giveaway, don't you think?
>
> yeah, it is not likely possible apart from using some kind of emulator (say,
> an x86 emulator with JNI support).

It could be possible, I think, if you really specialized the library
loading feature to do stub libraries and a lot of appropriate trampolining.

Far easier would be spawning a 32-bit process that can load the library
and then RPC'ing stuff between the two. Still not fun, though.

> easier would be, if possible, to compile/request/... 64-bit libraries (as
> well as libs for whatever other arch it may need to run on), and use these
> in addition to the 32-bit libs.

Or use multilib stuff (ugh)!

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
 | 
Pages: 1
Prev: OutOfMemory using ThreadPoolExecutor
Next: Menu in Swing