Compiling libreoffice
I've always failed to compile libreoffice, LO, with alienbob's libreoffice.SlackBuild.
I can compile LO Using a cut down version of Christoph Willing SlackBuild I can also compile LO from a git clone that I use for chasing regression bugs. Do the odd fix now and again. However, alienbob's SlackBuild is beyond me. My environment is a virtualbox client with an up to date 14.2 with multilib. I also have a number of packages installed from SlackBuilds including qt5. I've amended alienbob's Slackbuild to explicitly exlude qt5. It get's so far, but then hangs for hours at - Code:
[build PKG] redland until I kill it. top shows me this - Code:
top - 11:23:18 up 3:09, 4 users, load average: 5.10, 5.03, 5.02 How can I ascertain what the problem is? I normally create libreoffice using the Willy Sudiarto Raharjo SlackBuild which is not compiling but conversion of the rpms I know I can just download alienbob's binary packages, but I just have this itch to compile with alienbob's SlackBuild. Might learn something! Alex |
You might get some hints/clues from this thread:
https://www.linuxquestions.org/quest...nt-4175589127/ Here is where I finally got it: https://www.linuxquestions.org/quest...ml#post5609059 Ignore the link to my build log, it is no longer valid. |
I elected to concentrate on LO 6.2.0.3
The problem with the compiler hanging may have been something to do with the extra sources. So I completely changed all the extra sources in alienbob's libreoffice.Slackbuild with those listed in the 6.2.0.3 version of download.lst Whatever happened to alienbob's gensrc.sh? I then got a series of failures - Quote:
In libreoffice.SlackBuild I removed the --enable-ext-wiki-publisher flag from autogen.sh Then got this error Quote:
In libreoffice.SlackBuild I removed the --enable-ext-nlpsolver flag from autogen.sh Then got this error Quote:
I was now on a bit more familiar territory, In that this shouldn't be happening if I was actually using the external source harfbuzz-1.8.4.tar.bz2. The error message seemed to be suggesting that I was somehow using one of the system packages harfbuzz-1.2.7-x86_64-1 or harfbuzz-compat32-1.2.7-x86_64-1compat32. A quick email exchange with the LO developers, who asked me to run Code:
make PARALLELISM=1 verbose=t Code:
that a -L/usr/lib64 is your problem; it is pointless (because that is in the default search path anyway) and harmful (because it overrides the -L$W/UnpackedTarball/harfbuzz/src/.libs that comes later: Quote:
Quote:
After a bit of investigation I hashed out what I considered to be the problem code in libreoffice.slackbuild. I'm on a 64-bit box. Quote:
So what don't I understand with alienbob's libreoffice.SlackBuild I downloaded using lftp -c "open http://www.slackware.com/~alien/slac.../libreoffice/; mirror build" in the downloaded libreoffice.SlackBuild I changed
but still had to make this change Quote:
|
Quote:
|
Silly question: Why are you compiling something that large in the first place, unless of course you just enjoy it or are doing it for educational purposes?
Installiing LibreOffice on Slackware is easy. Just download the RPMs (program and help files), extract them, run rpm2tgz on all RPM files, then use installpkg to put them in /opt/LibreOffice6. Takes 5 minutes, and I've never had a failure doing this with any LO version. I recompress them into a new LibreOffice6.Slackware64.tar.gz file so I can just install it on all my Slackware boxes. Multilib is not necessary, but it shouldn't be an issue, either. |
Quote:
Quote:
|
Quote:
I should have also have said that I've raised a dozen or more bug reports for libreoffice. Have a LO git clone that I've kept up to date over the years, compiles successfully, used to submit patches to fix regressions. On my production machines I've historically used the Willy Sudiarto Raharjo packages as they're quick to install. However, we seem to be heading into uncharted territory. The autogen in my git clone now
As a result I've had to move my LO git clone to 14.2+ with alienbob's ktown. So now need a neat way to package LO so I can move it around my test boxes. Alienbob's seems to be the best candidate to do this as it mentions sourcing the code from git. Unfortunately with alienbob's script I seem to invariably fail. Have to hack things to get a success compile, now's there a suggestion that there may be a problem with compiling LO in a multilib environment - which I find a worrying. All the 188 downloads from SlackBuild.org I have compiled on a multilib platform - so are all these suspect, they don't seem to be causing me a problem and all compile successfully. Should I have compiled them on a pure 64-bit machine? I always seem to succeed when using the Chris Willing LO SlackBuild. Alex |
Quote:
Had several goes at reverting the clone back to a non-multilib evironment. In the end the only method that seemed to work was the slackpkg route and even then I had to reinstall curl and mariadb. Anyway with Code:
SLKLDFLAGS="-L/usr/lib64"; LIBDIRSUFFIX="64" Quote:
with Code:
SLKLDFLAGS=""; LIBDIRSUFFIX="" the build was successful Quote:
|
@aikempshall
maybe you could rename /usr/lib to /usr/lib0 while you compile libreoffice, run ldconfig, compile, and after that restore /usr/lib ? |
After getting a successful compile of libreoffice (6.2.0) with alienbob's libreoffice.SlackBuild on Slackware 14.2 with kde4, qt(qt4) and qt5.
I did some testing - My forms in base - work My connection to MariaDB - works Those macros I use on a weekly and monthly basis - work. Couldn't find anything wrong. So I'm happy to say that I can now compile libreoffice with alienbob's libreoffice.SlackBuild. So I have a bit of portability. I then decided to try compiling on 14.2+ with alienbob's libreoffice.SlackBuild. Modified to reflect this was on a kde5 environment with AlienBob's ktown. It still had the qt(qt4) and qt5 packages installed. Tried every which way top get a successful compile. The flags I was using, among others, where Code:
--disable-kde4 Quote:
All this was done on a VirtualBox client. So I decided to clone the client and remove qt(qt4) which just left qt5. The LO compile using alienbob's libreoffice.SlackBuild was successful. Removing qt4 broke keepassx, qt-creator, qbs, and Scribus and probably others as well. I've since compiled qt-creator and qbs in this now qt4 free environment they seem stand up. I had to switch to keepassxc as keepassx seems to need qt4. Not tried to compile Scribus. Stood up LO 6.2.0 successfully. Very limited testing showed that a regression bug had crept in in that copying in LO and pasting out of LO wasn't working. Someone else had already reported this see https://bugs.documentfoundation.org/....cgi?id=122689. Just a kde5 LO integration bug. So I compiled LO 6.2.1 just to prove that the regression has been fixed and that it wasn't anything I'd done in removing qt4. I successfully compiled LO 6.2.1 using alienbob's SlackBuild on my 14.2+ environment with just the qt5 package. The qt(qt4) package had been removed. The regression bug had been fixed. I've not done any other testing, but it looks promising. |
I forgot to say the itch has gone away. I've learnt a lot.
|
After getting a successful compile of libreoffice (6.2.1) with alienbob's libreoffice.SlackBuild on Slackware 14.2+ with kde plasma in a pure qt5 environment
I did some testing -
So LO has some way to go before being production ready for a pure qt5 kde plasma environment. |
All times are GMT -5. The time now is 10:11 AM. |