Because of recent updates in slackware-current (in this case, the boost package) the LibreOffice in my own repository stopped working. Library conflict. Don’t you love the life on the bleeding edge 😉
By coïncidence, the Document Foundation had just released a new version of their LibreOffice sources, so instead of recompiling the old 5.4.3 packages I could grab the new 5.4.4 release and turn those sources into Slackware packages (Slackware 14.2 and -current). The next major release 6.0 is just around the corner but I am not going to wait for that.
You can get the new packages from my repository – like https://slackware.nl/people/alien/slackbuilds/libreoffice/ .
Also, I updated the multilib repository with the latest updates in slackware-current (the new l/Mako, a/lzlib and a/plzip are now also available in a “compat32” version).
Remember to also install the new packages, not just upgrade the existing ones! If you have a local mirror, that means using “upgradepkg –install-new” and if you use slackpkg with slackpkg+, you need to do “slackpkg update; slackpkg install multilib ; slackpkg upgrade-all”. That “slackpkg install multilib” takes care of installing any package you are still missing.
Work on a new Plasma5 package set is also well underway. The 64bit -current bit is done so I know I have my sources and scripts in order, and I am generating a new PLASMA5 Live ISO for testing. Stay tuned.
you may want to edit your post.
l – MAKO
a – plzip
error while loading shared libraries: libboost_system.so.1.59.0
hmm… my boost is 1.66.0
after symlinking i have:
soffice.bin: symbol lookup error: /usr/lib64/libreoffice/program/libi18nutil.so: undefined symbol: _ZTVN6…
drakeo indeed 🙂 Fixed.
slackwarevod installed the wrong package? Works here (slackware64-current).
ln -s libboost_filesystem.so libboost_filesystem.so.1.66.0
ln -s libboost_iostreams.so libboost_iostreams.so.1.66.0
ln -s libboost_system.so libboost_system.so.1.66.0
Work, perfectly on current-64 here 😉
Antonio these symlinks should not be necessary with the newest libreoffice package and slackware – current. What did you break on your computer that you have to fiddle with these symlinks?
Note that creating symlinks to removed libraries is not always going to work. If the ABI of the library has changed then creating these symlinks will eventually just crash your application.
Thank you Eric! Works very well here.
Pingback: Links 22/12/2017: Mesa 17.3.1, Wine 3.0 RC3, LLVM 5.0.1 | Techrights
Heh, thanks for the reminder on “slackpkg install multilib.” Happy holidays!
It seems you still have the libva-intel-driver and json-c packages in your current multilib repo which have been removed from slackware.
Also it would be cool to add all the SDL2_* packages that have been added to current.
hadack good catch! I had not been keeping an eye on package removals… will see to that now.
Do you have a purpose for ‘compat32’ versions of these SDL2 packages? Are they required to compile some 32bit package of yours on 64bit Slackware? I had pondered SDL2 packages but could not come up with any 32bit software that needs them in a multilib setup.
Hmm I dont remember exactly, but some of them were needed for a 32 bit game so i converted and installed them. I have them since then, but I haven’t checked what needs them. I guess it is fine to see what needs them and add them if necessary. It just looked like good to have to me.
Sorry. All worked fine!
I downloaded: libreoffice/pkg64/14.2/libreoffice-5.4.4-x86-641alien.txz. The md5 hash given for this package is:
However, when running:
openssl dgst -md5 on it I get:
The hashes don’t match.
Simo check your download against where you downloaded it (and you named the file incorrectly, I assume that that is just a typo).
On my mirror server I get:
root@bear:# md5sum libreoffice/pkg64/14.2/libreoffice-5.4.4-x86_64-1alien.txz
root@bear:# openssl dgst -md5 libreoffice/pkg64/14.2/libreoffice-5.4.4-x86_64-1alien.txz
Tried the site linked to at the top of the page and that copy of libreoffice matches the given md5 hash.
The version that doesn’t match came from: http(COLON SLASH SLASH)www(DOT)slackware(DOT)com/~alien/
This is the first time this has happened. Like the new LibreOffice more than the old. Usually, adding more bells and whistles adds nothing. This time, lots of convenience tool buttons so you’re not going back and forth between submenus and your documents.
Simo, the md5sum of that file on slackware.com/~alien is is identical to that on the other server;
alien@connie:~$ md5sum libreoffice/pkg64/14.2/libreoffice-5.4.4-x86_64-1alien.txz
Again, check how you downloaded it.
For some reason, slack version of libreoffice works *much!* slower than the vanila one (rpm2txz), esspecially on the large spreadsheets. Anyone faced with that problem?
Vanila LibreOffice is working muck faster, but is using (one core) CPU 100% all the time 🙁
What about LO v6.0? I was astonished with the speed it worked on Win10. At least how fast it started – hard to say whether calc multiplies 2 by 3 faster.
When I have time…
it seems as if yesterday’s upgrade to llvm-7.0.0 in -current interfere if one has yor multilib package llvm-compat32-6.0.1 installed as well (see https://www.linuxquestions.org/questions/slackware-14/sbo-scripts-not-building-on-current-read-1st-post-pls-4175561999/page94.html#post5906547
Guess thos can be solved if you can build a 7.0.0 multilib package – when you can find the time…
KG Hammarlund – one can easily generate this package without having to wait for me to refresh the multilib repository, like orbea already explains in that same thread.
The pace of -current is erratic so I will often be out of sync with these ‘compat32’ packages.
Thanks, Eric – generating a new package with convertpkg-compat32 went smoothly and the build problem reported by Melke on LQ was eliminated.