[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Porting libreoffice to riscv64 arch



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



Reply to: