Hi,
Am 24.05.22 um 02:37 schrieb Bo YU:
Hi,
On Mon, May 23, 2022 at 06:34:38PM +0200, Rene Engelhard wrote:
Hi,
Am 23.05.22 um 09:24 schrieb Bo YU:
Thank you. And we now go a step further:
```
ifeq ($(ENABLE_LTO),TRUE)
ifeq ($(COM_IS_CLANG),TRUE)
gb_LTOFLAGS := -flto=thin
Yes, this is somehow misleading. It seems that COM_IS_CLANG is set
nervertheless. Should be fixed, but since all archs in Debian *do*
have clang and that one is used this wasn't yet an issue.
And I disbale CLANG in d/rule:
```
# generally use clang
USE_CLANG=n
# allow clang for skia?
ALLOW_CLANG=n
CLANG_VERSION=default
```
Which is in effect since the error message clearly says g++.
not using clang is the exception from the rule.
You can set ENABLE_LTO=n to get it built without LTO, though.
Ok, my fix is very buggly:
```
ifeq "$(ENABLE_MERGELIBS)" "y"
# vimer: fix
ENABLE_LTO=n
else
ENABLE_LTO=n
endif
```
No worry, I do that in quick tests all the time :)
Well enough. Because `ENABLE_LTO` will affect LTO only in here. it would
be better to disable LTO depend on ARCH.
Yup. Or (temporarily) add a exception for risvc64 here.
We do have one already for mips64el, see
https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/blob/master/rules#L676
ff.
(Strictly speaking LTO is already depending on arch, since it's only
done when doing MERGELIBS, which means only on 64bit :-)
Luckily, We got the *bridge* part:
[...]
There we arrive in regions I cannot help with...
You are the porter. ;-)
Regards,
Rene
