LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM
User Name
Password
Slackware - ARM This forum is for the discussion of Slackware ARM.

Notices


Reply
  Search this Thread
Old 11-07-2017, 01:06 PM   #31
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 587

Rep: Reputation: 423Reputation: 423Reputation: 423Reputation: 423Reputation: 423

Quote:
Originally Posted by abga View Post
@drmozes - if you are so kind and obviously have some spare time can you please jump in and start a compilation on your build pool wonder machine by adapting the Slack 14.2 x86 LibreOffice?
The Orange Pi H3 Plus v1 only has 1GB RAM, and I have a 4GB swap partition on an SSD. There are a few SlackBuilds that reduce down the number of parallel builds due to RAM problems.
I need to get a machine with more RAM at some point, but so far I've been able to get by on 1GB.

KDE also runs reasonably well on my Banana Pi and Orange Pi. I wouldn't use it myself for a desktop on ARM, but when I do test it from time to time, it's usable.
I don't have any time to look at something like libreoffice - particularly with the dependencies it requires.
 
Old 11-07-2017, 06:25 PM   #32
Linux.tar.gz
Senior Member
 
Registered: Dec 2003
Location: Paris
Distribution: Slackware forever.
Posts: 2,382

Original Poster
Rep: Reputation: 91
The [GAL] problem comes from a very old unpatched gcc bug, I doubt it's linked to the lack of Java/Ant.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70112

Requires taking files manually from a x86 build, then resume the compilation.
I'll try that.

Last edited by Linux.tar.gz; 11-07-2017 at 07:16 PM.
 
Old 11-08-2017, 04:40 PM   #33
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware x86 & ARM
Posts: 108

Rep: Reputation: 25
Just a short update, 15 hours into the build with only one makejob I've reached the "zone" where it crashed yesterday after just 7 hours with two makejobs.
Unfortunately it looks like it will crash again in the same "Piņa colada" section compiling a huge 29MB source file for the last 30 minutes: COLLADASaxFWLColladaParserAutoGen15PrivateValidation.cpp
I've noticed only after I started the compilation that I gave the GPU 256MB RAM and was left with only with 735 MB for the system, my bad.

Code:
tail -f /mnt/hd/libreoffice/libreoffice-build.log
[build CXX] workdir/UnpackedTarball/opencollada/COLLADASaxFrameworkLoader/src/generated14/COLLADASaxFWLSplineLoader14.cpp
[build CXX] workdir/UnpackedTarball/opencollada/COLLADASaxFrameworkLoader/src/generated14/COLLADASaxFWLVisualSceneLoader14.cpp
[build CXX] workdir/UnpackedTarball/opencollada/COLLADASaxFrameworkLoader/src/generated15/COLLADASaxFWLAssetLoader15.cpp
[build CXX] workdir/UnpackedTarball/opencollada/COLLADASaxFrameworkLoader/src/generated15/COLLADASaxFWLColladaParserAutoGen15Private.cpp
[build CXX] workdir/UnpackedTarball/opencollada/COLLADASaxFrameworkLoader/src/generated15/COLLADASaxFWLColladaParserAutoGen15PrivateEnums.cpp
[build CXX] workdir/UnpackedTarball/opencollada/COLLADASaxFrameworkLoader/src/generated15/COLLADASaxFWLColladaParserAutoGen15PrivateFindElementHash.cpp
[build CXX] workdir/UnpackedTarball/opencollada/COLLADASaxFrameworkLoader/src/generated15/COLLADASaxFWLColladaParserAutoGen15PrivateFunctionMap.cpp
[build CXX] workdir/UnpackedTarball/opencollada/COLLADASaxFrameworkLoader/src/generated15/COLLADASaxFWLColladaParserAutoGen15PrivateFunctionMapFactory.cpp
[build CXX] workdir/UnpackedTarball/opencollada/COLLADASaxFrameworkLoader/src/generated15/COLLADASaxFWLColladaParserAutoGen15PrivateNameMap.cpp
[build CXX] workdir/UnpackedTarball/opencollada/COLLADASaxFrameworkLoader/src/generated15/COLLADASaxFWLColladaParserAutoGen15PrivateValidation.cpp

ps axuf | grep cc1plus
root     29286  3.0  0.0   3168   480 pts/1    S+   23:11   0:00                  \_ grep cc1plus
root     28864 69.4 84.1 684224 633580 ?       D    23:00   7:58                  \_ /usr/libexec/gcc/arm-slackware-linux-gnueabihf/7.2.0/cc1plus -quiet -I /mnt/hd/libreoffice/tmp/SBo/libreoffice-5.4.2.2/workdir/UnpackedTarball/opencollada/COLLADASaxFrameworkLoader/src/generated15/ -I /mnt/hd/libreoffice/tmp/SBo/libreoffice-5.4.2.2/workdir/UnpackedTarball/opencollada/COLLADABaseUtils/include -I /mnt/hd/libreoffice/tmp/SBo/libreoffice-5.4.2.2/workdir/UnpackedTarball/opencollada/COLLADABaseUtils/include/Math -I /mnt/hd/libreoffice/tmp/SBo/libreoffice-5.4.2.2/workdir/UnpackedTarball/opencollada/COLLADAFramework/include -I /mnt/hd/libreoffice/tmp/SBo/libreoffice-5.4.2.2/workdir/UnpackedTarball/opencollada/COLLADASaxFrameworkLoader/include -I /mnt/hd/libreoffice/tmp/SBo/libreoffice-5.4.2.2/workdir/UnpackedTarball/opencollada/COLLADASaxFrameworkLoader/include/generated14 -I /mnt/hd/libreoffice/tmp/SBo/libreoffice-5.4.2.2/workdir/UnpackedTarball/opencollada/COLLADASaxFrameworkLoader/include/generated15 -I /mnt/hd/libreoffice/tmp/SBo/libreoffice-5.4.2.2/workdir/UnpackedTarball/opencollada/Externals/MathMLSolver/include -I /mnt/hd/libreoffice/tmp/SBo/libreoffice-5.4.2.2/workdir/UnpackedTarball/opencollada/Externals/MathMLSolver/include/AST -I /mnt/hd/libreoffice/tmp/SBo/libreoffice-5.4.2.2/workdir/UnpackedTarball/opencollada/Externals/UTF/include -I /mnt/hd/libreoffice/tmp/SBo/libreoffice-5.4.2.2/workdir/UnpackedTarball/opencollada/GeneratedSaxParser/include -I /mnt/hd/libreoffice/tmp/SBo/libreoffice-5.4.2.2/include -I /opt/java/include -I /opt/java/include/linux -I /mnt/hd/libreoffice/tmp/SBo/libreoffice-5.4.2.2/config_host -I /mnt/hd/libreoffice/tmp/SBo/libreoffice-5.4.2.2/workdir/UnpackedTarball/opencollada/Externals/pcre/include -I /mnt/hd/libreoffice/tmp/SBo/libreoffice-5.4.2.2/workdir/UnpackedTarball/opencollada/Externals/UTF/include -I /mnt/hd/libreoffice/tmp/SBo/libreoffice-5.4.2.2/workdir/UnpackedTarball/opencollada/Externals/MathMLSolver/include -I /mnt/hd/libreoffice/tmp/SBo/libreoffice-5.4.2.2/workdir/UnpackedTarball/opencollada/Externals/MathMLSolver/include/AST -MMD /mnt/hd/libreoffice/tmp/SBo/libreoffice-5.4.2.2/workdir/GenCxxObject/UnpackedTarball/opencollada/COLLADASaxFrameworkLoader/src/generated15/COLLADASaxFWLColladaParserAutoGen15PrivateValidation.d -MF /mnt/hd/libreoffice/tmp/SBo/libreoffice-5.4.2.2/workdir/Dep/GenCxxObject/UnpackedTarball/opencollada/COLLADASaxFrameworkLoader/src/generated15/COLLADASaxFWLColladaParserAutoGen15PrivateValidation.d_ -MP -MT /mnt/hd/libreoffice/tmp/SBo/libreoffice-5.4.2.2/workdir/GenCxxObject/UnpackedTarball/opencollada/COLLADASaxFrameworkLoader/src/generated15/COLLADASaxFWLColladaParserAutoGen15PrivateValidation.o -D_GNU_SOURCE -D ARM -D ARM32 -D BOOST_ERROR_CODE_HEADER_ONLY -D BOOST_SYSTEM_NO_DEPRECATED -D CPPU_ENV=gcc3 -D LINUX -D NDEBUG -D OSL_DEBUG_LEVEL=0 -D UNIX -D UNX -D _FILE_OFFSET_BITS=64 -D _PTHREADS -D _REENTRANT -D SYSTEM_LIBXML -D GENERATEDSAXPARSER_XMLPARSER_LIBXML -D GENERATEDSAXPARSER_VALIDATION -D PCRE_STATIC -D EXCEPTIONS_ON -D LIBO_INTERNAL_ONLY -isystem /usr/include/libxml2 /mnt/hd/libreoffice/tmp/SBo/libreoffice-5.4.2.2/workdir/UnpackedTarball/opencollada/COLLADASaxFrameworkLoader/src/generated15/COLLADASaxFWLColladaParserAutoGen15PrivateValidation.cpp -quiet -dumpbase COLLADASaxFWLColladaParserAutoGen15PrivateValidation.cpp -march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -mtls-dialect=gnu -auxbase-strip /mnt/hd/libreoffice/tmp/SBo/libreoffice-5.4.2.2/workdir/GenCxxObject/UnpackedTarball/opencollada/COLLADASaxFrameworkLoader/src/generated15/COLLADASaxFWLColladaParserAutoGen15PrivateValidation.o -O3 -Wall -Wno-missing-braces -Wnon-virtual-dtor -Wendif-labels -Wextra -Wundef -Wunused-macros -Wduplicated-cond -Wlogical-op -Wshift-overflow=2 -Wunused-const-variable=1 -Wshadow -Woverloaded-virtual -w -std=gnu++14 -fvisibility=hidden -fmessage-length=0 -fno-common -fvisibility-inlines-hidden -fstack-protector-strong -fPIC -fexceptions -fno-enforce-eh-specs -o -

du -s -h /mnt/hd/libreoffice/tmp/SBo/libreoffice-5.4.2.2/workdir/UnpackedTarball/opencollada/COLLADASaxFrameworkLoader/src/generated15/COLLADASaxFWLColladaParserAutoGen15PrivateValidation.cpp
29M     /mnt/hd/libreoffice/tmp/SBo/libreoffice-5.4.2.2/workdir/UnpackedTarball/opencollada/COLLADASaxFrameworkLoader/src/generated15/COLLADASaxFWLColladaParserAutoGen15PrivateValidation.cpp
@drmozes
Sorry, I was under the impression that you somehow split the make jobs and use the x86 systems for the individual compilation. That's why I asked you for help on this.
Attached Thumbnails
Click image for larger version

Name:	libreoffice.jpg
Views:	5
Size:	69.9 KB
ID:	26240  

Last edited by abga; 11-08-2017 at 04:51 PM. Reason: typo
 
Old 11-08-2017, 05:47 PM   #34
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 587

Rep: Reputation: 423Reputation: 423Reputation: 423Reputation: 423Reputation: 423
Quote:
Originally Posted by abga View Post
@drmozes
Sorry, I was under the impression that you somehow split the make jobs and use the x86 systems for the individual compilation. That's why I asked you for help on this.
I do, but the linking is done natively.
Why don't you look at the x-toolchain:
ftp://ftp.arm.slackware.com/slackwar...s/x-toolchain/
You'd need to use the build script there, and then run distccd on the x86 (see the rc.local-addition file).
On the ARM side, you'd look at "dbuild" which basically creates symlink wrappers for gcc et al to distcc, and sets $PATH and a few other things in the shell environment.
It's a bit fiddly because it's set up for the ARM port environment only, but is easy enough to adapt if you spend time looking at what it's doing.

Even if you scale back the number of parallel jobs, you can still make the x86 do most of the compilation. My cross toolchain only supports gcc though - I have not looked into llvm yet.
 
Old 11-10-2017, 01:26 AM   #35
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware x86 & ARM
Posts: 108

Rep: Reputation: 25
Escaped the out of memory form opencollada, reported in the previous post, but got this morning into another one, this time a serious one
It happened after about 48 hours into the compilation and it was caused by building libetonyek. The only larger source files I found where in:
/mnt/hd/libreoffice/tmp/SBo/libreoffice-5.4.2.2/workdir/UnpackedTarball/libetonyek/src/lib/.deps
The crash:
Code:
[build PAT] libetonyek
....
/usr/include/c++/7.2.0/bits/deque.tcc:611:3: note: parameter passing for argument of type ‘std::_Deque_iterator<libetonyek::IWORKGradientStop, const libetonyek::IWORKGradientStop&, const libetonyek::IWORKGradientStop*>’ changed in GCC 7.1
  CXX      libetonyek_internal_la-IWAReader.lo
  CXX      libetonyek_internal_la-IWASnappyStream.lo
  CXX      libetonyek_internal_la-IWAText.lo
  CXX      libetonyek_internal_la-IWORKChainedTokenizer.lo
  CXX      libetonyek_internal_la-IWORKChart.lo
  CXX      libetonyek_internal_la-IWORKCollector.lo
  CXX      libetonyek_internal_la-IWORKDictionary.lo
  CXX      libetonyek_internal_la-IWORKDiscardContext.lo
  CXX      libetonyek_internal_la-IWORKDocumentInterface.lo
  CXX      libetonyek_internal_la-IWORKFormula.lo
g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
make[6]: *** [Makefile:1271: libetonyek_internal_la-IWORKFormula.lo] Error 1
make[5]: *** [Makefile:830: all] Error 2
make[4]: *** [Makefile:397: all-recursive] Error 1
make[3]: *** [Makefile:506: all-recursive] Error 1
make[2]: *** [Makefile:417: all] Error 2
make[1]: *** [/mnt/hd/libreoffice/tmp/SBo/libreoffice-5.4.2.2/external/libetonyek/ExternalProject_libetonyek.mk:29: /mnt/hd/libreoffice/tmp/SBo/libreoffice-5.4.2.2/workdir/ExternalProject/libetonyek/build] Error 1
make: *** [Makefile:269: build] Error 2
I was monitoring the system with the help of Monitorix and noticed the bumps (100%) usage in the Memory Allocation/ VFS graphs.
ATM I'd stop investing my time/efforts in this, I've never imagined that I'll need more than 500-900 MB for a compilation and considering this a slight "insult" that I'd expect maybe from the Redmond guys but not from the OpenSource community. But maybe some LibreOffice developers were working at Redmond before ...
Maybe during the weekend I'll start it again with 4 make jobs on 900MB RAM (hope I won't forget again to edit the /boot/config.txt & reboot) and a 4GB external HDD swap (I tried to avoid this until now).

@drmozes
Thanks, I was looking into it when I first joined LQ and was considering compiling my own kernel for the Pi boards, downloaded some of your stuff but never really had time to look and understand/learn it. I got successful until now by only using 4 armv7 cores and 900MB RAM, apparently this is not enough for larger compilations anymore. I never used a swap to substitute the RAM especially for a compilation, regardless of how fast the storage is (it will get bottle-necked anyways matching the USB speed on the Raspberry Pi).
I don't own any SSD, I consider them a luxury, still expensive, only half of the capacity optimally usable (I would leave the other half for the wear leveling) and unreliable.
Intel's 3D XPoint tech looks promising though (robustness).

Last edited by abga; 11-10-2017 at 01:34 AM. Reason: changed format
 
Old 11-12-2017, 01:10 AM   #36
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware x86 & ARM
Posts: 108

Rep: Reputation: 25
I just started a new compilation without Java & with Apache ANT & with KDE4 on a Pi2B - 957 MB RAM, external HDD working directory, 4 make jobs and a 4 GB external HDD swap partition. I'll report back in the evening, gtg.
If I somehow fail again, then I'll use the build wonder machine drmozes created.

@Linux.tar.gz
What's your status on this? Have you got it compiled and working finally?

Last edited by abga; 11-13-2017 at 05:12 PM. Reason: correction - without JAVA & with Apache ANT & with KDE4
 
Old 11-12-2017, 04:57 AM   #37
Linux.tar.gz
Senior Member
 
Registered: Dec 2003
Location: Paris
Distribution: Slackware forever.
Posts: 2,382

Original Poster
Rep: Reputation: 91
I tried to build with -O0, as said in the gcc bug report, but the error was the same.

I now have to look at the source files to see what is moved by gengal.bin and try to do the stuff manually, then resume the compilation.
Not sure to succeed...
 
Old 11-13-2017, 05:56 PM   #38
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware x86 & ARM
Posts: 108

Rep: Reputation: 25
It was nothing to update yesterday evening as the compilation was still running. Unfortunately, today around noon I got a short power drop (some switching that happens 1-2 a week) that blew my compilation I only use laptops and a small (and very tired) UPS for my monitor & a switch, the Pi boards I backup through some cheap & modified Chinese power banks that should output 1,5A for a short period. The power outage was a little bit longer and i got the external HDD disconnected & the Pi2Board frozen. Bad luck.

Now, I got interested and started this compilation after I experienced how fast LibreOffice runs under Raspbian on the Raspberry Pi0. During this 25 hour partial compilation with 957MB RAM and 4GB swap, which was an utterly stupid approach from the very beginning, but then somehow one needs to tests his knowledge every now and then, I got into exactly what I was expecting, compilation done on the swap and not in RAM.
Yesterday I observed many times some cc1plus processes exceeding 400-500MB and today in the morning before I left home and the compilation reached the Calc application, I got my external HDD working 100% and by checking the system stats I observed a wave-like behavior - for every 4 cc1plus new jobs the RAM was filling up really fast and the swap usage was reaching 600-800MB, by the time the cc1plus were done and the system was clearing the RAM/swap, a new bunch of cc1plus processes were starting again filling everything up.

According to the official doc the RAM looks to be a taboo subject (obviously), as estimated before at least 2GB RAM are necessary for the compilation:
https://wiki.documentfoundation.org/...uildingOnLinux

@drmozes - your wonder machine looks to be the only option left. I'll definitely take a look into it these days and hopefully won't need to annoy you too much with support requests.

@Linux.tar.gz
After 25 hours of compilation, with only some gcc 7.1 related notes and warnings that didn't break anything, I got apparently into the sc source folder that belongs to the Calc application:
http://www.lanedo.com/exploring-the-...ice-code-base/
And my last lines in the 9MB big and 124440 lines long build-log were:
Code:
[build CXX] sc/source/ui/view/select.cxx
[build CXX] sc/source/ui/view/selectionstate.cxx
[build CXX] sc/source/ui/view/spelldialog.cxx
[build CXX] sc/source/ui/view/spelleng.cxx
[build CXX] sc/source/ui/view/spellcheckcontext.cxx
I'm wondering if your crash ([GAL] problem) happened after this stage, just to make sure/prepare that I won't end up with another failed compilation.

Last edited by abga; 11-13-2017 at 06:00 PM. Reason: 1 x typo
 
Old 11-14-2017, 02:31 PM   #39
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware x86 & ARM
Posts: 108

Rep: Reputation: 25
Somewhere after 1/2 (line 85306/124440) of the libreoffice-build.log I've noticed this:
Code:
[build DEP] LNK:Library/libswlo.so
[build DEP] LNK:Library/libmswordlo.so
[build DEP] LNK:Executable/pixelctl
[build DEP] LNK:Executable/gengal.bin
[build DEP] SRS:svx/gal
[build DEP] SRS:svx/ofa
[build DEP] SRS:svx/res
[build DEP] LNK:Library/libtextconversiondlgslo.so
[build DEP] LNK:Library/libsvxcorelo.so
I was using -O3 in my last compilation attempt, specifically:
Code:
SLKCFLAGS="-O3 -march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -std=c++98"
By looking after some more building LibreOffice for ARM experiences I stumbled upon this (old) discussion:
https://ask.libreoffice.org/en/quest...running-linux/

"
As might this Slackware thread https://www.linuxquestions.org/quest...ce-arm-935880/ , although they don't appear to have built it successfully.
"
 
Old 11-15-2017, 02:54 AM   #40
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware x86 & ARM
Posts: 108

Rep: Reputation: 25
@Linux.tar.gz

Can you please change the title of this thread, now that your original issue seems to be resolved, and put a more generic title like Building LibreOffice on Slackware ARM. Maybe we'll get more Slackers interested/involved and get some documentation/instructions/Slack.Build done in the end.
Thanks!
 
Old 11-17-2017, 03:50 AM   #41
Linux.tar.gz
Senior Member
 
Registered: Dec 2003
Location: Paris
Distribution: Slackware forever.
Posts: 2,382

Original Poster
Rep: Reputation: 91
Like the ones you've seen, there's already enough threads about building LO.

And the vpush error is the error the Slackware ARM users will encounter first, so they'll come here.

I didn't find the time yet to get into the code.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Alien libreoffice SlackBuild Digest::MD5 problem Linux.tar.gz Slackware - ARM 4 10-28-2017 09:50 AM
[Alien's LO 5.2.5] Strange bug/annoyance in Alien's LibreOffice 5.2.5 sombragris Slackware 3 02-05-2017 10:39 AM
Alien Bob's Libreoffice 4.3.0.4 slackbuild AlleyTrotter Slackware 1 08-06-2014 05:53 PM
[SOLVED] LibreOffice-4.2.3 slackbuild error on new KDE integration split off frushiyama Slackware 2 04-22-2014 07:03 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM

All times are GMT -5. The time now is 02:17 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration