During the build I'm getting the same error as Mark Wright in Bug 713574, Comment 7: Work on gallery 'file:///var/tmp/portage/app-office/libreoffice-6.4.6.2-r2/work/libreoffice-6.4.6.2/workdir/Gallery/education' Existing themes: 0 /bin/sh: line 1: 17402 Segmentation fault ( LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program" $I/program/gengal.bin --build-tree --destdir file://$S/extras/source/gallery --name "education" --path $W/Gallery/education --filenames file://$RESPONSEFILE ) make[1]: *** [/var/tmp/portage/app-office/libreoffice-6.4.6.2-r2/work/libreoffice-6.4.6.2/solenv/gbuild/Gallery.mk:55: /var/tmp/portage/app-office/libreoffice-6.4.6.2-r2/work/libreoffice-6.4.6.2/workdir/Gallery/education.done] Error 139 I don't know how to get debugging information turned on, but I managed to get the segfault's backtrace (roughly the same as in Bug 713574, Comment 15): * frame #0: 0x00007ffff7fc114b libgcc3_uno.so`gcc3::deleteException(void*) + 43 frame #1: 0x00007ffff3d0d8ec libc++abi.so.1`__cxa_end_catch + 204 frame #2: 0x00007ffff6985dbf libmergedlo.so`FileExists(INetURLObject const&) + 463 frame #3: 0x00007ffff6980fbb libmergedlo.so`GalleryThemeEntry::ImplGetURLIgnoreCase(INetURLObject const&) + 91 frame #4: 0x00007ffff6980697 libmergedlo.so`GalleryThemeEntry::GalleryThemeEntry(bool, INetURLObject const&, rtl::OUString const&, bool, bool, unsigned int, bool) + 567 frame #5: 0x00007ffff69837c1 libmergedlo.so`Gallery::CreateTheme(rtl::OUString const&) + 337 frame #6: 0x000000000020744f gengal.bin`GalApp::Main() + 2719 frame #7: 0x00007ffff75a37f5 libmergedlo.so`ImplSVMain() + 101 frame #8: 0x00000000002090da gengal.bin`main + 26 frame #9: 0x00007ffff39decfe libc.so.6`__libc_start_main + 238 frame #10: 0x00000000002059aa gengal.bin`_start + 42 As before, it is within [[libgcc3_uno.so`gcc3::deleteException(void*)]], but optimizations probably inlined the call to [[libgcc3_uno.so`std::type_info::name(this=0x0000000000000000) const]]. Here's upstream's fix <https://cgit.freedesktop.org/libreoffice/core/commit/?id=986bd28388df745dd969e7be7c3bda36b2b2cb0e>, which I've found is applied. Basically what it does is (I mean, I think this is exactly what it does): #if defined _LIBCPPABI_VERSION if ((*(void **)header == nullptr) header++; #endif But for whatever reason, it seems that this condition isn't triggered. Reproducible: Always
Created attachment 663313 [details] emerge --info
Created attachment 663316 [details] build.log.xz
Created attachment 668759 [details, diff] libreoffice-clang.patch Try that patch (libreoffice-clang.patch).
(In reply to Perfect Gentleman from comment #3) > Created attachment 668759 [details, diff] [details, diff] > libreoffice-clang.patch > > Try that patch (libreoffice-clang.patch). It worked with Clang-11 and LO-7
(In reply to Perfect Gentleman from comment #4) > (In reply to Perfect Gentleman from comment #3) > > Created attachment 668759 [details, diff] [details, diff] [details, diff] > > libreoffice-clang.patch > > > > Try that patch (libreoffice-clang.patch). > > It worked with Clang-11 and LO-7 Please clarify: * the patch is needed for clang-11 and lo-7, or * the patch is not needed anymore for clang-11 and lo-7 ?
(In reply to Andreas K. Hüttel from comment #5) > (In reply to Perfect Gentleman from comment #4) > > (In reply to Perfect Gentleman from comment #3) > > > Created attachment 668759 [details, diff] [details, diff] [details, diff] [details, diff] > > > libreoffice-clang.patch > > > > > > Try that patch (libreoffice-clang.patch). > > > > It worked with Clang-11 and LO-7 > > Please clarify: > * the patch is needed for clang-11 and lo-7, or > * the patch is not needed anymore for clang-11 and lo-7 ? the patch is needed for clang-11 and lo-7
Created attachment 675073 [details, diff] clang-11/llvm-11 libreoffic patch This patch works for me utilizing clang-11 + llvm-11 toolset
Created attachment 677806 [details, diff] libreoffice-6.4.6.2-llvm-10-deleteException.patch I noted before that the segmentation fault occurs in deleteException(). When reading through the implementation in 7.1 (no earlier), I found that it does take LLVM 10 into account: https://github.com/LibreOffice/core/blob/libreoffice-7-1/bridges/source/cpp_uno/gcc3_linux_x86-64/except.cxx#L114-L135 Introduced in: https://github.com/LibreOffice/core/commit/cc5a6c6afeed1d2cf76d288133971d29ee8d893e The patch 'libreoffice-6.4.6.2-llvm-10.patch' seems to have missed this change, which explains why it is insufficient, and why dannftk@yandex.ru had to use a hack: https://gitweb.gentoo.org/repo/gentoo.git/tree/app-office/libreoffice/files/libreoffice-6.4.6.2-llvm-10.patch?id=947faddaa0c012fe78adaf3fb3d0d1f1fde2be4e The GitHub commit above doesn't apply cleanly, but I modified it and libreoffice-6.4.6.2 and 6.4.7.2 build successfully.
Created attachment 678010 [details, diff] libreoffice-7.0.3.1-llvm-10-deleteException.patch Also, I've noticed that the ebuild for 7.0.3.1 is missing the LLVM 10 patches. 7.0.3.1 will need: * libreoffice-6.4.6.2-llvm-10.patch (exists) * This patch (updated from previous one to apply cleanly) * The next patch for libc++ 11 changes.
Created attachment 678013 [details, diff] libreoffice-7.0.3.1-libcxx11.patch As mentioned above, this adds two missing headers. It builds fine now.
What about LO 7.0.4.2 ? Does it need anything from here ?
(In reply to Joakim Tjernlund from comment #11) > What about LO 7.0.4.2 ? Does it need anything from here ? I rebuilt LO 7.0.4.2 with libreoffice-6.4.6.2-llvm-10.patch and libreoffice-7.0.3.1-libcxx11.patch ( one didn't apply) and now I got a crash less when double clicking on an Draw img embedded into a word docx. Is libreoffice-7.0.3.1-llvm-10-deux.patch not needed for 7.0.4.2 or did I just get lucky?
LO-7.1.1.1 builds with Clang-11.1 without any patching.
(In reply to Perfect Gentleman from comment #13) > LO-7.1.1.1 builds with Clang-11.1 without any patching. I can confirm, built LO-7.1.1.1 with Clang-11.1.0 with default libc++ and what's better, executes without segfaulting without any patch except for the missing includes in patch libreoffice-7.0.3.1-libcxx11.patch (adapted for being applied to this version). Maybe it is worth to just bump (and add the missing version for some dependencies like libixion and liborcus)?
If you still need those patches in 7.1.3.2 then please try to get them upstreamed.
(In reply to Andreas Sturmlechner from comment #15) > If you still need those patches in 7.1.3.2 then please try to get them > upstreamed. Yep. I'll close this unless there's some progress or update here?
