Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 739134 - app-office/libreoffice-7 version bump
Summary: app-office/libreoffice-7 version bump
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 3 votes (vote)
Assignee: Gentoo Office Team
URL:
Whiteboard:
Keywords:
Depends on: jdk11
Blocks:
  Show dependency tree
 
Reported: 2020-08-26 19:11 UTC by Andreas Sturmlechner
Modified: 2021-12-04 20:51 UTC (History)
23 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Sturmlechner gentoo-dev 2020-08-26 19:11:15 UTC
In preparation, sort of.
Comment 1 andy 2020-09-22 18:49:03 UTC
(In reply to Andreas Sturmlechner from comment #0)
> In preparation, sort of.

i have been using yours ebuild and modified it a bit in my overlay (hedmos-overlay). it has been working good for month now. feel free to comment or give me some feedback if you like.
Comment 2 Silvio 2020-09-23 08:42:23 UTC
7.0.1 is out
Comment 3 andy 2020-09-23 15:38:48 UTC
(In reply to Silvio from comment #2)
> 7.0.1 is out

yes i have 7.0.1.2 .and 7.0.2.1 is out to but not with |10n..
Comment 4 andy 2020-09-23 16:02:26 UTC
but libreoffice-7.x depends on dev-libs/qrcodegen and that is not in portage....
Comment 5 Scott Furry 2020-09-23 16:20:42 UTC
(In reply to andy from comment #4)
> but libreoffice-7.x depends on dev-libs/qrcodegen and that is not in
> portage....

And it's unclear why we don't have this in tree yet. Rather utilitarian library given it has multiple language bindings. Python bindings are available from PyPi.

see https://www.nayuki.io/page/qr-code-generator-library
Comment 6 Andreas Sturmlechner gentoo-dev 2020-09-26 19:48:09 UTC
(In reply to Scott Furry from comment #5)
> (In reply to andy from comment #4)
> > but libreoffice-7.x depends on dev-libs/qrcodegen and that is not in
> > portage....
> 
> And it's unclear why we don't have this in tree yet. Rather utilitarian
> library given it has multiple language bindings. Python bindings are
> available from PyPi.
You'll have to find a volunteer to deal with the trainwreck build system. There's bug 691740 for that, but it does not affect libreoffice-7 version bump at all.
Comment 7 Silvio 2020-10-17 12:55:58 UTC
So it is not possible to have a quick solution, is it?
Comment 8 Silvio 2020-10-24 23:09:24 UTC
Here in pg_overlay there is an ebuild for 7.0.2.2
https://data.gpo.zugaina.org/pg_overlay/app-office/libreoffice/
I'll test it soon.
Comment 9 Andreas Sturmlechner gentoo-dev 2020-10-24 23:11:54 UTC
Yeah, that's an outdated copy with incorrect virtual/jdk minimum dep.
Comment 10 Silvio 2020-10-24 23:16:15 UTC
(In reply to Andreas Sturmlechner from comment #9)
> Yeah, that's an outdated copy with incorrect virtual/jdk minimum dep.

So do you advise me not to use it?
Comment 11 Silvio 2020-10-24 23:36:26 UTC
(In reply to Silvio from comment #10)
> (In reply to Andreas Sturmlechner from comment #9)
> > Yeah, that's an outdated copy with incorrect virtual/jdk minimum dep.
> 
> So do you advise me not to use it?

It doesn't compile ... 

Do you know how much time will it take to deliver the ebuild in portage?
Comment 12 Perfect Gentleman 2020-10-25 01:53:50 UTC
(In reply to Silvio from comment #11)
> (In reply to Silvio from comment #10)
> > (In reply to Andreas Sturmlechner from comment #9)
> > > Yeah, that's an outdated copy with incorrect virtual/jdk minimum dep.
> > 
> > So do you advise me not to use it?
> 
> It doesn't compile ... 
> 
> Do you know how much time will it take to deliver the ebuild in portage?

It does compile
app-office/libreoffice-7.0.2.2::pg_overlay was built with the following:
USE="branding cups dbus kde mariadb pdfimport -accessibility -bluetooth -coinmp -debug -eds -firebird -googledrive -gstreamer -gtk -java -ldap -odk -postgres -test" LIBREOFFICE_EXTENSIONS="-nlpsolver -scripting-beanshell -scripting-javascript -wiki-publisher" PYTHON_SINGLE_TARGET="python3_9 -python3_7 -python3_8"
CFLAGS="-march=native -mtune=native -O3 -pipe -fdata-sections -fdevirtualize-at-ltrans -ffunction-sections -fgraphite-identity -fipa-pta -flto=9 -floop-interchange -floop-nest-optimize -floop-parallelize-all -fomit-frame-pointer -fuse-linker-plugin -fno-asynchronous-unwind-tables -fno-plt -fno-stack-protector -s"
CXXFLAGS="-march=native -mtune=native -O3 -pipe -fdata-sections -fdevirtualize-at-ltrans -ffunction-sections -fgraphite-identity -fipa-pta -flto=9 -floop-interchange -floop-nest-optimize -floop-parallelize-all -fomit-frame-pointer -fuse-linker-plugin -fno-asynchronous-unwind-tables -fno-plt -fno-stack-protector -s"
FEATURES="config-protect-if-modified preserve-libs multilib-strict xattr userpriv sfperms strict metadata-transfer ebuild-locks sandbox assume-digests merge-sync qa-unresolved-soname-deps unknown-features-warn usersync binpkg-logs ccache binpkg-dostrip protect-owned ipc-sandbox userfetch parallel-fetch binpkg-docompress pid-sandbox usersandbox network-sandbox unmerge-logs unmerge-orphans parallel-install news fixlafiles distlocks"
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--gc-sections -Wl,--sort-common -Wl,-z,norelro -march=native -mtune=native -O3 -pipe -fdata-sections -fdevirtualize-at-ltrans -ffunction-sections -fgraphite-identity -fipa-pta -flto=9 -floop-interchange -floop-nest-optimize -floop-parallelize-all -fomit-frame-pointer -fuse-linker-plugin -fno-asynchronous-unwind-tables -fno-plt -fno-stack-protector -s"
Comment 13 Andreas Sturmlechner gentoo-dev 2020-10-25 08:30:47 UTC
IUSE=-java...
Comment 14 Perfect Gentleman 2020-10-25 08:48:48 UTC
(In reply to Andreas Sturmlechner from comment #13)
> IUSE=-java...

Yep, I don't like java
Comment 15 Perfect Gentleman 2020-10-25 08:53:29 UTC
(In reply to Andreas Sturmlechner from comment #9)
> Yeah, that's an outdated copy with incorrect virtual/jdk minimum dep.

It's from libreoffice-9999
Comment 16 Andreas Sturmlechner gentoo-dev 2020-10-25 09:28:55 UTC
Please go to the forums instead if you want to have a forums style discussion.

- The blocker of this bug is well documented, any work on libreoffice-9999 is also stalled until this is solved.
- It's your overlay, you do you - but don't pretend it 'works' when it only does with a limited IUSE set.
Comment 17 Perfect Gentleman 2020-10-25 10:57:16 UTC
(In reply to Andreas Sturmlechner from comment #16)
> - It's your overlay, you do you - but don't pretend it 'works' when it only
> does with a limited IUSE set.
---------------------------------
okay, build with java. what next?
---------------------------------
```
app-office/libreoffice-7.0.3.1::pg_overlay was built with the following:
USE="branding cups dbus java kde mariadb -accessibility -base -bluetooth -coinmp -debug -eds -firebird -googledrive -gstreamer -gtk -ldap -odk -pdfimport -postgres -test" LIBREOFFICE_EXTENSIONS="-nlpsolver -scripting-beanshell -scripting-javascript -wiki-publisher" PYTHON_SINGLE_TARGET="python3_9 -python3_7 -python3_8"
CFLAGS="-march=native -mtune=native -O3 -pipe -fdata-sections -fdevirtualize-at-ltrans -ffunction-sections -fgraphite-identity -fipa-pta -flto=9 -floop-interchange -floop-nest-optimize -floop-parallelize-all -fomit-frame-pointer -fuse-linker-plugin -fno-asynchronous-unwind-tables -fno-plt -fno-stack-protector -s"
CXXFLAGS="-march=native -mtune=native -O3 -pipe -fdata-sections -fdevirtualize-at-ltrans -ffunction-sections -fgraphite-identity -fipa-pta -flto=9 -floop-interchange -floop-nest-optimize -floop-parallelize-all -fomit-frame-pointer -fuse-linker-plugin -fno-asynchronous-unwind-tables -fno-plt -fno-stack-protector -s"
FEATURES="qa-unresolved-soname-deps strict multilib-strict binpkg-docompress unmerge-logs preserve-libs ccache binpkg-dostrip config-protect-if-modified ipc-sandbox news sandbox distlocks assume-digests usersandbox ebuild-locks unmerge-orphans pid-sandbox parallel-fetch network-sandbox sfperms binpkg-logs userfetch merge-sync unknown-features-warn fixlafiles xattr userpriv metadata-transfer protect-owned parallel-install usersync"
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--gc-sections -Wl,--sort-common -Wl,-z,norelro -march=native -mtune=native -O3 -pipe -fdata-sections -fdevirtualize-at-ltrans -ffunction-sections -fgraphite-identity -fipa-pta -flto=9 -floop-interchange -floop-nest-optimize -floop-parallelize-all -fomit-frame-pointer -fuse-linker-plugin -fno-asynchronous-unwind-tables -fno-plt -fno-stack-protector -s"
```
Comment 18 Andreas Sturmlechner gentoo-dev 2020-10-25 11:25:38 UTC
(In reply to Perfect Gentleman from comment #17)
> ---------------------------------
> okay, build with java. what next?
> ---------------------------------
Awesome! Now fix your ebuild to depend on >=jdk-1.9, then add it straight to package.mask. Or go help fix bug 629252. Otherwise your stuff is still broken.
Comment 19 Perfect Gentleman 2020-10-25 11:46:30 UTC
(In reply to Andreas Sturmlechner from comment #18)
> (In reply to Perfect Gentleman from comment #17)
> > ---------------------------------
> > okay, build with java. what next?
> > ---------------------------------
> Awesome! Now fix your ebuild to depend on >=jdk-1.9, then add it straight to
> package.mask. Or go help fix bug 629252. Otherwise your stuff is still
> broken.

I've build it openjdk bumped to 15.0.1_p9. The problem is that LO doesn't detect OpenJDK. But binary from office site detected it.
Comment 20 Perfect Gentleman 2020-10-25 12:04:37 UTC
> I've build it openjdk bumped to 15.0.1_p9. The problem is that LO doesn't
> detect OpenJDK. But binary from office site detected it.

But it works anyway. Installed java-dependent extension.
Comment 21 Perfect Gentleman 2020-10-25 12:15:36 UTC
(In reply to Perfect Gentleman from comment #20)
> > I've build it openjdk bumped to 15.0.1_p9. The problem is that LO doesn't
> > detect OpenJDK. But binary from office site detected it.
> 
> But it works anyway. Installed java-dependent extension.

It works with openjdk-jre-bin, not with openjdk. Why? -\o/-
Comment 22 Perfect Gentleman 2020-10-25 12:16:40 UTC
> It works with openjdk-jre-bin, not with openjdk. Why? -\o/-
Could not create Java implementation loader /tmp/portage/app-office/libreoffice-7.0.3.1/work/libreoffice-7.0.3.1/stoc/source/javaloader/javaloader.cxx:314
Comment 23 andy 2020-10-26 20:18:26 UTC
i have this in my ebuilds:

DEPEND="${COMMON_DEPEND}
	java? (
	    dev-java/ant-core
		>=virtual/jdk-11

RDEPEND="${COMMON_DEPEND}
	java? ( >=virtual/jre-11-r1 )

	 elog "libreoffice needs jdk9+ for USE=java and is masked (-gentoo-vm) at the moment."
	 elog "if you want to override it.. have a look in:"
	 elog "https://wiki.gentoo.org/wiki//etc/portage/profile/package.use.mask"

i dont know if this is still vail.but if it is Andreas Sturmlechner is right
and the problem has to be fixed before it goes to portage.
Comment 24 Ivan 2020-10-26 21:02:16 UTC
(In reply to Perfect Gentleman from comment #22)

Version from pg_overlay worked pretty well, thanks. But for now it doesn't with jre/jdk-15 or I just don't know how to make it work properly. 

I'll resort to main Gentoo tree for a while.
But thank you for your ebuilds, efforts and time spent.
Comment 25 Perfect Gentleman 2020-10-27 04:58:09 UTC
(In reply to Ivan from comment #24)
> (In reply to Perfect Gentleman from comment #22)
> 
> Version from pg_overlay worked pretty well, thanks. But for now it doesn't
> with jre/jdk-15 or I just don't know how to make it work properly. 
> 
> I'll resort to main Gentoo tree for a while.
> But thank you for your ebuilds, efforts and time spent.

It works well with openjdk-jre-bin. As I said earlier LO doesn't detect it but it works as Java-dependent extension was installed and tested for working.
I don't get it why LO doesn't work with openjdk as LO-7 downloaded from official website detects openjdk and openjdk-bin and works with them normally.
Comment 26 Georgy Yakovlev archtester gentoo-dev 2020-10-28 21:00:35 UTC
someone got my attention to this bug... would never have seen it otherwise.

stale issues tracker is here, I can add it to the mask.
https://bugs.gentoo.org/697014
but in reality nobody works on java:11 issues actively and tracker does not reflect reality at all, much more things are broken.

as for OO, you can depend on || ( openjdk:11 openjdk-bin:11 ) directly for now if you just need JVM, stable symlinks are provided via /usr/$(get_libdir)/openjdk-11/bin/java and /opt/openjdk-11/bin/java (typing from memory) but those paths are not in $PATH.

also will have to stable-mask java flag in oo, because openjdk-11 is not getting stable anytime soon, sorry.
unmasking virtual/jdk:11 wreaks complete havoc on anything pulling java/deps.
getting it stable wreaks even more chaos.

we can add openjdk:!5 as well (it's short-lived version and will be dead in several month), but situation will be exactly the same as with 11.

as for https://bugs.gentoo.org/show_bug.cgi?id=629252, it's not getting anywhere.
there will be no new icedtea. and even old once might get removed/masked soon. just use openjdk, whatever version suits.


I'm available to help figure out sane way of getting existing jdk to work with it, so lmk.
Comment 27 Andrew John Hughes 2020-10-29 01:29:36 UTC
(In reply to Georgy Yakovlev from comment #26)

> there will be no new icedtea

That is not only untrue (we literally released a new version yesterday), but I don't see how you are in any position to speak on it.
Comment 28 Georgy Yakovlev archtester gentoo-dev 2020-10-29 01:37:57 UTC
(In reply to Andrew John Hughes from comment #27)
> (In reply to Georgy Yakovlev from comment #26)
> 
> > there will be no new icedtea
> 
> That is not only untrue (we literally released a new version yesterday), but
> I don't see how you are in any position to speak on it.

thanks, I almost masked due to security issues.

I've already bumped it earlier today in gentoo repo before it got bumped in java overlay, so we are good.

What I meant there will be icedtea-4 or 11 or whatever. that's the impression I got lurking in other older bugs from JDK9 times.

this is a sentence/discussion taken out of context of https://bugs.gentoo.org/show_bug.cgi?id=629252 which was used as a blocker of this bug.
I just pointed out this current bug should not wait for icedtea version 4 (or later) as it probably will not happen and just use openjdk-11.

btw, Andrew, while I have you attention, I would like to sync ::gentoo icedtea ebuild with the one you maintain in ::java-overlay, what's the preferred method of sending patches to you? I got some changes, ebuilds are diverging.

I mailed you but never got a reply.
Comment 29 Larry the Git Cow gentoo-dev 2020-10-29 10:40:17 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2c31a3aa736f52ba28567b41c80d71069654334f

commit 2c31a3aa736f52ba28567b41c80d71069654334f
Author:     Andreas Sturmlechner <asturm@gentoo.org>
AuthorDate: 2020-10-29 08:37:55 +0000
Commit:     Andreas Sturmlechner <asturm@gentoo.org>
CommitDate: 2020-10-29 10:40:01 +0000

    app-office/libreoffice: Add 7.0 stable branch
    
    Bug: https://bugs.gentoo.org/739134
    Package-Manager: Portage-3.0.8, Repoman-3.0.2
    Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org>

 .../libreoffice-7.0.3.1-fix-non-pdfium-build.patch |  29 +
 app-office/libreoffice/libreoffice-7.0.9999.ebuild | 603 +++++++++++++++++++++
 2 files changed, 632 insertions(+)
Comment 30 Andreas Sturmlechner gentoo-dev 2020-10-29 10:43:59 UTC
Thanks for clearing things up.

(In reply to Georgy Yakovlev from comment #26)
> also will have to stable-mask java flag in oo, because openjdk-11 is not
> getting stable anytime soon, sorry.
> unmasking virtual/jdk:11 wreaks complete havoc on anything pulling java/deps.
> getting it stable wreaks even more chaos.
How about stabilising openjdk:11 without virtual/jdk?
Comment 31 jospezial 2020-10-29 16:51:14 UTC
RDEPEND
java? (
		dev-java/openjdk:11
		dev-java/openjdk-jre-bin:11
		>=virtual/jre-1.8
	)

Does it really need all of them? Shouldn't it have: || (
as in DEPEND?
Comment 32 Andreas Sturmlechner gentoo-dev 2020-10-29 17:29:48 UTC
Right.
Comment 33 Larry the Git Cow gentoo-dev 2020-10-29 17:32:29 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=36a871e8cef9c6845c49ac350090f0540beb3c4a

commit 36a871e8cef9c6845c49ac350090f0540beb3c4a
Author:     Andreas Sturmlechner <asturm@gentoo.org>
AuthorDate: 2020-10-29 17:32:01 +0000
Commit:     Andreas Sturmlechner <asturm@gentoo.org>
CommitDate: 2020-10-29 17:32:14 +0000

    app-office/libreoffice: Add missing || ( )
    
    Reported-by: jospezial <jospezial@gmx.de>
    Bug: https://bugs.gentoo.org/739134
    Package-Manager: Portage-3.0.8, Repoman-3.0.2
    Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org>

 app-office/libreoffice/libreoffice-7.0.9999.ebuild | 4 ++--
 app-office/libreoffice/libreoffice-9999.ebuild     | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)
Comment 34 jospezial 2020-10-29 20:57:48 UTC
See also
https://bugs.gentoo.org/show_bug.cgi?id=751799
Comment 35 Adrien Dessemond 2020-10-30 14:17:27 UTC
Builds (and starts) with dev-java/icedtea-3.17. However, because LibreOffice 7.x prefers clang over gcc (ref. => https://bugs.documentfoundation.org/show_bug.cgi?id=131697) and because there is no 1:1 equivalence in options used by both compilers, compilation failures occurred here with:

CXXFLAGS=CFLAGS="-O3 -pipe -march=native -fomit-frame-pointer -fopt-info-vec -mindirect-branch=thunk -mindirect-branch-register"

Compilation succeeds with:

CXXFLAGS=CFLAGS="-O3 -pipe -march=native -fomit-frame-pointer"


Stripping flags or forcing a "safe-set" in the ebuild might be an option?

Anyway good job! :)
Comment 36 Perfect Gentleman 2020-10-30 14:22:34 UTC
(In reply to Adrien Dessemond from comment #35)
> Builds (and starts) with dev-java/icedtea-3.17. However, because LibreOffice
> 7.x prefers clang over gcc (ref. =>
> https://bugs.documentfoundation.org/show_bug.cgi?id=131697) and because
> there is no 1:1 equivalence in options used by both compilers, compilation
> failures occurred here with:
> 
> CXXFLAGS=CFLAGS="-O3 -pipe -march=native -fomit-frame-pointer -fopt-info-vec
> -mindirect-branch=thunk -mindirect-branch-register"
> 
> Compilation succeeds with:
> 
> CXXFLAGS=CFLAGS="-O3 -pipe -march=native -fomit-frame-pointer"
> 
> 
> Stripping flags or forcing a "safe-set" in the ebuild might be an option?
> 
> Anyway good job! :)

You can do next: remove clang, emerge libreoffce, then re-emerge clamg.
Comment 37 andy 2020-10-30 15:56:10 UTC
There is no option as far as i can tell yet.i have contacted the devs about it.
And there is no option for --system-skia. I have the commits when they did the change and it is quite big.i dont know....but one option is to blind libreoffi(In reply to Adrien Dessemond from comment #35)
> Builds (and starts) with dev-java/icedtea-3.17. However, because LibreOffice
> 7.x prefers clang over gcc (ref. =>
> https://bugs.documentfoundation.org/show_bug.cgi?id=131697) and because
> there is no 1:1 equivalence in options used by both compilers, compilation
> failures occurred here with:
> 
> CXXFLAGS=CFLAGS="-O3 -pipe -march=native -fomit-frame-pointer -fopt-info-vec
> -mindirect-branch=thunk -mindirect-branch-register"
> 
> Compilation succeeds with:
> 
> CXXFLAGS=CFLAGS="-O3 -pipe -march=native -fomit-frame-pointer"
> 
> 
> Stripping flags or forcing a "safe-set" in the ebuild might be an option?
> 
> Anyway good job! :)

There is no option as far as i can tell yet.i have contacted the devs about it.
And there is no option for --system-skia. I have the commits when they did the change and it is quite big.i have not tested it but one option is to disable skia.
Comment 38 Perfect Gentleman 2020-10-30 16:09:10 UTC
just add to EXTRA_ECONF="--disable-skia" and voilà LO-7 can be built with all optimizations enabled and with GCC only
Comment 39 andy 2020-10-30 16:52:43 UTC
(In reply to Perfect Gentleman from comment #38)
> just add to EXTRA_ECONF="--disable-skia" and voilà LO-7 can be built with
> all optimizations enabled and with GCC only

or add it as a useflag because not every one use vulkan.
Comment 40 Adrien Dessemond 2020-10-30 16:58:47 UTC
Good news if Skia can be disabled (those who do not want +vulkan will appreciate) however most of us will leave it enabled and have a side-by-side installation of both clang and GCC. 

Although a temporary emerge -C clang might work, it is definitely "heavy" and counter-intuitive (you have to re-emerge it again and it will take some time which might be mitigated by building a binary package). Beyond that it is wrong to assume a "loosely coupled" dependency between clang and LibreOffice in the long run. At some point, LibreOffice might require it, not counting the dependencies.

Some packages like >=media-video/ffmpeg-4.3.1 and sys-libs/glibc already takes the approach of overriding the {C,CXX}FLAGS variables to use a well known, safe set of compiler options.
Comment 41 Perfect Gentleman 2020-10-30 17:11:03 UTC
(In reply to Adrien Dessemond from comment #40)
> Although a temporary emerge -C clang might work, it is definitely "heavy"
> and counter-intuitive (you have to re-emerge it again and it will take some
> time which might be mitigated by building a binary package). 
Or build LO and its all deps with Clang but that might break linkage with libs/packages built with GCC.
Comment 42 Silvio 2020-10-31 09:21:29 UTC
Are the 7 ebuild arriving? :)
I didn't understand if it could be created a testing ebuild on portage with the last discovers.
Comment 43 Silvio 2020-11-01 17:51:38 UTC
Any news?

I think it is important that gentoo user could use the new Libreoffice version as it carries many new features.

May I help in any way?
Comment 44 Perfect Gentleman 2020-11-01 18:05:30 UTC
(In reply to Silvio from comment #43)
> Any news?
> 
> I think it is important that gentoo user could use the new Libreoffice
> version as it carries many new features.
> 
> May I help in any way?

Who wants to use it use it. Heh %)
Comment 45 Silvio 2020-11-01 21:32:03 UTC
(In reply to Perfect Gentleman from comment #44)

> Who wants to use it use it. Heh %)

How?
Comment 46 Silvio 2020-11-03 13:45:48 UTC
Any hope to have the new version soon on portage? :)
Comment 47 Iñigo 2020-11-03 15:39:38 UTC
(In reply to Silvio from comment #45)
> (In reply to Perfect Gentleman from comment #44)
> 
> > Who wants to use it use it. Heh %)
> 
> How?

In the Libreoffice website you can download an appImage for the latest version. It is not ideal, and won't be integrated to the system, but seems to be the only way of having LibreOffice 7 on Gentoo.

pg_overlay seems to have it too, but it pulls a ton of updates/and dependencies over stock Gentoo. Doing a package.mask and only unmasking LibreOffice will reach a point where it won't install and won't tell you what else you need to unmask, so you have to bite the bullet and risk it.
Comment 48 Adrien Dessemond 2020-11-03 15:49:36 UTC
You can also emerge =app-office/libreoffice-7.0.9999 (you will have to unmask it first).

You also might have to adjust your CFLAGS/CXXFLAGS variables to ensure clang does not see unsupported compiler options, see the comment #35 above. As suggested in comment #36, you also might have to remove clang,  recompile LibreOffice and emerge clang again afterwards.
Comment 49 Silvio 2020-11-03 16:07:35 UTC
(In reply to Adrien Dessemond from comment #48)
> You can also emerge =app-office/libreoffice-7.0.9999 (you will have to
> unmask it first).
> 
> You also might have to adjust your CFLAGS/CXXFLAGS variables to ensure clang
> does not see unsupported compiler options, see the comment #35 above. As
> suggested in comment #36, you also might have to remove clang,  recompile
> LibreOffice and emerge clang again afterwards.

[blocks B      ] app-office/libreoffice-l10n ("app-office/libreoffice-l10n" is blocking app-office/libreoffice-7.0.9999)

I cannot install it, it needs a masked updated version even of libreoffice-l10n
Comment 50 Silvio 2020-11-03 16:08:32 UTC
(In reply to Iñigo from comment #47)
> (In reply to Silvio from comment #45)
> > (In reply to Perfect Gentleman from comment #44)
> > 
> > > Who wants to use it use it. Heh %)
> > 
> > How?
> 
> In the Libreoffice website you can download an appImage for the latest
> version. It is not ideal, and won't be integrated to the system, but seems
> to be the only way of having LibreOffice 7 on Gentoo.
> 
> pg_overlay seems to have it too, but it pulls a ton of updates/and
> dependencies over stock Gentoo.

I tried and noticed. Too riskfull

> Doing a package.mask and only unmasking
> LibreOffice will reach a point where it won't install and won't tell you
> what else you need to unmask, so you have to bite the bullet and risk it.

I agree
Comment 51 Adrien Dessemond 2020-11-03 16:14:06 UTC
(In reply to Silvio from comment #50)
 
> [blocks B      ] app-office/libreoffice-l10n ("app-office/libreoffice-l10n"
> is blocking app-office/libreoffice-7.0.9999)
> 
> I cannot install it, it needs a masked updated version even of
> libreoffice-l10n

emerge -C app-office/libreoffice-l10n app-office/libreoffice 

(suggestion: build binaries packages of them first)

Then try to emerge 7.0.9999

You might also have to adjust your localization  variables (LINGUAS etc) to not pull in app-office/libreoffice-l10n per dependency. I am not using localized systems, what worked for me will require some tweaks for you.
Comment 52 andy 2020-11-03 16:28:25 UTC
Silvio 

libreoffice-7.0.9999 is a live ebuild and that mean it will not be updated.you have to update it your self,portage will not do any thing with it and you will never know when the compile will fail if libreoffice has done a change. it is better for you to use one from  pg_overlay or from mine "hedmos-overlay". this ebuilds is locked on a version release and will not change from day to day.
Comment 53 jospezial 2020-11-03 22:41:07 UTC
(In reply to Silvio from comment #49)
> (In reply to Adrien Dessemond from comment #48)
> > You can also emerge =app-office/libreoffice-7.0.9999 (you will have to
> > unmask it first).
> > 
> > You also might have to adjust your CFLAGS/CXXFLAGS variables to ensure clang
> > does not see unsupported compiler options, see the comment #35 above. As
> > suggested in comment #36, you also might have to remove clang,  recompile
> > LibreOffice and emerge clang again afterwards.
> 
> [blocks B      ] app-office/libreoffice-l10n ("app-office/libreoffice-l10n"
> is blocking app-office/libreoffice-7.0.9999)
> 
> I cannot install it, it needs a masked updated version even of
> libreoffice-l10n

The live ebuilds of libreoffice don't have a l10n package and the l10n package from causes incompatibilities.
Seen some calc functions in other language not did not work, maybe unrelated.
Would be nice if we could also use the translations from LO-git.
Comment 54 Arfrever Frehtes Taifersar Arahesis 2020-11-06 22:26:29 UTC
configure.ac respects CLANG_C and CLANG_CXX variables since this commit (included in 7.0):
https://git.libreoffice.org/core/+/647499ef8151d9383983f89230a970edcb44b5bb
https://git.libreoffice.org/core/+/647499ef8151d9383983f89230a970edcb44b5bb^!


configure.ac respects LO_CLANG_CC and LO_CLANG_CXX variables since this commit (included in 7.1):
https://git.libreoffice.org/core/+/5b0ca23615c3d0aae7083147bc3bb5d61db26f5e
https://git.libreoffice.org/core/+/5b0ca23615c3d0aae7083147bc3bb5d61db26f5e^!


Ebuild can force respecting compiler:
- In =app-office/libreoffice-7.0*:
    export CLANG_C="$(tc-getCC)"
    export CLANG_CXX="$(tc-getCXX)"
- In >=app-office/libreoffice-7.1 (currently only app-office/libreoffice-9999):
    export LO_CLANG_CC="$(tc-getCC)"
    export LO_CLANG_CXX="$(tc-getCXX)"


Currently users can try e.g.:
> CLANG_C="x86_64-pc-linux-gnu-gcc" CLANG_CXX="x86_64-pc-linux-gnu-g++" emerge -1 "=app-office/libreoffice-7.0*"
Comment 55 Silvio 2020-11-14 23:11:28 UTC
Any news about the possibility to have libreoffice 7 on gentoo?

It is not a secondary package.

If I could help in any way ...
Comment 56 Larry the Git Cow gentoo-dev 2020-11-17 17:23:13 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=af86e0e2f91da40999615ed71b6be7a5756690a4

commit af86e0e2f91da40999615ed71b6be7a5756690a4
Author:     Jason A. Donenfeld <zx2c4@gentoo.org>
AuthorDate: 2020-10-27 14:57:05 +0000
Commit:     Jason A. Donenfeld <zx2c4@gentoo.org>
CommitDate: 2020-11-17 17:17:38 +0000

    app-office/libreoffice: bump to 7.0.3.1
    
    Closes: https://bugs.gentoo.org/739134
    Package-Manager: Portage-3.0.8, Repoman-3.0.2
    Signed-off-by: Jason A. Donenfeld <zx2c4@gentoo.org>

 app-office/libreoffice-l10n/Manifest               | 168 ++++++
 .../libreoffice-l10n-7.0.3.1.ebuild                |  91 ++++
 app-office/libreoffice/Manifest                    |   3 +
 .../libreoffice-7.0.3.1-fix-non-pdfium-build.patch |  31 ++
 app-office/libreoffice/libreoffice-7.0.3.1.ebuild  | 592 +++++++++++++++++++++
 profiles/base/package.use.mask                     |   4 +
 6 files changed, 889 insertions(+)
Comment 57 Jason A. Donenfeld gentoo-dev 2020-11-17 17:24:24 UTC
I assume what I just pushed will need some work, but at least now we have a base to build on, instead of letting this rot on longer.
Comment 58 Larry the Git Cow gentoo-dev 2020-11-17 18:20:25 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c66a6cc5f3be619c2e2f6a97bcfda0613cb6ee5c

commit c66a6cc5f3be619c2e2f6a97bcfda0613cb6ee5c
Author:     Andreas Sturmlechner <asturm@gentoo.org>
AuthorDate: 2020-11-17 18:17:04 +0000
Commit:     Andreas Sturmlechner <asturm@gentoo.org>
CommitDate: 2020-11-17 18:20:12 +0000

    app-office/libreoffice: Revert "bump to 7.0.3.1"
    
    Not ACKed from office project. Drive-by commit without regard for Java
    dependencies or even the latest state of 7.0 stable branch ebuild and
    *known* issue wrt Skia and clang automagic.
    
    This reverts commit af86e0e2f91da40999615ed71b6be7a5756690a4.
    
    Bug: https://bugs.gentoo.org/739134
    Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org>

 app-office/libreoffice-l10n/Manifest               | 168 ------
 .../libreoffice-l10n-7.0.3.1.ebuild                |  91 ----
 app-office/libreoffice/Manifest                    |   3 -
 .../libreoffice-7.0.3.1-fix-non-pdfium-build.patch |  31 --
 app-office/libreoffice/libreoffice-7.0.3.1.ebuild  | 592 ---------------------
 profiles/base/package.use.mask                     |   4 -
 6 files changed, 889 deletions(-)
Comment 59 Andreas Sturmlechner gentoo-dev 2020-11-17 18:24:35 UTC
Jason, if you really wan't to help then don't commit an outdated ebuild but rather work with what is already here and most importantly test and try integrate Arfrever's clues with the ebuild. First live, then the release version bump.
Comment 60 andy 2020-11-17 19:31:08 UTC
Andreas Sturmlechner

I agree with you.as i have been working with libreoffice-7 for some Time now i have to say
That the ebuild in portage and pg_overlay is far from a working state (gentoo class) to use for libeoffice-7.just One example is skia... As skia use vulkan the ebuild
Needs to depend on vulkan provided in portage and if
someone like to use libreoffice-7 on older hardware
(No vulkan support or xf86-video-nouveau) there needs to be a use flag or something to regulate that. And to get
the best quality provided by libreoffice the ebuild
needs to depend on sys-devel/clang but i have to say that if the "hack" that Arfrever's comment had is ok for gentoo "standard" i think that One is a good thing to add as a use flag as well. And not to mention THE options that needs to be added/dropped.
Comment 61 Arfrever Frehtes Taifersar Arahesis 2020-11-18 10:04:12 UTC
Maybe alternatively it would make sense to add separate Skia package (probably media-gfx/skia) and modify build system of LibreOffice to use system Skia.

Skia package could have IUSE="+clang", and with USE="clang" it would use Clang.
Comment 62 andy 2020-11-18 10:29:06 UTC
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #61)
> Maybe alternatively it would make sense to add separate Skia package
> (probably media-gfx/skia) and modify build system of LibreOffice to use
> system Skia.
> 
> Skia package could have IUSE="+clang", and with USE="clang" it would use
> Clang.

about --system-skia i think it is a good idea but dont think it will be easy
to make that happend (i dont know).i have a skia ebuild that works and builds with both gcc and clang but libreoffice do not provide --system-skia.ATM i am using the "hack" from your comment 54 and providing it with USE=gcc-only as i am 
using lto .
Comment 63 Perfect Gentleman 2020-11-18 11:20:02 UTC
skia could controlled with USE=vulkan, but the main problem that LO-7 build system is terrible. LO-7 can be built with GCC + Clang'd skia only with limited set of CFLAGS. LTO can be hardly enable as enable LTO passed -flto=n which is not supported by Clang. LO-7 can be built with onle the one toolchain.
Comment 64 andy 2020-11-18 11:34:11 UTC
(In reply to Perfect Gentleman from comment #63)
> skia could controlled with USE=vulkan, but the main problem that LO-7 build
> system is terrible. LO-7 can be built with GCC + Clang'd skia only with
> limited set of CFLAGS. LTO can be hardly enable as enable LTO passed -flto=n
> which is not supported by Clang. LO-7 can be built with onle the one
> toolchain.

Perfect Gentleman

i do not fully understand you but i am controlling skia with USE=skia.And i am using libreoffice with LTO by controlling libreoffice to be build with gcc only
(USE=gcc-only) and the useflag adds:

	if use gcc-only; then
		# hack to force skia to be build with gcc and not clang...
		export LO_CLANG_CC="$(tc-getCC)"
		export LO_CLANG_CXX="$(tc-getCXX)"
	fi

to the build
Comment 65 Perfect Gentleman 2020-11-18 11:37:09 UTC
andy, that's what I'm telling: GCC or Clang only. You cannot use GCC+LTO for building while using Clang for building skia.
Comment 66 Perfect Gentleman 2020-11-18 11:38:42 UTC
>but i am controlling skia with USE=skia
vulkan is global flag, skis is local. there is no skia without vulkan afaik.
Comment 67 andy 2020-11-18 11:59:35 UTC
(In reply to Perfect Gentleman from comment #66)
> >but i am controlling skia with USE=skia
> vulkan is global flag, skis is local. there is no skia without vulkan afaik.

i know it fits better with :

	if use vulkan ; then
		myeconfargs+=( --enable-skia  )
	else
		myeconfargs+=( --disable-skia  )
	fi
Comment 68 Arfrever Frehtes Taifersar Arahesis 2020-11-18 12:11:56 UTC
When shared libraries are enabled in Skia, Skia provides 3 static libraries and 4 shared libraries:

 libparticles.a
 libpathkit.a
 libskresources.a

 libskia.so
 libskottie.so
 libsksg.so
 libskshaper.so


For using system Skia in LibreOffice, it would be necessary to change mainly:
https://git.libreoffice.org/core/+/47fda617fc4dad8273919227ca45ea3b8b61aea1/RepositoryExternal.mk#123

This line probably can be dropped:
https://git.libreoffice.org/core/+/808e8a8e9e96b6c3fac3ddf291e3900a40846409/external/Module_external.mk#98


Bundled Skia in LibreOffice is slightly patched.
System Skia would probably need at least "share-grcontext.patch.1":
https://git.libreoffice.org/core/+/bb4b538ff6c2b10d41784819224171df07910eaf/external/skia/README#30
https://git.libreoffice.org/core/+/7c1dc527837a65b77f7624e18a575271cb46afba/vcl/skia/README#71
https://git.libreoffice.org/core/+/319a03fe3975f24f1bccc88019a92217bc1df53b/external/skia/share-grcontext.patch.1
Comment 69 Iñigo 2020-11-19 08:40:24 UTC
So, a couple of days ago I made a system update, and happily see Libreoffice7 was on it (I currently have 7.0.3.1). Works fine for me. Now it wants to downgrade to version 6 again... Which I suppose I have to do because I accidentally deleted libeoffice-l10n v7 on a --depclean

What happened?
Comment 70 Silvio 2020-11-19 13:03:32 UTC
(In reply to Iñigo from comment #69)
> So, a couple of days ago I made a system update, and happily see
> Libreoffice7 was on it (I currently have 7.0.3.1). Works fine for me. Now it
> wants to downgrade to version 6 again... Which I suppose I have to do
> because I accidentally deleted libeoffice-l10n v7 on a --depclean
> 
> What happened?

It has been removed from portage for further stabilisation.
This is the reason why it proposes to you to downgrade.
Comment 71 Larry the Git Cow gentoo-dev 2020-11-21 15:08:11 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1e6582952369e1fd90f507f94853263ce07089c9

commit 1e6582952369e1fd90f507f94853263ce07089c9
Author:     Andreas K. Hüttel <dilfridge@gentoo.org>
AuthorDate: 2020-11-21 15:05:38 +0000
Commit:     Andreas K. Hüttel <dilfridge@gentoo.org>
CommitDate: 2020-11-21 15:07:57 +0000

    app-office/libreoffice: Version bump (no keywords, for testing)
    
    Bug: https://bugs.gentoo.org/739134
    Package-Manager: Portage-3.0.9, Repoman-3.0.2
    Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>

 app-office/libreoffice/Manifest                    |   2 +
 app-office/libreoffice/libreoffice-7.0.3.1.ebuild  | 650 +++++++++++++++++++++
 app-office/libreoffice/libreoffice-7.0.9999.ebuild |  54 +-
 app-office/libreoffice/libreoffice-9999.ebuild     |  54 +-
 app-office/libreoffice/metadata.xml                |   2 +
 5 files changed, 758 insertions(+), 4 deletions(-)

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f8d4ec8bdce3f0b8da94d158c9ffe57361779cbc

commit f8d4ec8bdce3f0b8da94d158c9ffe57361779cbc
Author:     Andreas K. Hüttel <dilfridge@gentoo.org>
AuthorDate: 2020-11-21 15:01:06 +0000
Commit:     Andreas K. Hüttel <dilfridge@gentoo.org>
CommitDate: 2020-11-21 15:07:53 +0000

    app-office/libreoffice-l10n: Version bump (no keywords, for testing)
    
    Bug: https://bugs.gentoo.org/739134
    Package-Manager: Portage-3.0.9, Repoman-3.0.2
    Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>

 app-office/libreoffice-l10n/Manifest               | 183 +++++++++++++++++++++
 app-office/libreoffice-l10n/files/lo_gen_langs.sh  |  12 +-
 .../libreoffice-l10n-7.0.3.1.ebuild                |  91 ++++++++++
 profiles/desc/l10n.desc                            |   3 +
 4 files changed, 283 insertions(+), 6 deletions(-)
Comment 72 Andreas K. Hüttel archtester gentoo-dev 2020-11-21 15:10:07 UTC
Please test with and without USE=clang

I can only do limited testing myself at the moment since I hard-rely on a functioning LO Impress until christmas.
Comment 73 andy 2020-11-21 17:51:12 UTC
USE=-clang/clang does not work for me:

clang-11: error: unknown argument: '-fgraphite-identity'
clang-11: error: unknown argument: '-floop-nest-optimize'
clang-11: error: unknown argument: '-fdevirtualize-at-ltrans'
clang-11: error: unknown argument: '-fipa-pta'
clang-11: error: unsupported argument '16' to option 'flto='
clang-11: error: unknown argument: '-fgraphite-identity'
clang-11: error: unknown argument: '-floop-nest-optimize'
clang-11: error: unknown argument: '-fdevirtualize-at-ltrans'
clang-11: error: unknown argument: '-fipa-pta'
clang-11: error: unsupported argument '16' to option 'flto='
Comment 74 andy 2020-11-21 17:59:39 UTC
as you have bumped libreoffice-7.0.3.1 i think you have to set :

line:406 export CLANG_C="$(tc-getCC)"
line:407 export CLANG_CXX="$(tc-getCXX)"
Comment 75 Larry the Git Cow gentoo-dev 2020-11-21 19:02:07 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a6e8979afea92806e9f3b469c37822a1f80e6a6f

commit a6e8979afea92806e9f3b469c37822a1f80e6a6f
Author:     Andreas K. Hüttel <dilfridge@gentoo.org>
AuthorDate: 2020-11-21 18:51:50 +0000
Commit:     Andreas K. Hüttel <dilfridge@gentoo.org>
CommitDate: 2020-11-21 19:01:50 +0000

    app-office/libreoffice: Use CLANG_CC in 7.0 branch
    
    Bug: https://bugs.gentoo.org/739134
    Package-Manager: Portage-3.0.9, Repoman-3.0.2
    Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>

 app-office/libreoffice/libreoffice-7.0.3.1.ebuild  | 4 ++--
 app-office/libreoffice/libreoffice-7.0.9999.ebuild | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)
Comment 76 andy 2020-11-21 20:09:41 UTC
(In reply to Larry the Git Cow from comment #75)
> The bug has been referenced in the following commit(s):
> 
> https://gitweb.gentoo.org/repo/gentoo.git/commit/
> ?id=a6e8979afea92806e9f3b469c37822a1f80e6a6f
> 
> commit a6e8979afea92806e9f3b469c37822a1f80e6a6f
> Author:     Andreas K. Hüttel <dilfridge@gentoo.org>
> AuthorDate: 2020-11-21 18:51:50 +0000
> Commit:     Andreas K. Hüttel <dilfridge@gentoo.org>
> CommitDate: 2020-11-21 19:01:50 +0000
> 
>     app-office/libreoffice: Use CLANG_CC in 7.0 branch
>     
>     Bug: https://bugs.gentoo.org/739134
>     Package-Manager: Portage-3.0.9, Repoman-3.0.2
>     Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
> 
>  app-office/libreoffice/libreoffice-7.0.3.1.ebuild  | 4 ++--
>  app-office/libreoffice/libreoffice-7.0.9999.ebuild | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)

mybox /home/hedmo # rm /var/cache/distfiles/libreoffice-branding-gentoo-0.8.tar.xz
mybox /home/hedmo # emerge -av =libreoffice-7.0.3.1                             
 * IMPORTANT: 1 news items need reading for repository 'gentoo'.
 * Use eselect news read to view new items.


These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild     UD*] app-office/libreoffice-7.0.3.1::gentoo [7.1.0.0_alpha1::hedmos-overlay] USE="bluetooth branding cups dbus gtk java kde mariadb vulkan -accessibility -base -clang% -coinmp -debug -eds -firebird -googledrive -gstreamer -ldap -odk -pdfimport -postgres -test (-gcc-only%*)" LIBREOFFICE_EXTENSIONS="-nlpsolver -scripting-beanshell -scripting-javascript -wiki-publisher" PYTHON_SINGLE_TARGET="python3_7 -python3_6 -python3_8 -python3_9%" 0 KiB
[ebuild  N    *] app-office/libreoffice-l10n-7.0.3.1::gentoo  USE="-offlinehelp" L10N="-af -am -ar -as -ast -be -bg -bn -bn-IN -bo -br -brx -bs -ca -ca-valencia -ckb -cs -cy -da -de -dgo -dsb -dz -el -en -en-GB -en-ZA -eo -es -et -eu -fa -fi -fr -fur -fy -ga -gd -gl -gu -gug -he -hi -hr -hsb -hu -id -is -it -ja -ka -kab -kk -km -kmr-Latn -kn -ko -kok -ks -lb -lo -lt -lv -mai -mk -ml -mn -mni -mr -my -nb -ne -nl -nn -nr -nso -oc -om -or -pa -pl -pt -pt-BR -ro -ru -rw -sa -sat -sd -si -sid -sk -sl -sq -sr -sr-Latn -ss -st -sv -sw-TZ -szl -ta -te -tg -th -tn -tr -ts -tt -ug -uk -uz -ve -vec -vi -xh -zh-CN -zh-TW -zu" 0 KiB

Total: 2 packages (1 downgrade, 1 new), Size of downloads: 0 KiB

Would you like to merge these packages? [Yes/No] 
>>> Verifying ebuild manifests
>>> Running pre-merge checks for app-office/libreoffice-7.0.3.1
 * If you plan to use Base application you must enable USE base.
 * Checking for at least 512 MiB RAM ...                                 [ ok ]
 * Checking for at least 6 GiB disk space at "/var/tmp/portage/app-office/libreoffice-7.0.3.1/temp" ...                                                  [ ok ]
>>> Emerging (1 of 2) app-office/libreoffice-7.0.3.1::gentoo
>>> Failed to emerge app-office/libreoffice-7.0.3.1, Log file:
>>>  '/var/tmp/portage/app-office/libreoffice-7.0.3.1/temp/build.log'
>>> Jobs: 0 of 2 complete, 1 failed                 Load avg: 0.82, 1.15, 1.33
!!! Fetched file: libreoffice-branding-gentoo-0.8.tar.xz VERIFY FAILED!
!!! Reason: Insufficient data for checksum verification
!!! Got:      
!!! Expected: BLAKE2B BLAKE2S MD5 RMD160 SHA1 SHA256 SHA3_256 SHA3_512 SHA512 WHIRLPOOL
 * Fetch failed for 'app-office/libreoffice-7.0.3.1', Log file:
 *  '/var/tmp/portage/app-office/libreoffice-7.0.3.1/temp/build.log'

 * Messages for package app-office/libreoffice-7.0.3.1:

 * If you plan to use Base application you must enable USE base.

 * Messages for package app-office/libreoffice-7.0.3.1:

 * Fetch failed for 'app-office/libreoffice-7.0.3.1', Log file:
 *  '/var/tmp/portage/app-office/libreoffice-7.0.3.1/temp/build.log'
mybox /home/hedmo #
Comment 77 andy 2020-11-21 22:40:41 UTC
(In reply to Larry the Git Cow from comment #75)
> The bug has been referenced in the following commit(s):
> 
> https://gitweb.gentoo.org/repo/gentoo.git/commit/
> ?id=a6e8979afea92806e9f3b469c37822a1f80e6a6f
> 
> commit a6e8979afea92806e9f3b469c37822a1f80e6a6f
> Author:     Andreas K. Hüttel <dilfridge@gentoo.org>
> AuthorDate: 2020-11-21 18:51:50 +0000
> Commit:     Andreas K. Hüttel <dilfridge@gentoo.org>
> CommitDate: 2020-11-21 19:01:50 +0000
> 
>     app-office/libreoffice: Use CLANG_CC in 7.0 branch
>     
>     Bug: https://bugs.gentoo.org/739134
>     Package-Manager: Portage-3.0.9, Repoman-3.0.2
>     Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
> 
>  app-office/libreoffice/libreoffice-7.0.3.1.ebuild  | 4 ++--
>  app-office/libreoffice/libreoffice-7.0.9999.ebuild | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)

sorry Andreas K. Hüttel

still fails with :

clang-11: error: unknown argument: '-fgraphite-identity'
clang-11: error: unknown argument: '-floop-nest-optimize'
clang-11: error: unknown argument: '-fdevirtualize-at-ltrans'
clang-11: error: unknown argument: '-fipa-pta'
clang-11: error: unsupported argument '16' to option 'flto='

i am just using :

	if ! use clang; then
		# hack to force skia to be build with gcc and not clang...
		einfo "Enforcing the use of gcc due to USE=-clang ..."
		export LO_CLANG_CC="$(tc-getCC)"
		export LO_CLANG_CXX="$(tc-getCXX)"
	fi

in my libreoffice-7.1.0.0_alpha1.ebuild and that works
Comment 78 Andreas K. Hüttel archtester gentoo-dev 2020-11-21 23:07:22 UTC
Could you add the start of the build log please? The configure phase is enough.
Comment 79 Andreas K. Hüttel archtester gentoo-dev 2020-11-21 23:09:22 UTC
(In reply to Andreas K. Hüttel from comment #78)
> Could you add the start of the build log please? The configure phase is
> enough.

Forget it, I think I understand the problem.
Comment 80 Larry the Git Cow gentoo-dev 2020-11-21 23:27:54 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f9e9a8666cd4b64a01bf3f6dcf585e8c4e1dec14

commit f9e9a8666cd4b64a01bf3f6dcf585e8c4e1dec14
Author:     Andreas K. Hüttel <dilfridge@gentoo.org>
AuthorDate: 2020-11-21 23:24:25 +0000
Commit:     Andreas K. Hüttel <dilfridge@gentoo.org>
CommitDate: 2020-11-21 23:27:36 +0000

    app-office/libreoffice: Brute-force compiler settings (clang/gcc)
    
    Bug: https://bugs.gentoo.org/739134
    Package-Manager: Portage-3.0.9, Repoman-3.0.2
    Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>

 app-office/libreoffice/libreoffice-7.0.3.1.ebuild  | 26 +++++++++-------------
 app-office/libreoffice/libreoffice-7.0.9999.ebuild | 26 +++++++++-------------
 app-office/libreoffice/libreoffice-9999.ebuild     | 26 +++++++++-------------
 3 files changed, 30 insertions(+), 48 deletions(-)
Comment 81 Perfect Gentleman 2020-11-22 05:48:35 UTC
imho, it's not a good idea to implement USE=clang.
Firstly, anyone who uses LLVM/Clang as system toolchain will build LO-7 with LLVM/Clang anyway.
Secondly, when GCC is system toolchain and USE=clang is used then lots of deps should be re-built with LLVM/Clang.
Comment 82 andy 2020-11-22 07:35:01 UTC
(In reply to  comment #80)
> commit f9e9a8666cd4b64a01bf3f6dcf585e8c4e1dec14
> Author:     Andreas K. Hüttel <dilfridge@gentoo.org>
> AuthorDate: 2020-11-21 23:24:25 +0000
> Commit:     Andreas K. Hüttel <dilfridge@gentoo.org>
> CommitDate: 2020-11-21 23:27:36 +0000
> 
>     app-office/libreoffice: Brute-force compiler settings (clang/gcc)

the changes worked for me now. USE=-clang make you to compile with 
custom cflags. 


i'd buy that for a dollar :)
Comment 83 Andreas Sturmlechner gentoo-dev 2020-11-22 08:05:45 UTC
(In reply to Perfect Gentleman from comment #81)
> imho, it's not a good idea to implement USE=clang.
> Firstly, anyone who uses LLVM/Clang as system toolchain will build LO-7 with
> LLVM/Clang anyway.
I dislike that flag as much as you do, but if we take upstream serious then there is legitimate interest to make that flag and the relation to skia/vulkan visible to the user.

(In reply to Perfect Gentleman from comment #81)
> Secondly, when GCC is system toolchain and USE=clang is used then lots of
> deps should be re-built with LLVM/Clang.
As a matter of principle or is there any problem you would see arise?
Comment 84 andy 2020-11-22 08:24:29 UTC
(In reply to Andreas Sturmlechner from comment #83)
> (In reply to Perfect Gentleman from comment #81)
> > imho, it's not a good idea to implement USE=clang.
> > Firstly, anyone who uses LLVM/Clang as system toolchain will build LO-7 with
> > LLVM/Clang anyway.
> I dislike that flag as much as you do, but if we take upstream serious then
> there is legitimate interest to make that flag and the relation to
> skia/vulkan visible to the user.
> 
> (In reply to Perfect Gentleman from comment #81)
> > Secondly, when GCC is system toolchain and USE=clang is used then lots of
> > deps should be re-built with LLVM/Clang.
> As a matter of principle or is there any problem you would see arise?

i think Perfect Gentleman got a point because USE=clang will force libreoffice to be build with clang and not only skia. i did try to compile libreoffice with USE=clang now and it fails. i think i will rename the useflag to :

 clang -> custom-cflags 

and skip :

if use clang ; then
		# Force clang
		einfo "Enforcing the use of clang due to USE=clang ..."
		AR=llvm-ar
		CC=${CHOST}-clang
		CXX=${CHOST}-clang++
		NM=llvm-nm
		RANLIB=llvm-ranlib
		LDFLAGS+=" -fuse-ld=lld"
		strip-unsupported-flags
Comment 85 Perfect Gentleman 2020-11-22 11:05:21 UTC
(In reply to Andreas Sturmlechner from comment #83)
> As a matter of principle or is there any problem you would see arise?
As andy wrote below for now LO-7 fails with USE=clang. For building with LLVM/Clang some deps should be built with LLVM/Clang also which leads to problems when packages built with GCC needs those deps to be built with GCC otherwise they fail during building or on start.
Comment 86 Mike Lothian 2020-11-22 11:43:26 UTC
Which packages have issues with being built with different compilers?

The only packages I currently compile with Clang regularly are Chromium and Mesa

If there are issues it might be worth reporting bugs upsteam
Comment 87 Perfect Gentleman 2020-11-22 12:09:26 UTC
(In reply to Mike Lothian from comment #86)
> Which packages have issues with being built with different compilers?
> 
> The only packages I currently compile with Clang regularly are Chromium and
> Mesa
> 
> If there are issues it might be worth reporting bugs upsteam

you'd be laughing but lots of them: from sys-libs to DE and its applications.
Comment 88 andy 2020-11-22 12:47:58 UTC
(In reply to Mike Lothian from comment #86)
> Which packages have issues with being built with different compilers?
> 
> The only packages I currently compile with Clang regularly are Chromium and
> Mesa
> 
> If there are issues it might be worth reporting bugs upsteam

from my point of view i don think the problem is which compiler to use but the cflags you have set in make.conf. I am using lto and gcc  which make libreoffice
to fail when it tries to build skia. when i am trying to build libreoffice with 
USE=clang it fails with :

checking whether x86_64-pc-linux-gnu-clang++ defines __si_class_type_info in cxxabi.h... yes
checking whether x86_64-pc-linux-gnu-clang++ defines __vmi_class_type_info in cxxabi.h... yes
checking that x86_64-pc-linux-gnu-clang++ supports __attribute__((warn_unused))... configure: error: no

and to be straight up simple... i quote Andreas K. Hüttels commit:

  app-office/libreoffice: Brute-force compile with :
  CFLAGS="-O2 -pipe -march=native"
  CXXFLAGS="${CFLAGS}"

and the problem is gone.
Comment 89 Mike Lothian 2020-11-22 12:56:34 UTC
I use the following env overrides to compile with Clang and LTO

https://github.com/FireBurn/PortageStuff/blob/master/env/clango3lto.conf
Comment 90 Andreas K. Hüttel archtester gentoo-dev 2020-11-22 13:08:09 UTC
If the build fails for you, then please add the following here:

* your useflag settings
* your emerge --info output
* and at least the last lines of the build log that show the *error* (may require some searching)

Otherwise there's nothing to do here.

Yes I realize that USE=clang may go against the rest of the system. Point is, if you think this makes problems, don't select it.

Because of stupid amazon sponsorship being in limbo I have only limited cycles available at the moment. USE=-clang built fine, USE=clang is still running.
Comment 91 Andreas K. Hüttel archtester gentoo-dev 2020-11-22 13:09:59 UTC
P.S. 
If you want to discuss this in realtime feel free to join channel #gentoo-office on freenode. I'll be back around 17:00 EET (that's 15:00 UTC).
Comment 92 Perfect Gentleman 2020-11-22 13:21:45 UTC
andy is right. it depends on which optimization CFLAGS are used. ThinLTO+LLD is definitely breaks when Gpaphite+LTO is used. If SAFE CFLAGS are used, I think it's okay on matter which toolchain is used.

FYI, I use heavy optimizations, i.e. Graphite+LTO+Sections in GCC and ThinLTO+LLD+Polly+Sections in LLVM/Clang.
Comment 93 Andreas Sturmlechner gentoo-dev 2020-11-22 16:56:22 UTC
LO-7[clang] build just finished successfully, runs fine.
Comment 94 Larry the Git Cow gentoo-dev 2020-11-22 17:08:03 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=758a966d8fd830f30822335baad033f439e5a1ad

commit 758a966d8fd830f30822335baad033f439e5a1ad
Author:     Andreas K. Hüttel <dilfridge@gentoo.org>
AuthorDate: 2020-11-22 17:07:07 +0000
Commit:     Andreas K. Hüttel <dilfridge@gentoo.org>
CommitDate: 2020-11-22 17:07:49 +0000

    app-office/libreoffice: Re-add keywords to 7.0.3.1
    
    Closes: https://bugs.gentoo.org/739134
    Package-Manager: Portage-3.0.9, Repoman-3.0.2
    Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>

 app-office/libreoffice/libreoffice-7.0.3.1.ebuild | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
Comment 95 Andreas K. Hüttel archtester gentoo-dev 2020-11-22 17:08:38 UTC
Please report future issues in separate bugs. Thanks!!!
Comment 96 Mike Lothian 2020-11-25 13:01:07 UTC
Not an issue just an FYI for people testing this

I have to use SAL_FORCESKIA=1 to get Skia working at all on my machine

More environment variables:

AL_DISABLESKIA=1 - force disabled Skia
SAL_ENABLESKIA=1 - enable Skia, unless blacklisted (and if the VCL backend supports Skia)
SAL_FORCESKIA=1 - force using Skia, even if blacklisted
SAL_SKIA=raster|vulkan - select Skia's drawing method, by default Vulkan is used

There also also GUI options for controlling whether Skia is enabled.

Note that many backends do not use Skia. E.g. on Linux it is necessary to also use
SAL_USE_VCLPLUGIN=gen .

Skia drawing methods:
=====================

Skia supports several methods to draw:
- Raster - CPU-based drawing (here primarily used for debugging)
- Vulkan - Vulkan-based GPU drawing, this is the default

There are more (OpenGL, Metal on Mac, etc.), but (as of now) they are not supported by VCL.