From: junyoung on
I have a 64bit jvm now,

$> file /usr/lib/jvm/java-1.5.0-sun/jre/bin/java
/usr/lib/jvm/java-1.5.0-sun/jre/bin/java: ELF 64-bit LSB executable,
x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked
(uses shared libs), stripped

and, my java applications are using 32bit shared libraries to be run
normally.

$ file libadscli.so
libadscli.so: ELF 32-bit LSB shared object, Intel 80386, version 1
(SYSV), not stripped

but, whenever my applications are failed because of the following
errors.

java.lang.UnsatisfiedLinkError: /home/jykim/work/trunk/ads/ads_home/
lib/libadscli.so: /home/jykim/work/trunk/ads/ads_home/lib/
libadscli.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:1753)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1678)
at java.lang.Runtime.loadLibrary0(Runtime.java:822)
at java.lang.System.loadLibrary(System.java:993)
at com.altibase.ads.jdbc.ADSCLI.<init>(ADSCLI.java:33)
at com.altibase.ads.jdbc.ADSDriver.initialize(ADSDriver.java:117)
at com.altibase.ads.jdbc.ADSDriver.connect(ADSDriver.java:217)
at java.sql.DriverManager.getConnection(DriverManager.java:525)
at java.sql.DriverManager.getConnection(DriverManager.java:193)
at ads.jdbc.test.common.TestUtil.openConnect(TestUtil.java:99)
at ads.jdbc.test.common.TestUtil.openConnect(TestUtil.java:88)
at ads.jdbc.test.ConnectionTest.setUp(ConnectionTest.java:25)

Is there any way to use 32bit shared libraries on 64 bit platforms
without installing proper jvm version ( in case of, 32bit jvm ).

any helps would be much appreciated. thanks.
From: EJP on
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?
From: junyoung on
On 4¿ù23ÀÏ, ¿ÀÀü2½Ã52ºÐ, Joshua Cranmer <Pidgeo...(a)verizon.invalid> wrote:
> On 04/22/2010 11:01 AM, cr88192 wrote:
>
> > "EJP"<esmond.not.p...(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

how do you think do use the option -D ( about data.model )

there are two options I can use the first one is -D32 for 32bit data
model. the other one is -D64 for 64bit data model.

I guess this way has to solve this problems.

how do u think?

thanks u always.
From: junyoung on
On 4¿ù23ÀÏ, ¿ÀÈÄ2½Ã01ºÐ, junyoung <juneng...(a)gmail.com> wrote:
> On 4¿ù23ÀÏ, ¿ÀÀü2½Ã52ºÐ, Joshua Cranmer <Pidgeo....(a)verizon.invalid> wrote:
>
>
>
>
>
> > On 04/22/2010 11:01 AM, cr88192 wrote:
>
> > > "EJP"<esmond.not.p...(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
>
> how do you think do use the option -D ( about data.model )
>
> there are two options I can use the first one is -D32 for 32bit data
> model. the other one is -D64 for 64bit data model.
>
> I guess this way has to solve this problems.
>
> how do u think?
>
> thanks u always.

oh, god ;(

$ java -d32
Running a 32-bit JVM is not supported on this platform.
From: Roedy Green on
On Thu, 22 Apr 2010 01:10:39 -0700 (PDT), junyoung
<juneng603(a)gmail.com> wrote, quoted or indirectly quoted someone who
said :

>I have a 64bit jvm now,

It is possible for a C/C++ 64 bit program to call into a 32 bit DLL?

If so, you could write some JNI glue to do the transition.
--
Roedy Green Canadian Mind Products
http://mindprod.com

It�s amazing how much structure natural languages have when you consider who speaks them and how they evolved.