Date: Thu, 25 Mar 2004 19:59:01 -0800 From: Peter Wemm <peter@wemm.org> To: tonymaher@optusnet.com.au Cc: "freebsd-amd64 @ freebsd . org" <freebsd-amd64@freebsd.org> Subject: Re: i386 jdk and lib32 Message-ID: <200403251959.01193.peter@wemm.org> In-Reply-To: <200403260019.i2Q0Jow26161@mail016.syd.optusnet.com.au> References: <200403260019.i2Q0Jow26161@mail016.syd.optusnet.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 25 March 2004 04:19 pm, tonymaher@optusnet.com.au wrote:
> > Peter Wemm <peter@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@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200403251959.01193.peter>