Currently I've got OpenOffice built from source, and this is what I'd prefer 
to use.  Right now, though, /opt/oo/program/setup (compiled from source) is 
segfaulting on one system.  It's apparently not a very reproducible error, 
because the same precompiled setup works just fine on a different system. 
 
The system where setup works is an Athlon running a customized distro 
(pre-release of InceptionOS--http://www.inceptionos.org/).  It carries 512MB 
of RAM (2GB swap) and about 270GB of disk space.  The system where setup fails 
is a P3 running the same O/S (slightly different package set), with a mere 
16GB of hard disk space and 128MB RAM (400MB swap).  Kernel is 2.4.18 with SGI 
XFS and preempt patches.  glibc version is 2.2.5.  XFree86 version is 4.2.0. 
 
OO 1.0.1 was built from source via the instructions at 
http://www.geocities.com/tush/lfs/oo-1.0.1.txt .  Those instructions came 
partly from yours truly, as did much of the "mega patch" mentioned therein 
(I'm sorry, but the OO build process is horribly broken.  Thus why the patch 
was necessary).  OO was compiled with gcc 3.1.1 and optimized with -O2 
-march=i486.  J2SDK 1.4.0 (also compiled form source) was used during the 
build. 
 
On the system where setup works, it works perfectly.  setup pulls up the 
splash screen, goes through the dialog boxes, recognizes J2SDK/J2RE, and 
initializes the user-specific directory.  Afterwards, swriter et al all run 
without any apparent hitch.  On the system where it fails, setup.bin segfaults 
every time.  When I edit the setup wrapper script to run setup.bin through 
gdb, the following message consistently appears in the gdb shell: 
 
<snip a lot of gdb output> 
Program received signal SIGSEGV, Segmentation fault. 
---Type <return> to continue, or q <return> to quit--- 
0x4142d9a5 in psp::JobData::constructFromStreamBuffer(void*, int, 
psp::JobData&) () from ./libpsp641li.so 
 
On the same system, when I try to run setup from the precompiled OpenOffice, 
it pulls up a small progress meter with an image of an open box, starts 
extracting within /tmp, and then dies with the progress bar half-full, 
returning an exit code of 1.  Only 20% of /tmp is filled during this time; 
/tmp is a 256MB partition.  If I try non-interactive setup via the "install" 
script, much the same thing happens--I just don't get the pretty progress 
meter. 
 
Is this possibly a resource shortage?  Regardless of this, setup should do 
more than just say "Segmentation fault" and force me to run it through a 
debugger to find what went wrong.  I'm still trying to figure out why it would 
work on one system and fail on another...