Drat…
Today, uploaded a set of updated packages of libreoffice-3.3.1 for the 64bit Slackware platform. The packages that I had originally made available were sub-optimal.
What happened? When I compiled libreoffice 3.3.1 earlier this week I used two separate (virtual) machines for that, one running 32bit Slackware and the other 64bit Slackware. Somehow I was not paying attention when I copied the results back into my repository and the correct 64bit packages were overwritten by a flawed attempt of a day earlier.
The packages (version “1alien“) that I originally had in the 64bit repository did not include many of the extensions that should have been bundled (the pdf-import, mysql-connector and report-builder modules for instance) and they did not have a working dictionary install routine either.
The updated 64bit packages (version “2alien“) are the good ones. They contain all the extensions, and several dictionaries in the language packs just like the 32bit packages already had. I advise you to upgrade to these versions of libreoffice-3.3.1 for Slackware64! Note that the 32bit packages were alright from the beginning – they do not need an update.
Eric
PS: This is what my Extensions Manager shows now:
Hi Eric,
thanks for all the work you’re doing. I just wanted to ask whether you have any insight into the ominous libz.so crash that some people seem to have. I have installed libreoffice-3.3.1 for i486 on a single-cpu machine and it runs fine. However, libreoffice-3.3.1 for x86_64 with multilibs installed crashes during startup with a java error that indicates a seg fault in libz.so. I checked the installation and found libz.so.1.2.5 in two packages: aaa_elflibs and zlib. Any idea?
Thanks,
Martin
Hi Martin
No idea what is happening there… I do not run a multilib system myself, strange as it may sound. But I will see that I get a multilib system installed by the time I have to create libreoffice 3.3.2 packages.
Eric
Well, I didn’t want it to sound as if I suspected the multilibs. That bit was only for info. 😉 Searching on the web I cannot find many clues. I’ve done an strace, the interesting part is:
24173 stat(“/usr/lib64/libreoffice/basis3.3/help/idxcaption.xsl”, {st_mode=S_IFREG|0444, st_size=1180, …}) = 0
24173 stat(“/usr/lib64/libreoffice/basis3.3/help/idxcaption.xsl”, {st_mode=S_IFREG|0444, st_size=1180, …}) = 0
24173 stat(“/usr/lib64/libreoffice/basis3.3/help/idxcaption.xsl”, {st_mode=S_IFREG|0444, st_size=1180, …}) = 0
24173 open(“/usr/lib64/libreoffice/basis3.3/help/idxcaption.xsl”, O_RDONLY) = 71
24173 lseek(71, 0, SEEK_CUR) = 0
24173 — SIGSEGV (Segmentation fault) @ 0 (0) —
I looked at the file but cannot detect anything unusual. I reckon it’s a red herring and the cpu did something completely different by the time the segfault hit.
Anyway, good night for now,
Martin
it seems to be a zlib internal error. I have file a bug report with zlib.
Martin
turns out it is an external zlib function. I’ve created a bugzilla entry for LibreOffice:
https://bugs.freedesktop.org/show_bug.cgi?id=35723
just for the records, it turned out the upgrading the JRE from 6.0_23 to 6.0_24 solved the issue. The bugzilla ticket has been closed.