i386 jdk and lib32

[Peter Wemm]

On Thursday 25 March 2004 04:19 pm, tonymaher at optusnet.com.au wrote:
> > Peter Wemm <peter at wemm.org> wrote:
> >
> > On Thursday 25 March 2004 01:51 am, Tony Maher wrote:
> > > (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).
>
> Thanks Peter. Setting LD_32_LIBRARY_PATH in wrapper worked perfectly.
> (forgot to mention yesterday that  wrapper also need "proc=i386" so
> it could find directories correctly).
>
> However trying to run executables uncovered another problem:
> /usr/local/jdk1.3.1/bin/java
> SIGSYS    12*  bad argument to system call
>
> Full thread dump Classic VM (1.3.1-p9-root-040325-17:07, green
> threads): "Finalizer" (TID:0x28eb3528, sys_thread_t:0x80d4080,
> state:CW) prio=8 at java.lang.Object.wait(Native Method)
>         ...
>         ...
>
> Relevant ktrace/kdump output is:
>
>  56058 java     NAMI  "/usr/local/jdk1.3.1/jre/lib/ext"
>  56058 java     RET   open 4
>  56058 java     CALL  fstat(0x4,0xffffc8b8)
>  56058 java     RET   fstat 0
>  56058 java     CALL  fcntl(0x4,0x2,0x1)
>  56058 java     RET   fcntl 0
>  56058 java     CALL  fstatfs
>  56058 java     RET   fstatfs -1 errno 78 Function not implemented
>  56058 java     PSIG  SIGSYS caught handler=0x2807c868 mask=0x0
> code=0x0 56058 java     CALL  write(0x2,0xffffbbe0,0x2b)
>  56058 java     GIO   fd 2 wrote 43 bytes
>        "SIGSYS    12*  bad argument to system call
>        "
>  56058 java     RET   write 43/0x2b
>  56058 java     CALL  break(0x8141000)
>
>
> We have reduced the problem to the folowing C program:
>
> #include <stdio.h>
> #include <sys/param.h>
> #include <sys/mount.h>
> #include <sys/errno.h>
>
> int main(int argc, char** argv)
> {
>         struct statfs buf;
>
>         if (fstatfs(0, &buf) < 0)
>                 perror("fstatfs");
>
>         return 0;
> }
>
> This works fine if natively compiled and run on amd64 and i386
> respectively. But the i386 binary on amd64 core dumps.
>
> file ~/test-i386
> /home/tonym/test-i386: ELF 32-bit LSB executable, Intel 80386,
> version 1 (FreeBSD), for FreeBSD 5.0.2, dynamically linked (uses
> shared libs), not stripped
>
>  ~/test-i386
> Bad system call (core dumped)
>
> Is this a lost cause (in the short term)?

I can fix this pretty quickly.  The problem is that somebody changed the 
statfs structures and the compat syscall table wasn't updated.  I'll 
take a shot at it tonight unless somebody beats me to it.

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