i386 jdk and lib32

[Peter Wemm]

On Thursday 25 March 2004 01:51 am, Tony Maher wrote:
> Hello
>
> I ran Peter Wemm's build32.sh script and tested with ksh93 package
> built on an i386 box.  All worked well.
>
> Encouraged I created jdk1.3 on i386 machine and installed on amd64
> box. Trying to run any of the java binaries resulted in
> (paraphrasing) /libexec/ld-elf.so.1 cannot load (find) libhpi.so
>
> Could not understand why it was ld-elf.so.1 and not ld-elf32.so.1
> but ktrace/kdump showed ld-elf32.so.1 was tried first and failed and
> then ld-elf.so.1 was tried and produced the message.  ktrace also
> showed it was looking in /lib32 (or /usr/lib32). (reading build32.sh
> explained why this is). So I added symlinks in /lib32 to the java
> libs and got further. Was getting  (from memory)
> Cannot open /greenthreads/libhpi.so
>
> Thats as far as I got before going home.  I'll look further tomorrow.
>
> (Obviously?) what would be better is to be able to create
> /var/run/ld32.so.hints (is that correct name?) rather than symlink
> hack. Is this possible (without a lot of work)?
>
> (Also obviously?!) it looks like LD_LIBRARY_PATH is ignored for 32
> bit i386 which is why no libraries are found.  Any ideas about this?

The information you're probably missing is that there are a couple of 
extra environment variables and ldconfig can create the ld32.so.hints 
file for you.  What you probably need is to set $LD_32_LIBRARY_PATH
and/or use ldconfig -32 to set the search paths for your other 32 bit 
libraries.

I suspect the java wrappers are setting $LD_LIBRARY_PATH.

(I'd originally used $LD32_ as the prefix, but there are security checks 
when scrubbing the environment that specifically look for "LD_" as a 
prefix.  If you run setuid, or copy the environment via login -f, then 
it needs to remove the environment variables).
-- 
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5