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

Re: Porting libreoffice to riscv64 arch

On Thu, May 12, 2022 at 08:28:26PM +0200, Rene Engelhard wrote:

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

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

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!




Reply to: