<rant> After three compilation failures (each setting me back several hours) I must say this:
Whenever I have to bump a LibreOffice package – and perhaps due to moving up from Slackware 14.0 to 14.1 for compiling – it annoys the hell out of me that there are so many unexpected build failures. Not because I cannot fix them, but because every iteration of a LibreOffice compilation attempt costs another few hours. And there’s only so many hours between coming home from work and falling over because of sleep deprivation.
I am afraid that it will take some time before I can produce proper LibreOffice 4.2.0 packages for you. They will be available for Slackware 14.1 and newer . If you are running Slackware 14.0 then you’ll have to stick with LibreOffice 4.1.x (32-bit, 64-bit) for which I will build new packages soon (4.1.5 is around the corner). Users of Slackware 13.37 can still enjoy LibreOffice 3.6.7 (32-bit,64-bit).
In the meantime I am baking a fresh bread for tomorrow morning, so that I get at least something useful out of this frustrating evening.
Eric
Perhaps it time to take a look at Open Office again?
slackbuilds.org, edit libreoffice.Slackbuild (4.1.3 ~~> 4.2.0).
Done =]
Sometimes it happens that I undertake a project, and if there are too many failures leading me nowhere, I have to ask myself: is it really worth the hassle? If I was in your position, I’d simply repackage the prebuilt binaries. One has to wonder: what is it with these office suite developers? Even with the binaries, they can’t help but breaking naming schemes even between minor version bumps.
You probably already know that sort of solution, but in the past, when building big things like KDE, I’ve been using a combination of Distcc and CCache (http://www.microlinux.fr/slackware/Linux-HOWTOs/Distcc-HOWTO.txt). A distributed build on four or five machines can be quite fast. Plus, in the winter, you can turn off the heater in the office. Another alternate solution is to purchase a workstation similar to the monster one of my clients (the oceanographic institue in Brest) is using: 24 CPUs with 32 GB RAM. :o)
Hello,
maybe You could try to build Apache OO?
I would like to try it and check if its stability is better for production use than LO. I did compiled few times aoo on slackware64-current, but when I run it there were some problems with dbus.
I know about distcc and I use it when compiling for ARM. However I only have one big machine, and that is the server where I compile my x86 packages already, so distcc is not an option here.
Going with the binary pre-built stuff from libreoffice.org is going against my principles that I only use binaries if there are no sources to compile. In case of LibreOffice, the vendor binaries have been compiled to work on as many systems as possible, therefore they are not optimal binaries for Slackware.
Eric
hi
No, I will not be building packages for Apache OpenOffice.
Eric
Thank you for your patience. Your LO packages are definitely appreciated by myself. Are the LO developers aware of what a pain it is to build?
Is it such a pain in debian based distros. Since you are a senior ninja master slacker and even you have problems it must be a real pain.
Twice now, the compilation process managed to fill my 40 GB filesystem (which I use for compiling programs in the virtual machine) to the max. What kind of crazy software creep is inside of libreoffice 4.2.0 ?
I have enlarged my VM disk image and hope it is sufficient. At least the errors are caused by insufficient disk space and not by changed configuration parameters… this I can fix.
Well, looking at the feature page (https://www.libreoffice.org/download/4-2-new-features-and-fixes/) will give you hint that there ARE many new features and i believe the developer added MANY more internal packages in it. But still it’s unbelieveable that 40 GB is not enough to build a single LO package…
Finally the sources compiled cleanly, and that took 47 GB of space…
There was an issue with some files that are no longer present, which triggered a script abortion (due to a chmod command that failed), and that means I have to wait another 10 hours for my VM to compile a new set of 64-bit packages.
At least it enabled me to add “–enable-extra-fonts” in the assumption that this will add Google’s Carlito and Caladea fonts (free replacements for MS fonts) to the package.
The Carlito font is metrically compatible with the current MS default font “Calibri”. The Caladea font does the same for Microsoft’s “Cambria” font. Identical metrics means that you can use these fonts when rendering MS Office documents in LibreOffice and the document layout will not change. Even if the fonts don’t look the same, they take up the same space on the page.
Eric
Hi,
Eric, could you list the error ?
I’m asking because I’m having a very annoying time trying to compile PHP 5.5 on Slackware 14.1 and I’m wondering if it could be the same error.
Apparently is something related to the new GCC 4.8.2, the new glibc or both.
It’s the error from config.log after a “./configure —disable-all” at the PHP 5.5.8 source package:
configure:85972: checking for extended DES crypt
configure:86002: cc -o conftest -g -O2 -fvisibility=hidden conftest.c -lcrypt -lrt -lm -ldl -lnsl -lcrypt >&5
conftest.c: In function ‘main’:
conftest.c:241:3: warning: incompatible implicit declaration of built-in function ‘exit’ [enabled by default]
exit (strcmp((char *)crypt(“rasmuslerdorf”,”_J9..rasm”),”_J9..rasmBYk8r9AiWNc”));
^
configure:86002: $? = 0
configure:86002: ./conftest
./configure: line 2347: 15404 Segmentation fault ./conftest$ac_exeext
and
configure:86019: checking for MD5 crypt
configure:86058: cc -o conftest -g -O2 -fvisibility=hidden conftest.c -lcrypt -lrt –
lm -ldl -lnsl -lcrypt >&5
conftest.c: In function ‘main’:
conftest.c:248:5: warning: incompatible implicit declaration of built-in function ‘str
cpy’ [enabled by default]
strcpy(answer,salt);
^
conftest.c:249:5: warning: incompatible implicit declaration of built-in function ‘str
cat’ [enabled by default]
strcat(answer,”rISCgZzpwk3UhDidwXvin0″);
^
conftest.c:250:5: warning: incompatible implicit declaration of built-in function ‘exi
t’ [enabled by default]
exit (strcmp((char *)crypt(“rasmuslerdorf”,salt),answer));
^
And the dmesg:
[93378.783637] conftest[15404]: segfault at 0 ip 00000000004005b0 sp 00007fffb9b15dc0 error 4 in conftest[400000+1000]
[93378.934037] conftest[15427]: segfault at 0 ip 00007f35d72e2ff6 sp 00007fffcefb0b38 error 4 in libc-2.17.so[7f35d71ad000+1bf000]
Jero
Hi Jeronimo
Looks like my LibreOffice compilation issues have nothing do do with your issue.
Eric
I really appreciate your patience and effort. Thank you Eric!
I finally compiled some libreoffice-4.2.0 packages and will upload those shortly…
Give them a try and let me know. At least the programs start and seem to work okay.
Eric
Great news! Will wait for those. Thanks again Eric.
Hello,
it seems that there are problems with this new version. This
http://www.cgedd.fr/prix-immobilier-friggit.doc
cannot be seen correctly, by your build of libreoffice and also by the official build. But it works with openoffice and calligra.
Hi Alien BOB,
today, my script saw that there were new libreoffice packages on the slackware.org.uk mirror, so I upgraded them with it and have been using them without a problem so far.
Thanks for all the hard work you put into this!
lems
Hi Eric
LO seems to work OK here
Big thanks
Eddy
once when i was waiting for libreoffice to start i measured the time – 9 sec. 25 years ago i waited the same amount of time to start wordstar from a floppy disk! great. so i searched for an alternative and – as tex is a huge package – i gave groff a try. to make it short – i write all my letters with groff now, and i wont touch libre-/openoffice again. there are macro packages (mom), which makes this taks easy.
libreoffice is in fact windows software – huge, bloated, has a huge amount of functionality and it uses a binary file format format. so maybe the solution to our problem is to dismiss libreoffice and switch from “word processing” to “text processing” by using groff or tex. This is actually a return to the unix philosophy.