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

Re: [libreoffice-users] Re: Building libreoffice with clang on ppc64


On 22/10/2019 18:28, Piotr Kubaj wrote:
Here's the backtrace. The process that segfaults is gengan.bin:
#0 0x000000081baea134 in (anonymous namespace)::cpp_mediate(unsigned long, void**, void**, long, long*)
(nOffsetAndIndex=60434681040, gpreg=0x3ffffffffffef830, fpreg=0x3ffffffffffef7c8, sp=4611686018427320272, pRegisterReturn=0x3ffffffffffef7b8)
at bridges/source/cpp_uno/gcc3_linux_powerpc64/cpp2uno.cxx:396
#1 0x000000081bae9f50 in privateSnippetExecutor() () at bridges/source/cpp_uno/gcc3_linux_powerpc64/cpp2uno.cxx:563
#2 0x00000008121de234 in cppu::throwException(com::sun::star::uno::Any const&)Python Exception <class 'gdb.error'> No type named 挀漀洀⸀猀甀渀⸀猀琀愀爀⸀甀挀戀⸀䤀渀琀攀爀愀挀琀椀瘀攀
䄀甀最洀攀渀琀攀搀䤀伀䔀砀挀攀瀀琀椀漀渀.:
(exc=) at cppuhelper/source/exc_thrower.cxx:207
#3 0x000000081672ebd4 in ucbhelper::cancelCommandExecution(com::sun::star::ucb::IOErrorCode, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&, com::sun::star::uno::Reference<com::sun::star::ucb::XCommandEnvironment> const&, rtl::OUString const&, com::sun::star::uno::Reference<com::sun::star::ucb::XCommandProcessor> const&)
(eError=com::sun::star::ucb::IOErrorCode::IOErrorCode_NOT_EXISTING, rArgs=
uno::Sequence of length 2 = {...}, xEnv=empty uno::Reference, rMessage="an error occurred during file opening", xContext=uno::Reference to (fileaccess::BaseContent *) 0x81d0b5258) at ucbhelper/source/provider/cancelcommandexecution.cxx:109

So this smells like it is indeed related to the changes in your below patch. (The code is about synthesizing a C++ `throw some_exception` expression, which may require synthesizing RTTI for the type of `some_exception` in RTTI::getRTTI in bridges/source/cpp_uno/gcc3_linux_powerpc64/except.cxx, which would need definitions of __cxxabiv1::__class_type_info and __cxxabiv1::__si_class_type_info.) But hard to tell what exactly is going wrong without actually debugging it.

On 19-10-21 21:38:29, Piotr Kubaj wrote:
I'm trying to build LibreOffice 6.3.2 on FreeBSD/powerpc64 with LLVM 9.0.0 (elfv2 ABI).

My problem is that I'm getting those errors https://pastebin.com/dKAY28ns

I tried to patch them with https://pastebin.com/66Xhi1D1 using similar code to x86-64. But then I'm getting a segfault at postcmd stage at the end of compilation.

I would assume that something about the definitions of __cxxabiv1::__class_type_info and __cxxabiv1::__si_class_type_info you added to bridges/source/cpp_uno/gcc3_linux_powerpc64/share.hxx does not match the definitions actually used by the system.

LibreOffice builds just fine with GCC 9.2, but this is still on elfv1. FreeBSD/powerpc* switches to LLVM for elfv2.

So where does such a GCC-based build find definitions of __cxxabiv1::__class_type_info and __cxxabiv1::__si_class_type_info (in some system header)? How do those definitions differ from those you now added to bridges/source/cpp_uno/gcc3_linux_powerpc64/share.hxx?


--
To unsubscribe e-mail to: users+unsubscribe@global.libreoffice.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/users/
Privacy Policy: https://www.documentfoundation.org/privacy

Follow-Ups:
Re: [libreoffice-users] Re: Building libreoffice with clang on ppc64Piotr Kubaj <pkubaj@anongoth.pl>
Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.