Super Linux Expert Help Required!

General Discussions
#1

I’ve got a 32-bit JDK here on this 'ere Linux box. Unfortunately it’s a 64-bit Linux. Consequently it doesn’t recognise java as an executable it can launch.

No problem you say, sudo apt-get install ia32-libs.

That’s not what I want to do!

I want a 32-bit JDK with all the appropriate 32-bit compatibility libraries already in it so it “just works” on a 64-bit system without having to install any other packages. I’ve tried copying a bunch of the aforementioned 32-bit compat libraries to the JRE lib/i386 library and now I’m at the stage of getting a Segmentation Fault but no actual useful output (I don’t even know where the segfault is going).

Any takers?

Cas :slight_smile:

#2

What you’re looking for basically is static linking. I don’t think modern glibc can be 100% statically linked – libnss for one thing will always demand to be dynamically loaded.

#3

What I’m looking for involves not actually doing any static linking - I just want to get the collection of libraries that ia32-libs provides and bung them along with my JVM so it works. Which it does do, if you just do a sudo apt-get install ia32-libs; so clearly the theory behind it is sound, it’s just the niggly details which elude me.

Cas :slight_smile:

#4

Ia32-libs appears to actually contain the linker required to load a 32 bit library if I understand correctly. The os probably can’t find it, which is causing your problem. You’re gonna have to install. Ia32- libs also seems to be outdated in favor of multiarch packages.

#5

If you export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH in a launch script, it should work.

There are other ways to manipulate the library search path, as well, but, if you’re already using a launch script, this is probably the simplest thing to try.

#6

Indeed, ia32-libs actually is empty, it just goes off and gets some other packages; the end result is a bunch of libraries that get shoved somewhere which I’ve gone and dug up. One of these libraries is a 32-bit capable ld.so, which can be used to load 32-bit executables, eg:


$ ./lib/i386/ld.so ./bin/java

(with a bunch of extra parameters) and I’ve got that to the get to the point where it just segfaults instead of complains about missing libjava.so and libjvm.so.

It seems that setting LD_LIBRARY_PATH isn’t helping. I think it’s picking up the libraries but it’s segfaulting and I can’t seem to get any further information.

Cas :slight_smile:

#7

More than what I’d call a “bunch of files”. /usr/lib/i366-linux-gnu on this machine is 203M. Of course, that includes some things that java doesn’t need.

A quick check shows that java needs at least:

libpthread.so.0
libc.so.6
libdl.so.2

However, there are plenty of libs that are potentially pulled in later by the jre via dlopen() (in lib/i386), so if anything you’re using in java requires one or more of them, you’ll need those, as well.

I downloaded lwjgl-2.8.5 for a quick peek there, and it adds (again, not including anything pulled in via dlopen()):

libX11.so.6
libXext.so.6
libXcursor.so.1
libXrandr.so.2
libxcb.so.1
libXrender.so.1
libXfixes.so.3
libXau.so.6
libXdmcp.so.6
librt.so.1
libm.so.6

I don’t have time right now to look further, I need to leave the house shortly - perhaps later tonight or tomorrow I can dig a bit deeper. Do you have a particular program that you want to have working? Or is it giving you SIGSEGV on even “java -version”?

To get more info on the fault, you could run via gdb. Even without debug symbols, you’d at least get a stack trace that way, which might point toward the problem.

eg:

gdb ./bin/java
(gdb) run -version

replace “-version” with whatever you need – “-jar agame.jar” or whatever.

I’ll at least check in this evening my time (CST - I’m in Minnesota, USA).

I assume your evil plan is to put together a tarball style install package that will run on either 32bit or 64bit machines w/o extra deps, in an attempt to make a tarball install as easy to use as a .deb or .rpm, yes?

#8

It seems that all you need is the correct version of java (64 bit version) what Linux distribution are you using? Ubuntu? Mint? Fedora? If your on an RPM based distribution like Fedora, then Oracle provides a 64 bit version as an .rpm. If you are an a DEB system like Ubuntu or Mint, then you have to do it the long way and extract and set up the tar.gz yourself. Which isn’t really that hard, but may be confusing for n00bs. Here is a good walk through if your on DEB.

https://sites.google.com/site/easylinuxtipsproject/java

#9

I found a little time tonight to look at this further.

After getting a fresh Ubuntu 64 bit install set up in a VM, I extracted the 32bit jre1.7.0_11 in ~/Downloads.

I was eventually able to get a hello world program to run w/o issues with the following setup:

Created ~/Downloads/jre1.7.0_11/bin/lib32, containing:

ld-2.15.so
ld-linux.so.2 (symlink to ld-2.15.so)
libc-2.15.so
libc.so.6 (symlink to libc-2.15.so)
libdl-2.15.so
libdl.so.2 (symlink to libdl-2.15.so)
libm-2.15.so
libm.so.6 (symlink to libm-2.15.so)
libpthread-2.15.so
libpthread.so.0 (symlink to libpthread-2.15.so)

I had placed Hello.jar up in ~/Downloads.

Then, sitting in ~/Downloads, I was able to run a simple hello world via:

LD_LIBRARY_PATH=jre1.7.0_11/bin/lib32 jre1.7.0_11/bin/lib32/ld-linux.so.2 jre1.7.0_11/bin/java -cp Hello.jar com.hexomancy.Hello

I was unable to get it to work properly with lib32 sitting anywhere else but in $JRE_DIR/bin, though it’s not occurring to me just now why that might be. I’ve got a doozy of a week coming up, but perhaps I’ll find time to look into it further.

A more complex executable would require additional libs in lib32, of course. Some of the libs in question are likely GPL, with the minor PITA that distributing GPL libs entails.

Also, since the whole set is, as I mentioned, not small, you’d probably want to figure out just what you need. The list in my previous response would be a start, and the rest could be found via some combination of ltrace and just running to see what the loader complains about.

Hope some of this is helpful!

#10

That’s looking promising; but I wonder maybe if I’m beating down the wrong path - perhaps I should simply be including both 64 and 32 bit JVMs in the distribution, but sharing a common rt.jar (which is after all the bulk of it)

Cas :slight_smile:

#11

that would probably be the best, most robust idea. you could just symlink to rt.jar wherever you decide to put it.

#12

If there are no gotchas (and I can’t think of any right off), that would certainly be a heck of a lot simpler, and much less brittle.

Not that I’m telling you anything you’re not already more than versed in, but there is the niggling matter of whether a symlink to rt.jar in another directory meets Oracle’s redistribution requirements.

I would think so, especially given the direction they’re taking in Java 8 and with JavaFX 2, but with lawyers, you never know.

#13

It would seem that that was exactly the best thing to do; the only caveat is that there are a few classes in rt.jar that are arch-specific. What I’ve done then is split out rt.jar into rt32.jar and rt64.jar and the common ones in rt.jar, and then I fire up my VM using -Xbootclasspath/p:rt{32|64}.jar - presto! Obviously the total install size is a few megs bigger but meh.

Screw the licensing requirements, the code’s all there, just muddled up a bit :slight_smile:

Cas :slight_smile: