Re: fatal error in SO 5.1
Brad wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> On Mon, 4 Oct 1999, Ed Cogburn wrote:
>
> > "Damir J. Naden" wrote:
> > >
> > > Hi Brad; unless Mutt is confused, you wrote:
> > > >
> > > > Except for the problems with threaded system(3) calls in ove of the glibc
> > > > 2.1.2 prereleases, all the solutions you mention solve problems for
> > > > StarOffice 5.01 (which had problems with glibc 2.1), not StarOffice 5.1.
> >
> > There may have been problems with earlier versions of SO, I only showed
> > up for 5.1, however there *were* glibc2.1 problems for SO 5.1.
>
> 1) Are you sure 5.1, and not 5.01? This seems to cause some confusion.
It was 5.1 from stardivision.com before being bought out by Sun.
> 2) Are you _sure_ is wasn't the problem with threaded system(3) calls in
> one of the 2.1.2 prereleases? Given the information you give below, it
> distinctly sounds like you ran into this bug and not a bug in SO 5.1.
>
> Especially since i have SO 5.1 from StarDivision before Sun bought
> them, and it works fine (although it is a memory hog...)
I don't know the details about the system(3) call problem. Your last
sentence here is very different from my experience. See below.
>
> > The first version I downloaded from the Star Division web site failed
> > after an upgrade of glibc2.1 of the potato distribution. I made an
> > attempt to have both glibc2.07 and glibc2.1 on the system to get SO to
> > work, but the instructions failed for me. For me the solution was
> > "solved" (not exactly sure) when I downloaded the new SO tarball
> > (so51a_lnx_01.tar, note the "a") from Sun's website (stardivision.com
> > will now redirect to sun.com). This one worked without problems with
> > glibc2.1.x. There were however later upgrades to glibc in that time,
> > but I think it wasn't glibc, they did something with the new version
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Why? Circumstances point more towards the glibc problem mentioned above.
Ok, let me try to explain my experience. I've been upgrading against
potato since its beginning. When glibc was 2.0.x I downloaded SO5.1
from stardivision.com (before Sun). I installed it and it worked. As
the weeks went by I upgraded my potato sys several times a week. When
the glibc version went to 2.1.x, SO broke. A message on deb.usr gave a
list of instructions to try, but the instructions failed for me. I left
SO broke, waiting for a solution, either an update to glibc (2.1), or a
message on deb.usr explaining how to fix it. No message showed up, and
after several subsequent upgrades of glibc2.1.x, SO remained broke. At
this point Sun had taken Stardivision over, and put SO
(so51a_lnx_01.tar) up on sun.com for download. I thought this may be an
updated version (same name as early version but with the addition of the
"a"). I downloaded it, installed it, and it worked.
The above experience lead me to believe the newer SO version solved the
problem. Of course, it goes without saying that I'm probably wrong,
thats why I put the word 'solved' in quotes in my original message.
>
> > of SO to solve the problem.
> >
>
> [[[ SNIP ]]]
>
> > With glibc2.0.x, the original tarball from stardivision.com would work
> > fine, but that version only works for systems with glibc2.0.x. Those
> > who have upgraded to glibc2.1 either have to modify their system (and
> > install two versions of glibc), or download the newer tarball from Sun.
>
> Wrong by proof to the contrary. i have the StarDivision tarball for 5.1
> installed and working fine with the latest potato glibc (version 2.1.2-5).
> The ldd command indicates that it is using the Debian installed glibc 2.1
> libraries.
>
> $ ldd /usr/local/staroffice51/bin/soffice.bin
> *random StarOffice libs*
> libdl.so.2 => /lib/libdl.so.2 (0x4001b000)
> libpthread.so.0 => /lib/libpthread.so.0 (0x4001f000)
> libm.so.6 => /lib/libm.so.6 (0x40031000)
> libc.so.6 => /lib/libc.so.6 (0x4004e000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
> $ ls -o /lib/libc.so.6
> lrwxrwxrwx 1 root 13 Sep 28 16:12 /lib/libc.so.6 -> libc-2.1.2.so
>
> Note that if LD_LIBRARY_PATH or other methods were used to load glibc 2.0
> libraries at runtime, any StarOffice function that uses the system(3) call
> (e.g. printing) would fail due to /bin/sh requiring glibc 2.1. Only by
> changing the dynamic links within the StarOffice binary to point to
> renamed glibc 2.0 libs can this be avoided, but then the ldd output would
> show those changed names instead of the standard ones.
Your probably right. I deleted the original tarball after getting the
updated version, so some recent update to glibc2.1.x may have solved the
problem, before the new version of SO was out. Once I had the new
version downloaded, I never stopped to check if the old version would
now work or not. I assumed it was still broke, so I wiped it and
installed the new SO version, which did work.
--
Ed C.
Reply to: