is it possible to call 32 bit shared libraries on 64bit os platforms?

[junyoung]

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.

 

[Nigel Wade]

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 ).

Not that I am aware of.

You will need to install a 32bit JVM and ensure that you run the correct
one (it's perfectly possible to have multiple versions, and
architectures, of the JVM co-exist quite happily on Linux). Normally all
you need to do is run the correct java executable. Download the latest
JRE from Sun/Oracle. Get the non-RPM version which allows you to extract
it anywhere you like. The RPM version will use the package manager to
install it, and will probably replace your existing version.

 

[EJP]

libadscli.so: wrong ELF class: ELFCLASS32 (Possible cause:
architecture word width mismatch)

Bit of a giveaway, don't you think?

 

[cr88192]

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...

 

[RedGrittyBrick]

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/

 

[Joshua Cranmer]

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)!

 

[junyoung]

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.


Or use multilib stuff (ugh)!

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.

 

[junyoung]

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.

 

[Roedy Green]

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.

 

[Arne Vajhøj]

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.

Why should his own DLL be better than the DLL's of the JVM?

Arne