This is tracking PR for libreoffice issues, similar to PR45375
Currently libreoffice dies building svx at PR50383. Also there are couple of errors even with -fpermissive. Could someone look into that?
Just successfully built libreoffice with todays gcc without LTO. I ran into three issues: 1) I use the following patch to include <unistd.h> in gcc/gthr-posix.h. This gets rid of many trivial errors. diff --git a/gcc/gthr-posix.h b/gcc/gthr-posix.h index b1d499d..3c155d0 100644 --- a/gcc/gthr-posix.h +++ b/gcc/gthr-posix.h @@ -39,6 +39,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see #endif #include <pthread.h> +#include <unistd.h> #if ((defined(_LIBOBJC) || defined(_LIBOBJC_WEAK)) \ || !defined(_GTHREAD_USE_MUTEX_TIMEDLOCK)) Revision 176335 deleted this include and the authors insist that this is the right thing to do... 2) There is an error in ./oox/inc/oox/helper/refmap.hxx: ../../inc/oox/helper/refmap.hxx:182:86: error: no matching function for call to 'find(oox::RefMap<std::pair<short int, rtl::OUString>, oox::xls::DefinedName>::key_type&)' Fixed by following the note given in the warning that proceeds the error: ../../inc/oox/helper/refmap.hxx:182:86: warning: 'find' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive] ../../inc/oox/helper/refmap.hxx:182:86: note: declarations in dependent base 'std::map<int, boost::shared_ptr<oox::xls::Connection>, std::less<int>, std::allocator<std::pair<const int, boost::shared_ptr<oox::xls::Connection> > > >' are not found by unqualified lookup ../../inc/oox/helper/refmap.hxx:182:86: note: use 'this->find' instead 3) There were three identical errors in /sc/source/ui/view/dbfunc.cxx (complaining that GetViewData() cannot be called without an object). Fixed by putting a "this->" before GetViewData() in lines 434, 463 and 473.
Thanks a lot! is there any chance to get those fixes into official git so we don't need to cummulate local patches? :)
(In reply to comment #3) > Thanks a lot! is there any chance to get those fixes into official git so we > don't need to cummulate local patches? :) It looks like some libreoffice developers are monitoring this meta-bug. Issue 2) is already fixed: http://cgit.freedesktop.org/libreoffice/core/commit/?id=87891c1c8bb82904fd68c523cb1aa11ddcfaaa3d
With workaround I attached to PR50383 I can now build libsvx (and I did not try to get further, with bit of luck it will just work ;) W/o lto: evans:/abuild/jh/libreoffice/:[0]# size ./core/solver/unxlngx6.pro/lib/libsvxcorelo.so text data bss dec hex filename 7628075 637648 10433 8276156 7e48bc ./core/solver/unxlngx6.pro/lib/libsvxcorelo.so With lto: evans:/abuild/jh/libreoffice/:[0]# size ./core/workdir/unxlngx6.pro/LinkTarget/Library/libsvxcorelo.so text data bss dec hex filename 6145323 635836 10384 6791543 67a177 ./core/workdir/unxlngx6.pro/LinkTarget/Library/libsvxcorelo.so Not too bad.
Now it dies at /abuild/jh/trunk-install/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../x86_64-unknown-linux-gnu/bin/ld: warning: hidden symbol 'typeinfo for SolarMutexResettableGuard' in /abuild/jh/libreoffice/core/workdir/unxlngx6.pro/CxxObject/sfx2/source/appl/app.o is referenced by DSO /abuild/jh/libreoffice/core/solver/unxlngx6.pro/lib/libvcllo.so lto1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. lto-wrapper: /abuild/jh/trunk-install/bin/g++ returned 1 exit status I saw previously segfault in ipa-cp, so this might be same issue. Honza
OK, the error is ipa-cp trying to fold ctor reference as: #1 0x00000000005d2fee in fold_ctor_reference (type=0x7ffff53501f8, ctor=0x7ffff7ec0b10, offset=1088, size=64) at ../../gcc/gimple-fold.c:2880 2880 if (useless_type_conversion_p (type, TREE_TYPE (ctor)) (gdb) p debug_tree (type) <pointer_type 0x7ffff53501f8 __vtbl_ptr_type type <function_type 0x7ffff53502a0 type <integer_type 0x7ffff7ec95e8 int public SI size <integer_cst 0x7ffff7ecc240 constant 32> unit size <integer_cst 0x7ffff7ecc260 constant 4> align 32 symtab 0 alias set 5 canonical type 0x7ffff7ec95e8 precision 32 min <integer_cst 0x7ffff7ecc1e0 -2147483648> max <integer_cst 0x7ffff7ecc200 2147483647> pointer_to_this <pointer_type 0x7ffff7ed72a0> reference_to_this <reference_type 0x7ffff1c7c930>> QI size <integer_cst 0x7ffff7ecc080 constant 8> unit size <integer_cst 0x7ffff7ecc0a0 constant 1> align 8 symtab 0 alias set -1 canonical type 0x7ffff53502a0 pointer_to_this <pointer_type 0x7ffff53501f8 __vtbl_ptr_type>> public unsigned DI size <integer_cst 0x7ffff7eb9ec0 type <integer_type 0x7ffff7ec90a8 bitsizetype> constant 64> unit size <integer_cst 0x7ffff7eb9ee0 type <integer_type 0x7ffff7ec9000 sizetype> constant 8> align 64 symtab 0 alias set -1 canonical type 0x7ffff53591f8 pointer_to_this <pointer_type 0x7ffff5350150>> $2 = void (gdb) p debug_tree (ctor) <error_mark 0x7ffff7ec0b10> $3 = void (gdb) bt #0 useless_type_conversion_p (outer_type=0x7ffff53501f8, inner_type=0x66686e6973615f6e) at ../../gcc/tree-ssa.c:1292 #1 0x00000000005d2fee in fold_ctor_reference (type=0x7ffff53501f8, ctor=0x7ffff7ec0b10, offset=1088, size=64) at ../../gcc/gimple-fold.c:2880 #2 0x00000000005d3a6e in gimple_get_virt_method_for_binfo (token=960, known_binfo=<optimized out>) at ../../gcc/gimple-fold.c:3056 #3 0x0000000000ae4cce in devirtualization_time_bonus (node=<optimized out>, known_csts=0x3622de0, known_binfos=0x3622d80) at ../../gcc/ipa-cp.c:1170 #4 0x0000000000ae8b8c in estimate_local_effects (node=<optimized out>) at ../../gcc/ipa-cp.c:1401 #5 propagate_constants_topo (topo=<optimized out>) at ../../gcc/ipa-cp.c:1548 #6 ipcp_propagate_stage (topo=<optimized out>) at ../../gcc/ipa-cp.c:1631 #7 ipcp_driver () at ../../gcc/ipa-cp.c:2434 #8 0x00000000006710a7 in execute_one_pass (pass=0x10916e0) at ../../gcc/passes.c:2063 #9 0x0000000000671876 in execute_ipa_pass_list (pass=0x10916e0) at ../../gcc/passes.c:2430 #10 0x00000000004ab3c4 in do_whole_program_analysis () at ../../gcc/lto/lto.c:2670 #11 0x00000000004adf6d in lto_main () at ../../gcc/lto/lto.c:2796 #12 0x0000000000704a32 in compile_file () at ../../gcc/toplev.c:548 #13 do_compile () at ../../gcc/toplev.c:1886 #14 toplev_main (argc=171, argv=0x11fe290) at ../../gcc/toplev.c:1962 #15 0x00007ffff63efbc6 in __libc_start_main () from /lib64/libc.so.6 #16 0x00000000004909e9 in _start () at ../sysdeps/x86_64/elf/start.S:113 Martin, is this optimized out binfo? I will try to reduce this mess, but it is huge, as you could expect
OK, I guess the problem is that we don't stream initializer of extern variables. This leads to Martin's new devirtualization code to no longer be able to get the optimization done (and same way our folder). We should check for error_mark, but also get a testcase for missed optimization and probably start walking extern initializers when partitioning.
BTW we find only 1 devirtualization case on sfx: evans:/abuild/jh/libreoffice/:[0]# grep "known target" ./core/workdir/unxlngx6.pro/LinkTarget/Library/libsvxcorelo.so.wpa* ./core/workdir/unxlngx6.pro/LinkTarget/Library/libsvxcorelo.so.wpa.049i.inline:ipa-prop: Discovered an indirect call to a known target (transform/47233 -> makeAny/46406), for stmt with uid 0 ./core/workdir/unxlngx6.pro/LinkTarget/Library/libsvxcorelo.so.wpa.049i.inline:ipa-prop: Discovered a virtual call to a known target (getStandardDate/24786 -> ensureLoaded/57221), for stmt with uid 2
PR50430 now tracks the svx2 issue.
With fix I commited for PR50430 and the workaround for PR50383 my build dies on java modules. I believe it is the problem we run into with Michael on the opensuse conference and we made that module to be last (it is because on my setup sun java does not work and ibm java apparently breaks with current libreoffice). So perhaps this is all needed?
(In reply to comment #11) > With fix I commited for PR50430 and the workaround for PR50383 my build dies on > java modules. I believe it is the problem we run into with Michael on the > opensuse conference and we made that module to be last (it is because on my > setup sun java does not work and ibm java apparently breaks with current > libreoffice). So perhaps this is all needed? It will build fine with LTO (and --without-java), but the resulting binary crashes during startup: terminate called after throwing an instance of 'com::sun::star::container::NoSuchElementException' It throws an exception in: xmlreader::XmlReader::XmlReader(rtl::OUString const&) () from image/usr/ure/lib/libxmlreader.so. This happens in xmlreader/source/xmlreader.cxx. I haven't looked deeper yet, but a non LTO build shows no problems at all.
(In reply to comment #12) > (In reply to comment #11) > > With fix I commited for PR50430 and the workaround for PR50383 my build dies on > > java modules. I believe it is the problem we run into with Michael on the > > opensuse conference and we made that module to be last (it is because on my > > setup sun java does not work and ibm java apparently breaks with current > > libreoffice). So perhaps this is all needed? > > It will build fine with LTO (and --without-java), but the resulting binary > crashes during startup: > > terminate called after throwing an instance of > 'com::sun::star::container::NoSuchElementException' > It throws an exception in: xmlreader::XmlReader::XmlReader(rtl::OUString > const&) () from image/usr/ure/lib/libxmlreader.so. > This happens in xmlreader/source/xmlreader.cxx. > > I haven't looked deeper yet, but a non LTO build shows no problems at all. The above happened when I configured --with-max-jobs=4 and --with-num-cpus=4. With -with-max-jobs=1 and --with-num-cpus=4 I get a different crash on startup: Program received signal SIGABRT, Aborted. 0x00007ffff7db7695 in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); #0 0x00007ffff7db7695 in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007ffff7db8b3d in __GI_abort () at abort.c:93 #2 0x00007ffff7bc486d in _Unwind_SetGRValue (val=<optimized out>, index=<optimized out>, context=<optimized out>) at /var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/gcc-4.5.3/libgcc/../gcc/unwind-dw2.c:253 #3 uw_update_context_1 (context=0x7fffffffbdc0, fs=0x7fffffffbc40) at /var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/gcc-4.5.3/libgcc/../gcc/unwind-dw2.c:1368 #4 0x00007ffff7bc4b91 in uw_update_context (context=0x7fffffffbdc0, fs=0x7fffffffbc40) at /var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/gcc-4.5.3/libgcc/../gcc/unwind-dw2.c:1388 #5 0x00007ffff7bc57cb in _Unwind_RaiseException (exc=0xe64150) at /var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/gcc-4.5.3/libgcc/../gcc/unwind.inc:122 #6 0x00007ffff7d0d741 in __cxa_throw () from /usr/lib64/libstdc++.so.6 #7 0x00007ffff18915c8 in gcc3::raiseException(_uno_Any*, _uno_Mapping*) () from /var/tmp/portage/app-office/libreoffice-9999-r1/image/usr/ure/lib/libgcc3_uno.so #8 0x00007ffff1892dff in cpp2uno_call(bridges::cpp_uno::shared::CppInterfaceProxy*, _typelib_TypeDescription const*, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter*, void**, void**, void**, unsigned long*) () from /var/tmp/portage/app-office/libreoffice-9999-r1/image/usr/ure/lib/libgcc3_uno.so #9 0x00007ffff1893553 in cpp_vtable_call () from /var/tmp/portage/app-office/libreoffice-9999-r1/image/usr/ure/lib/libgcc3_uno.so #10 0x00007ffff1895356 in privateSnippetExecutor () from /var/tmp/portage/app-office/libreoffice-9999-r1/image/usr/ure/lib/libgcc3_uno.so #11 0x00007ffff79389f3 in cppu::throwException(com::sun::star::uno::Any const&) () from /var/tmp/portage/app-office/libreoffice-9999-r1/image/usr/program/../basis-link/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #12 0x00007ffff69cd7ec 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&) () from /var/tmp/portage/app-office/libreoffice-9999-r1/image/usr/program/../basis-link/program/libucbhelper4gcc3.so #13 0x0000000000000000 in ?? ()
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 > > --- Comment #13 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2011-09-17 21:42:57 UTC --- > (In reply to comment #12) > > (In reply to comment #11) > > > With fix I commited for PR50430 and the workaround for PR50383 my build dies on > > > java modules. I believe it is the problem we run into with Michael on the > > > opensuse conference and we made that module to be last (it is because on my > > > setup sun java does not work and ibm java apparently breaks with current > > > libreoffice). So perhaps this is all needed? > > > > It will build fine with LTO (and --without-java), but the resulting binary > > crashes during startup: > > > > terminate called after throwing an instance of > > 'com::sun::star::container::NoSuchElementException' > > It throws an exception in: xmlreader::XmlReader::XmlReader(rtl::OUString > > const&) () from image/usr/ure/lib/libxmlreader.so. > > This happens in xmlreader/source/xmlreader.cxx. > > > > I haven't looked deeper yet, but a non LTO build shows no problems at all. > > The above happened when I configured --with-max-jobs=4 and --with-num-cpus=4. > With -with-max-jobs=1 and --with-num-cpus=4 I get a different crash on startup: Hmm, this is very weird. Since max-jobs affects nothing in GCC, it is probably some sort of build machinery problem. I guess it will be needed to debug what really happens here? Honza
BTW since the exception seems to be thrown from libuno_cppuhelpergcc3.so.3 that sounds like there is some sort of gcc specific magic that has good chance to break with LTO, I would suggest to try to compile that dso w/o linktime (you only need to add -fno-use-linker-plugin -fno-lto) and hopefully we get past this issue? Honza
(In reply to comment #15) > BTW since the exception seems to be thrown from libuno_cppuhelpergcc3.so.3 > that sounds like there is some sort of gcc specific magic that has good chance > to break with LTO, I would suggest to try to compile that dso w/o linktime (you > only need to add -fno-use-linker-plugin -fno-lto) and hopefully we get past > this issue? Unfortunately it's not that simple. It looks like several libraries in solver/unxlngx6.pro/lib are broken when they are build with LTO. What I've done is to copy working libraries from a non LTO build into solver/unxlngx6.pro/lib, until soffice.bin no longer crashes. But even "cp /lib_working/*gcc* solver/unxlngx6.pro/lib" isn't enough. You have to look at the back-traces to get an idea about what to copy next. And after copying many libs soffice.bin will no longer crash... I haven't found out exactly what libs are affected yet, because I've copied them in large chunks.
> I haven't found out exactly what libs are affected yet, because I've copied > them in large chunks. Hmm, this is quite weird. I am not aware of any really important LTO related wrong code issues (and in general my experience is that LTO tends to ICE or produce missing symbols, not really produce wrong code that often). So my bet would be that libreoffice uses some tricks that breaks with LTO and we will need to idenitfy which one. If you could look into it, perhaps it would be interesting to identify smallest library that misoptimize and see what is happening with it. One common cause of problems is that -flto confuse the configure scripts. Some of configure tests are written in a way so LTO optimize the interesting part away and the test always pass. This usually leads to some link/parse errors but it also might break other things. Since you have both lto and non-lto builds, you could compare the config caches and see if they match? Thanks! Honza
(In reply to comment #17) > > I haven't found out exactly what libs are affected yet, because I've copied > > them in large chunks. > > Hmm, this is quite weird. I am not aware of any really important LTO related > wrong code issues (and in general my experience is that LTO tends to ICE or > produce missing symbols, not really produce wrong code that often). > So my bet would be that libreoffice uses some tricks that breaks with LTO and > we will need to idenitfy which one. > > If you could look into it, perhaps it would be interesting to identify smallest > library that misoptimize and see what is happening with it. > > One common cause of problems is that -flto confuse the configure scripts. > Some of configure tests are written in a way so LTO optimize the interesting > part away and the test always pass. This usually leads to some link/parse > errors > but it also might break other things. Since you have both lto and non-lto > builds, > you could compare the config caches and see if they match? Yes, they are identical as far as I can tell. The problem seems to be that Libreoffice is ATM just too fragile when it comes to optimization flags. In other words, it will silently misoptimize in case of a non-supported -O flag. Quote from the Gentoo ebuild: # silent miscompiles; LO/OOo adds -O2/1/0 where appropriate filter-flags "-O* And because the effect of LTO is to fully optimize the important parts of a program and use -Os for the rest, this could explain the crashes.
> # silent miscompiles; LO/OOo adds -O2/1/0 where appropriate > filter-flags "-O* > > And because the effect of LTO is to fully optimize the important parts of > a program and use -Os for the rest, this could explain the crashes. GCC does not really bump up optimization levels and same heuristics is in limited degree applied w/o LTO as well. Debugging this seems quite important. Perhaps hacking -fno-strict-aliasing in addition to -flto at linktime could be first shot to get working binary?
For: terminate called after throwing an instance of 'com::sun::star::container::NoSuchElementException' It throws an exception in: xmlreader::XmlReader::XmlReader(rtl::OUString const&) () from image/usr/ure/lib/libxmlreader.so. This happens in xmlreader/source/xmlreader.cxx. This is new code, and shouldn't suffer lots of aliasing / compilation nasties I hope - it is also -fairly- self-standing and relatively simple. If we have a problem here - we have a real problem I think. I'd personally focus on that, it should (I hope) be easier. How did you install though ? run a 'make dev-install' ? and then run install/program/soffice ? this: #6 0x00007ffff7d0d741 in __cxa_throw () from /usr/lib64/libstdc++.so.6 #7 0x00007ffff18915c8 in gcc3::raiseException(_uno_Any*, _uno_Mapping*) () from /var/tmp/portage/app-office/libreoffice-9999-r1/image/usr/ure/lib/libgcc3_uno.so #8 0x00007ffff1892dff in cpp2uno_call(bridges::cpp_uno::shared::CppInterfaceProxy*, _typelib_TypeDescription const*, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter*, void**, void**, void**, unsigned long*) () from /var/tmp/portage/app-office/libreoffice-9999-r1/image/usr/ure/lib/libgcc3_uno.so #9 0x00007ffff1893553 in cpp_vtable_call () from is altogether more hairy - we create at run-time C++ vtables packed with trampolines so we can intercept / model native C++ objects and interact with them via python etc. that would need some more intense debugging love I guess.
> is altogether more hairy - we create at run-time C++ vtables packed with > trampolines so we can intercept / model native C++ objects and interact with > them via python etc. that would need some more intense debugging love I guess. Hmm, this sounds scary. (I remember Kendy explaining me this years back when OOo was ported to x86_64.) More or less everything that is reachable externally ought to be annotated with used/externally_visible attributes or the assembly wrappers has to be visible at linktime. Is there some short overview of the machinery? (or could you explain it somehow? :) Honza
(In reply to comment #20) > For: > > terminate called after throwing an instance of > 'com::sun::star::container::NoSuchElementException' > It throws an exception in: xmlreader::XmlReader::XmlReader(rtl::OUString > const&) () from image/usr/ure/lib/libxmlreader.so. > This happens in xmlreader/source/xmlreader.cxx. > > This is new code, and shouldn't suffer lots of aliasing / compilation > nasties I hope - it is also -fairly- self-standing and relatively simple. If we > have a problem here - we have a real problem I think. I'd personally focus on > that, it should (I hope) be easier. This problem is fixed in the current git version of LibreOffice. (I cannot reproduce it anymore, even with --with-max-jobs=4 and --with-num-cpus=4) > How did you install though ? run a 'make dev-install' ? and then run > install/program/soffice ? Yes. > this: > > #6 0x00007ffff7d0d741 in __cxa_throw () from /usr/lib64/libstdc++.so.6 > #7 0x00007ffff18915c8 in gcc3::raiseException(_uno_Any*, _uno_Mapping*) () > from > /var/tmp/portage/app-office/libreoffice-9999-r1/image/usr/ure/lib/libgcc3_uno.so > #8 0x00007ffff1892dff in > cpp2uno_call(bridges::cpp_uno::shared::CppInterfaceProxy*, > _typelib_TypeDescription const*, _typelib_TypeDescriptionReference*, int, > _typelib_MethodParameter*, void**, void**, void**, unsigned long*) () from > /var/tmp/portage/app-office/libreoffice-9999-r1/image/usr/ure/lib/libgcc3_uno.so > #9 0x00007ffff1893553 in cpp_vtable_call () from > > is altogether more hairy - we create at run-time C++ vtables packed with > trampolines so we can intercept / model native C++ objects and interact with > them via python etc. that would need some more intense debugging love I guess. and this one is the only remaining issue. Issue 3) from Comment 2 was a dup of PR50365 and was fixed by Jason recently.
> > is altogether more hairy - we create at run-time C++ vtables packed with > > trampolines so we can intercept / model native C++ objects and interact with > > them via python etc. that would need some more intense debugging love I guess. > > and this one is the only remaining issue. That sounds promising. I can imagine that this sort of magic breaks with LTO. Is the solution as simple as using non-LTO version of libgcc3_uno.so? I will try to take a look how this is implemented. Honza
> I can imagine that this sort of magic breaks with LTO. Is the solution as > simple as using non-LTO version of libgcc3_uno.so? I will try to take a look > how this is implemented. Great - so, we wouldn't loose much by having the bridge compiled without optimisation - it is ultimately used to map C++ -> Java or python so all performance is already shot by that stage ;-) bridges/source/cpp_uno/gcc3_linux_intel/call.s bridges/source/cpp_uno/gcc3_linux_x86-64/call.s are the places to dig - unfortunately there is -far- too much cut/paste going on in here, though we've done some work to try to share more IIRC. These snippets are used by cpp2uno.cxx - to build trampolines cf. 'codeSnippet' - which (I hope) should work fine, and by uno2cpp.cxx to invoke things eg. 'uno2cpp.cxx's callVirtualMethod - which has some fun assembler in each case. Does that help ?
New ICE with today's gcc and today's libreoffice: [ build PAG ] writer [ build LNK ] Executable/oosplash [ build LNK ] Library/libspl_unxlo.so [ build CMP ] desktop/unx/splash/splash [ build CMP ] desktop/unx/splash/splash [ build LNK ] Library/libevtattlo.so [ build CMP ] eventattacher/source/evtatt [ build CMP ] eventattacher/source/evtatt [ build LNK ] Library/libfileacc.so [ build CMP ] fileaccess/source/fileacc [ build CMP ] fileaccess/source/fileacc [ build LNK ] Library/libfrmlo.so [ build CMP ] forms/util/frm [ build CMP ] forms/util/frm [ build LNK ] Library/libforlo.so [ build CMP ] formula/util/for [ build CMP ] formula/util/for [ build LNK ] Library/libhwplo.so [ build CMP ] hwpfilter/source/hwp In file included from /var/tmp/portage/app-office/libreoffice-9999-r1/work/libreoffice-core-9999/solver/unxlngx6.pro/inc/cppu/unotype.hxx:3740:0, from :3330: /var/tmp/portage/app-office/libreoffice-9999-r1/work/libreoffice-core-9999/dbaccess/source/core/api/table.cxx: In member function 'columnDropped': /var/tmp/portage/app-office/libreoffice-9999-r1/work/libreoffice-core-9999/dbaccess/source/core/api/table.cxx:158:1: internal compiler error: in redirect_jump, at jump.c:1497 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. make[2]: *** [/var/tmp/portage/app-office/libreoffice-9999-r1/temp/ccoLHzyy.ltrans2.ltrans.o] Error 1 make[2]: *** Waiting for unfinished jobs.... lto-wrapper: make returned 2 exit status /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld: fatal error: lto-wrapper failed collect2: error: ld returned 1 exit status make[1]: *** [/var/tmp/portage/app-office/libreoffice-9999-r1/work/libreoffice-core-9999/workdir/unxlngx6.pro/LinkTarget/Library/libdbalo.so] Error 1 make[1]: *** Waiting for unfinished jobs...
(In reply to comment #25) > New ICE with today's gcc and today's libreoffice: > > /var/tmp/portage/app-office/libreoffice-9999-r1/work/libreoffice-core-9999/dbaccess/source/core/api/table.cxx:158:1: > internal compiler error: in redirect_jump, at jump.c:1497 This is now PR50496. I'm still reducing with delta.
OK, disabling Java gets me further now, but I now get an abort at: jh@evans:/abuild/jh/libreoffice/core> more ./workdir/unxlngx6.pro/CppunitTest/comphelper_test.test.log terminate called after throwing an instance of 'CppUnit::DynamicLibraryManagerException' what(): Failed to load dynamic library: /abuild/jh/libreoffice/core/workdir/unxlngx6.pro/LinkTarget/CppunitTest/libtest_comphelper_test.so any idea?
Gcc trunk revision 209488 built for me libreoffice 4.2.3.3 with -flto=4 -fuse-linker-plugin and resulting binaries works.
Indeed, at the moment I see now important showstoppers for Libreoffice, only thing I need is ar/nm/ranlib wrapper on my path. I am closing this sort of open-ended PR until some problems reappears ;))
Hey Jan, I'm not able to successfully compile LO (4.4.2.2) with GCC 5.1.0. I'm getting segmentation faults when gengal.bin is executed: /bin/sh: line 1: 5682 Segmentation fault SAL_USE_VCLPLUGIN=svp LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/ure/lib:$I/program" $I/program/gengal.bin "-env:BRAND_BASE_DIR=file://$S/instdir" "-env:CONFIGURATION_LAYERS=xcsxcu:file://$I/share/registry" "-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb file://$W/ComponentTarget/comphelper/util/comphelp.component file://$W/ComponentTarget/configmgr/source/configmgr.component file://$W/ComponentTarget/drawinglayer/drawinglayer.component file://$W/ComponentTarget/framework/util/fwk.component file://$W/ComponentTarget/i18npool/util/i18npool.component file://$W/ComponentTarget/package/source/xstor/xstor.component file://$W/ComponentTarget/package/util/package2.component file://$W/ComponentTarget/sax/source/expatwrap/expwrap.component file://$W/ComponentTarget/sfx2/util/sfx.component file://$W/ComponentTarget/svgio/svgio.component file://$W/ComponentTarget/svx/util/svx.component file://$W/ComponentTarget/svx/util/svxcore.component file://$W/ComponentTarget/ucb/source/core/ucb1.component file://$W/ComponentTarget/ucb/source/ucp/file/ucpfile1.component file://$W/ComponentTarget/unoxml/source/service/unoxml.component" "-env:UNO_TYPES= file://$I/program/types/offapi.rdb file://$I/ure/share/misc/types.rdb" -env:URE_INTERNAL_LIB_DIR=file://$I/ure/lib -env:LO_LIB_DIR=file://$I/program --build-tree --destdir file://$S/extras/source/gallery --name "arrows" --path $W/Gallery/arrows --filenames file://$RESPONSEFILE /home/gentoo/tmp/portage/app-office/libreoffice-4.4.2.2/work/libreoffice-4.4.2.2/solenv/gbuild/Gallery.mk:72: recipe for target '/home/gentoo/tmp/portage/app-office/libreoffice-4.4.2.2/work/libreoffice-4.4.2.2/workdir/Gallery/arrows.done' failed make[1]: *** [/home/gentoo/tmp/portage/app-office/libreoffice-4.4.2.2/work/libreoffice-4.4.2.2/workdir/Gallery/arrows.done] Error 139 make[1]: *** Waiting for unfinished jobs.... Any ideas?
Just a short update. With LTO enabled, configure thinks I have a buggy GCC: checking if gcc has a visibility bug with class-level attributes (GCC bug 26905)... yes configure: WARNING: Your gcc is not -fvisibility=hidden safe. Disabling visibility I've then added -ffat-lto-objects to my ${C,CXX,Ld}FLAGS and the warning disappeared. The build failes at the same place, but instead of a segmentation fault I now get a illegal instruction error: /bin/sh: line 1: 10795 Illegal instruction SAL_USE_VCLPLUGIN=svp LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/ure/lib:$I/program" $I/program/gengal.bin "-env:BRAND_BASE_DIR=file://$S/instdir" "-env:CONFIGURATION_LAYERS=xcsxcu:file://$I/share/registry" "-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb file://$W/ComponentTarget/comphelper/util/comphelp.component file://$W/ComponentTarget/configmgr/source/configmgr.component file://$W/ComponentTarget/drawinglayer/drawinglayer.component file://$W/ComponentTarget/framework/util/fwk.component file://$W/ComponentTarget/i18npool/util/i18npool.component file://$W/ComponentTarget/package/source/xstor/xstor.component file://$W/ComponentTarget/package/util/package2.component file://$W/ComponentTarget/sax/source/expatwrap/expwrap.component file://$W/ComponentTarget/sfx2/util/sfx.component file://$W/ComponentTarget/svgio/svgio.component file://$W/ComponentTarget/svx/util/svx.component file://$W/ComponentTarget/svx/util/svxcore.component file://$W/ComponentTarget/ucb/source/core/ucb1.component file://$W/ComponentTarget/ucb/source/ucp/file/ucpfile1.component file://$W/ComponentTarget/unoxml/source/service/unoxml.component" "-env:UNO_TYPES= file://$I/program/types/offapi.rdb file://$I/ure/share/misc/types.rdb" -env:URE_INTERNAL_LIB_DIR=file://$I/ure/lib -env:LO_LIB_DIR=file://$I/program --build-tree --destdir file://$S/extras/source/gallery --name "arrows" --path $W/Gallery/arrows --filenames file://$RESPONSEFILE /home/gentoo/tmp/portage/app-office/libreoffice-4.4.2.2/work/libreoffice-4.4.2.2/solenv/gbuild/Gallery.mk:72: recipe for target '/home/gentoo/tmp/portage/app-office/libreoffice-4.4.2.2/work/libreoffice-4.4.2.2/workdir/Gallery/arrows.done' failed make[1]: *** [/home/gentoo/tmp/portage/app-office/libreoffice-4.4.2.2/work/libreoffice-4.4.2.2/workdir/Gallery/arrows.done] Error 132 make[1]: *** Waiting for unfinished jobs....
(In reply to Steffen Hau from comment #31) Created PR70112