Re: Porting libreoffice to riscv64 arch
Hi,
On Thu, May 12, 2022 at 08:28:26PM +0200, Rene Engelhard wrote:
Hi,
Am 12.05.22 um 15:35 schrieb Bo YU:
I am trying to build libreoffice packages on riscv64 arch.
With the attached patches, I can run LibreOffice building
configuration partly.
- You patch configure. Why? It is a generated file.
Ok, I am wrong with here and i will look here again.
(and it contains some Windows thingies while configure.ac does not...)
- You didn't adapt any of the *_ARCHS variables in debian/rules. (And
that one is a hand-edited list on architectures LO is supposed to work
on/did in the past, see below)
Yeah. Sorry I don't display it in the patch.
It's a little tricky for me to put diff of d/* and diff of out of d/* into
one patch.
The full log is here: https://github.com/yuzibo/debian_dev/blob/main/0003-libreoffice-configure-log
I don't actually see a serious error here?
When I try to fix the other error from the configure log, but I am
lost in d/control file,
It's better to look at debian/rules and the variables/gazillions of
ifs here. debian/control is generated.
Wrt your error..
You mean clang? Ideally you get a clang here and then it will be
there. See also
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963109.
In this case it's a new architecture so I'd be less strict. You can
set ALLOW_CLANG=n in rules and ignore the "error"...
Ok, will do.
Besides that I don't see an error here.
I think the dependences of libreoffice had been met but need reduce
or exclude some build-deps such others arch. But I am not sure how
to deal with it.
Could you have a look? I have real riscv64 hardware by hand so I can
do more
tests.
What happens in the further build?
Oh, Opps, my bad, sorry again. The key informations is missing in the log file:
```
...
* WARNING : OpenSSL has been disabled. No code compiled here will make use of it but system libraries may create indirect dependencies
PATH=/<<PKGBUILDDIR>>/debian/usr/bin:/<<PKGBUILDDIR>>/debian/usr/bin:$PATH LD_LIBRARY_PATH= ARCH_FLAGS= TMP=`mktemp -q -d` /usr/bin/make build-non-l10n-only
make[2]: Entering directory '/<<PKGBUILDDIR>>'
Automatic fetching of external tarballs is disabled.
mkdir -p /<<PKGBUILDDIR>>/instdir
/<<PKGBUILDDIR>>/solenv/bin/install-gdb-printers -a /<<PKGBUILDDIR>>/instdir -c
/usr/bin/make -j 16 -r -f /<<PKGBUILDDIR>>/Makefile.gbuild build-non-l10n-only
make[3]: Entering directory '/<<PKGBUILDDIR>>'
/<<PKGBUILDDIR>>/solenv/gbuild/UnoApiTarget.mk:127: *** gb_UnoApiHeadersTarget_select_variant must be defined by platform. Stop.
make[3]: Leaving directory '/<<PKGBUILDDIR>>'
make[2]: *** [Makefile:276: build] Error 2
make[2]: Leaving directory '/<<PKGBUILDDIR>>'
make[1]: *** [/<<PKGBUILDDIR>>/debian/rules:2081: debian/stampdir/build-arch] Error 2
make[1]: Leaving directory '/<<PKGBUILDDIR>>'
make: *** [debian/rules:2072: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
--------------------------------------------------------------------------------
Build finished at 2022-05-12T11:13:41Z
```
It hints the gb_UnoApiHeadersTarget_select_variant should be defined on this platform.
Should I disable it?
You should definitely get a failure at bridges I guess ;-):
unfortunately, it seems that does not come to threr :(
You definitely have porting work before you. See e.g. https://cgit.freedesktop.org/libreoffice/core/tree/bridges/source/cpp_uno/gcc3_linux_aarch64
for arm64. You need to know the ABI and calling conventions.
Ok, thank you for this valuable info, will look.
(And no, unfortunately I can't help you in that, only to get it to
apply and (maybe) build system issues)
Thank you again!
Bo
Regards,
Rene
Reply to: