On Wed, Nov 14, 2001 at 10:46:10AM +0200, Martti Kuparinen wrote:
> >> I'm trying to install StarOffice 6.0 beta on my NetBSD/i386
> >> 1.5.3_ALPHA laptop. The setup.bin program dumps core with
> >> the following output:
> >
> > Add 'ktrace -t cenis' at the second last line in soffice (the else 
> > branch in the shell script you start) after the exec, so the line should 
> 
> I started the installation, copied /tmp/sv* to /tmp/so6/ and cancelled
> the installation, then restarted setup from /tmp/so6. There isn't any
> problem in finding the libs as reported by gdb. Here's the result from
> ktrace+kdump:

OK, at least that's fine. 

> ...
>    770 setup.bin CALL  gettimeofday(0xbfbfcecc,0)
>    770 setup.bin RET   gettimeofday 0
>    770 setup.bin CALL  sched_yield
>    770 setup.bin RET   sched_yield 0
>    770 setup.bin CALL  select(0x6,0xbfbfcf5c,0,0xbfbfcedc,0xbfbfcecc)
>    770 setup.bin RET   select 0
>    770 setup.bin CALL  rt_sigprocmask(0x2,0,0xbfbfccdc,0x8)
>    770 setup.bin RET   rt_sigprocmask 0
>    770 setup.bin CALL  rt_sigsuspend(0xbfbfccdc,0x8)
>    770 setup.bin PSIG  SIGSEGV SIG_DFL
>    770 setup.bin NAMI  "setup.bin.core"
> 
> Is it crashing in rt_sigsuspend or how should this be interpreted?

No, that's also fine. The rt_* functions are called because of the 
SIGSEGV, the last 'real' system call is select, and that exits without 
visuable problems. I had hoped for signs of "Unimplemented system call", a 
system call returning with an error code or something similar, but that 
looks more like a plain segfault.

> I looked at the README file (when nothing helps you read the docs :-)
> and found this:
> 
> 	System requirements:
> 	- Linux Kernel version 2.2.13 or higher
> 	- glibc2 version 2.1.2 or higher

Could be, but I'm only guessing. But I remember about problems running OO 
with a glibc 2.0 where the binary was compiled with glibc 2.1 on Linux PPC. 
I think it was a rather spurious error (could have been a segfault), I just 
can't find it in the archives of porting@openoffice.org right now. 

Alternatively you could try to run OO with gdb to find out the function 
where it segfaults. But then I wouldn't know what to do afterwards. 


HTH

Michael