error during build of 4.4.6.1
Hi, I'm back trying to update LO on XStreamOS/illumos. First I'm trying to upgrade build to 4.4.6.1 (got it working up to 4.4.0.3 until now). Patches are almost the same I used for 4.4.0.3, removed some that you probably already included meanwhile. Now I get this error, any idea? [build SLC] writerperfect S=/xstreamdev/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.6.1 & I=$S/instdir & W=$S/workdir & mkdir -p $W/Module/slowcheck/ & touch $W/Module/slowcheck/writerperfect /bin/sh: line 1: 756: Abort(coredump) File tested,Execution Time (ms) W: No such modules: liPgtag-ext-ldml-t.so W: No such modules: liPgtag-ext-ldml-u.so n751054.docx,1157 File tested,Execution Time (ms) n751117.docx,502 File tested,Execution Time (ms) n751017.docx,469 File tested,Execution Time (ms) n750935.docx,907 File tested,Execution Time (ms) n757890.docx,840 File tested,Execution Time (ms) rhbz988516.docx,790 File tested,Execution Time (ms) fdo49940.docx,673 File tested,Execution Time (ms) fdo74745.docx,551 File tested,Execution Time (ms) fdo81486.docx,431 File tested,Execution Time (ms) n751077.docx,631 File tested,Execution Time (ms) n705956-1.docx,252 File tested,Execution Time (ms) n705956-2.docx,248 File tested,Execution Time (ms) n747461.docx,596 File tested,Execution Time (ms) n750255.docx,637 File tested,Execution Time (ms) n652364.docx,731 File tested,Execution Time (ms) n760764.docx,561 File tested,Execution Time (ms) n764005.docx,505 File tested,Execution Time (ms) n764745-alignment.docx,166 File tested,Execution Time (ms) n766477.docx,495 File tested,Execution Time (ms) n758883.docx,838 File tested,Execution Time (ms) n766481.docx,438 File tested,Execution Time (ms) n766487.docx,324 File tested,Execution Time (ms) n693238.docx,758 File tested,Execution Time (ms) numbering1.docx,405 File tested,Execution Time (ms) bnc773061.docx,658 File tested,Execution Time (ms) all_gaps_word.docx,916 File tested,Execution Time (ms) n775906.docx,564 File tested,Execution Time (ms) n775899.docx,455 File tested,Execution Time (ms) n777345.docx,941 File tested,Execution Time (ms) n777337.docx,676 File tested,Execution Time (ms) n778836.docx,629 File tested,Execution Time (ms) n778140.docx,338 File tested,Execution Time (ms) n778828.docx,708 File tested,Execution Time (ms) ink.docx,700 File tested,Execution Time (ms) n779834.docx,461 File tested,Execution Time (ms) rhbz1180114.docx,99 File tested,Execution Time (ms) n779627.docx,884 File tested,Execution Time (ms) fdo74357.docx,398 File tested,Execution Time (ms) fdo55187.docx,779 File tested,Execution Time (ms) n780563.docx,564 File tested,Execution Time (ms) n780853.docx,472 File tested,Execution Time (ms) n780843.docx,1156 File tested,Execution Time (ms) imgshadow.docx,681 File tested,Execution Time (ms) n782061.docx,700 File tested,Execution Time (ms) n782345.docx,403 File tested,Execution Time (ms) n779941.docx,352 File tested,Execution Time (ms) n783638.docx,956 File tested,Execution Time (ms) fdo52208.docx,594 File tested,Execution Time (ms) n785767.docx,715 File tested,Execution Time (ms) n773061.docx,247 File tested,Execution Time (ms) n780645.docx,92 File tested,Execution Time (ms) tableborder-finedash.docx,501 File tested,Execution Time (ms) n792778.docx,582 File tested,Execution Time (ms) WordArt.docx,914 File tested,Execution Time (ms) groupshape-line.docx,516 File tested,Execution Time (ms) groupshape-child-rotation.docx,559 File tested,Execution Time (ms) groupshape-smarttag.docx,753 File tested,Execution Time (ms) n793262.docx,548 File tested,Execution Time (ms) n793998.docx,472 File tested,Execution Time (ms) n779642.docx,562 File tested,Execution Time (ms) tblr-height.docx,464 File tested,Execution Time (ms) bnc865381.docx,729 File tested,Execution Time (ms) fdo53985.docx,1074 File tested,Execution Time (ms) fdo59638.docx,380 File tested,Execution Time (ms) fdo61343.docx,625 File tested,Execution Time (ms) tools-line-numbering.docx,872 File tested,Execution Time (ms) fdo78904.docx,417 File tested,Execution Time (ms) fdo60922.docx,107 File tested,Execution Time (ms) fdo59273.docx,118 File tested,Execution Time (ms) table_width.docx,116 File tested,Execution Time (ms) conditionalstyles-tbllook.docx,317 File tested,Execution Time (ms) fdo63685.docx,105 File tested,Execution Time (ms) n592908-frame.docx,927 File tested,Execution Time (ms) n592908-picture.docx,318 File tested,Execution Time (ms) n779630.docx,315 File tested,Execution Time (ms) indentation.docx,320 File tested,Execution Time (ms) page-border-shadow.docx,598 File tested,Execution Time (ms) n816593.docx,551 File tested,Execution Time (ms) n820509.docx,856 File tested,Execution Time (ms) n820788.docx,504 File tested,Execution Time (ms) n820504.docx,409 File tested,Execution Time (ms) n830205.docx,1823 File tested,Execution Time (ms) fdo43641.docx,407 File tested,Execution Time (ms) table-auto-column-fixed-size.docx,1202 File tested,Execution Time (ms)
LO 4.4.0.3 works on Sonicle XStreamOS Desktop (illumos)
Hello, happy to announce that, regardless of the many crashing cpp unit tests I had to disable during build, and of the many patches I had to write... ...it works great on Sonicle XStreamOS Desktop! :) We're having more tests in the next days. If everything goes fine, I will be posting the patches to garrit. Thanks for all your help! Gabriele. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: another cppunit test core dump, java this time, building on xstreamos/illumos
Ok, I disabled dbaccess_macro cppunit test. Had also to disable dbaccess_hsqldb cppunit test, because of a coredump there too. Now it's going on... Da: Gabriele Bulfon A: Stephan Bergmann libreoffice@lists.freedesktop.org Data: 27 febbraio 2015 20.19.38 CET Oggetto: Re: another cppunit test core dump, java this time, building on xstreamos/illumos wowso? what can I do? is this cppunit stage necessary to complete the build? What if I could disable this and go on? would it possibly work? -- Da: Stephan Bergmann A: libreoffice@lists.freedesktop.org Data: 27 febbraio 2015 18.34.08 CET Oggetto: Re: another cppunit test core dump, java this time, building on xstreamos/illumos On 02/26/2015 12:35 PM, Gabriele Bulfon wrote: 0803d0e8 libc.so.1`_lwp_kill+0x15(1, 6, 10e3, fef66000, fef66000, 0) 0803d108 libc.so.1`raise+0x2b(6, 0, 803d120, efe70dd9, 0, 0) 0803d158 libc.so.1`abort+0x10e(0, f010, 803d308, effda2d3, 1, f00b877d) 0803d168 libjvm.so`__1cCosFabort6Fb_v_+0x51(1, f00b877d, 1, 7d0) 0803d308 libjvm.so`__1cHVMErrorOreport_and_die6M_v_+0xab3(803d380, 803d4b4) 0803d3d8 libjvm.so`JVM_handle_solaris_signal+0xa6e(b, 803d6b4, 803d4b4, 1) 0803d3f8 libjvm.so`signalHandler+0x26(b, 803d6b4, 803d4b4, fef66000, 803d470, feee7f73) 0803d410 libc.so.1`__sighndlr+0x15(b, 803d6b4, 803d4b4, ef81acd4, 0, 29) 0803d470 libc.so.1`call_user_handler+0x292(b, 803d6b4, 803d4b4, fe0749ee, 0, 29) 0803d4a0 libc.so.1`sigacthandler+0x77(b, 803d6b4, 803d4b4) 0803d758 libc.so.1`memcpy+0x1b(8, fd35c7bc, 1b, 0, fef6a380, fea90180) 0803d788 libuno_sal.so.3`rtl_uString_newFromStr_WithLength+0x63(803d7cc, fd35c7bc, 1b, fe0768b3, fef6ca00) [...] libfwklo.so`_ZN3com3sun4star3uno13WeakReferenceINS1_5frame7XFrame2EED1Ev+0x1d(f35cfc40, fef6a380, 803dab8, fec06f85, fec19ac0) 0803da98 libfwklo.so`_Z41__static_initialization_and_destruction_0ii+0x4c(0, , feffc480, ef2800c4, 803dad0, fefca3b1) 0803dab8 libfwklo.so`_GLOBAL__sub_D_frame.cxx+0x1a(803daf0, fefca394, feffb0a4, f32ed90a, f34cc000, f7b60018) 0803dad8 0xf32ed950(feffb0a4, fefcebf3, feffb0a4, f7b60018, 803db30, fefd21a8) 0803daf0 libfwklo.so`_fini+0x1b(feffc480, 0, f7b60018, f, 0, 8e) 0803db30 ld.so.1`call_fini+0xb3(feffc480, ef280018, 0, 0) 0803db60 ld.so.1`atexit_fini+0x66(0, 10, fef804f0, fef804f0, 101a, 6cf04) 0803dbb0 libc.so.1`__cxa_finalize+0x85(0, 10, 80560af, 0, fef66000, 803dbbc) 0803dbd0 libc.so.1`_exithandle+0x37(feffb0a4, 80560af, 0, 0, 803dc58, 8056042) 0803dbf4 libc.so.1`exit+0x12(15, 803e978, 803ea01, 803ea9d, 803eaa8, 803eb28) That would be apparently be static css::uno::WeakReference m_xCloserFrame; in framework/source/services/frame.cxx wreaking havoc when destroyed during exit. Looks like in your case rtl_allocateMemory is already returning nullptr, probably indicating that atexit handlers of sal are run prior to those of fwk, which would be a bug. That said, static data with destructor is always bad (and just a lucky coincidence this one appears to not wreak havoc elsewhere) and should be removed, but also I don't see any immediate way how to do it in this case. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___LibreOffice mailing listLibreOffice@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: another cppunit test core dump, java this time, building on xstreamos/illumos
...also postprocess services cpp unit test coredumps...disabled this too... Gabriele Bulfon - Sonicle S.r.l. Tel +39 028246016 Int. 30 - Fax +39 028243880 via Santa Maria Valle 3 - 20123 - Milano - Italy http://www.sonicle.com Da: Gabriele Bulfon A: Stephan Bergmann libreoffice@lists.freedesktop.org Data: 28 febbraio 2015 9.02.26 CET Oggetto: Re: another cppunit test core dump, java this time, building on xstreamos/illumos Ok, I disabled dbaccess_macro cppunit test. Had also to disable dbaccess_hsqldb cppunit test, because of a coredump there too. Now it's going on... Da: Gabriele Bulfon A: Stephan Bergmann libreoffice@lists.freedesktop.org Data: 27 febbraio 2015 20.19.38 CET Oggetto: Re: another cppunit test core dump, java this time, building on xstreamos/illumos wowso? what can I do? is this cppunit stage necessary to complete the build? What if I could disable this and go on? would it possibly work? -- Da: Stephan Bergmann A: libreoffice@lists.freedesktop.org Data: 27 febbraio 2015 18.34.08 CET Oggetto: Re: another cppunit test core dump, java this time, building on xstreamos/illumos On 02/26/2015 12:35 PM, Gabriele Bulfon wrote: 0803d0e8 libc.so.1`_lwp_kill+0x15(1, 6, 10e3, fef66000, fef66000, 0) 0803d108 libc.so.1`raise+0x2b(6, 0, 803d120, efe70dd9, 0, 0) 0803d158 libc.so.1`abort+0x10e(0, f010, 803d308, effda2d3, 1, f00b877d) 0803d168 libjvm.so`__1cCosFabort6Fb_v_+0x51(1, f00b877d, 1, 7d0) 0803d308 libjvm.so`__1cHVMErrorOreport_and_die6M_v_+0xab3(803d380, 803d4b4) 0803d3d8 libjvm.so`JVM_handle_solaris_signal+0xa6e(b, 803d6b4, 803d4b4, 1) 0803d3f8 libjvm.so`signalHandler+0x26(b, 803d6b4, 803d4b4, fef66000, 803d470, feee7f73) 0803d410 libc.so.1`__sighndlr+0x15(b, 803d6b4, 803d4b4, ef81acd4, 0, 29) 0803d470 libc.so.1`call_user_handler+0x292(b, 803d6b4, 803d4b4, fe0749ee, 0, 29) 0803d4a0 libc.so.1`sigacthandler+0x77(b, 803d6b4, 803d4b4) 0803d758 libc.so.1`memcpy+0x1b(8, fd35c7bc, 1b, 0, fef6a380, fea90180) 0803d788 libuno_sal.so.3`rtl_uString_newFromStr_WithLength+0x63(803d7cc, fd35c7bc, 1b, fe0768b3, fef6ca00) [...] libfwklo.so`_ZN3com3sun4star3uno13WeakReferenceINS1_5frame7XFrame2EED1Ev+0x1d(f35cfc40, fef6a380, 803dab8, fec06f85, fec19ac0) 0803da98 libfwklo.so`_Z41__static_initialization_and_destruction_0ii+0x4c(0, , feffc480, ef2800c4, 803dad0, fefca3b1) 0803dab8 libfwklo.so`_GLOBAL__sub_D_frame.cxx+0x1a(803daf0, fefca394, feffb0a4, f32ed90a, f34cc000, f7b60018) 0803dad8 0xf32ed950(feffb0a4, fefcebf3, feffb0a4, f7b60018, 803db30, fefd21a8) 0803daf0 libfwklo.so`_fini+0x1b(feffc480, 0, f7b60018, f, 0, 8e) 0803db30 ld.so.1`call_fini+0xb3(feffc480, ef280018, 0, 0) 0803db60 ld.so.1`atexit_fini+0x66(0, 10, fef804f0, fef804f0, 101a, 6cf04) 0803dbb0 libc.so.1`__cxa_finalize+0x85(0, 10, 80560af, 0, fef66000, 803dbbc) 0803dbd0 libc.so.1`_exithandle+0x37(feffb0a4, 80560af, 0, 0, 803dc58, 8056042) 0803dbf4 libc.so.1`exit+0x12(15, 803e978, 803ea01, 803ea9d, 803eaa8, 803eb28) That would be apparently be static css::uno::WeakReference m_xCloserFrame; in framework/source/services/frame.cxx wreaking havoc when destroyed during exit. Looks like in your case rtl_allocateMemory is already returning nullptr, probably indicating that atexit handlers of sal are run prior to those of fwk, which would be a bug. That said, static data with destructor is always bad (and just a lucky coincidence this one appears to not wreak havoc elsewhere) and should be removed, but also I don't see any immediate way how to do it in this case. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___LibreOffice mailing listLibreOffice@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice ___LibreOffice mailing listLibreOffice@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: another cppunit test core dump, java this time, building on xstreamos/illumos
. #28 0xf33c5c4a in _GLOBAL__sub_D_frame.cxx () from /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/program/libfwklo.so No symbol table info available. #29 0xf32ed950 in __do_global_dtors_aux () from /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/program/libfwklo.so No symbol table info available. #30 0xf348acab in _fini () from /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/program/libfwklo.so No symbol table info available. #31 0xfefd21a8 in call_fini () from /lib/ld.so.1 No symbol table info available. #32 0xfefd22cd in atexit_fini () from /lib/ld.so.1 No symbol table info available. #33 0xfee6e5f6 in __cxa_finalize () from /lib/libc.so.1 No symbol table info available. #34 0xfee6e98d in _exithandle () from /lib/libc.so.1 No symbol table info available. #35 0xfee623e2 in exit () from /lib/libc.so.1 No symbol table info available. #36 0x080560af in _start () No symbol table info available. Da: Gabriele Bulfon A: Stephan Bergmann libreoffice-dev Data: 27 febbraio 2015 9.28.38 CET Oggetto: Re: another cppunit test core dump, java this time, building on xstreamos/illumos Tried adding the join call, but no luck. Now I tried to run make for debugging, entered gdb and issued run. Looks like I need to enable some debugs. What module though? GNU gdb (GDB) 7.6 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-pc-solaris2.11. For bug reporting instructions, please see: ... Reading symbols from /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/LinkTarget/Executable/cppunittester...(no debugging symbols found)...done. (gdb) run Starting program: /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/LinkTarget/Executable/cppunittester /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/LinkTarget/CppunitTest/libtest_dbaccess_macros_test.so --headless -env:BRAND_BASE_DIR=file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir -env:BRAND_SHARE_SUBDIR=share -env:UserInstallation=file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/CppunitTest/dbaccess_macros_test.test.user -env:CONFIGURATION_LAYERS=xcsxcu:file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/share/registry\ xcsxcu:file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/unittest/registry -env:UNO_TYPES=file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/program/types/offapi.rdb\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/program/types/oovbaapi.rdb\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/ure/share/misc/types.rdb -env:UNO_SERVICES=file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/Rdb/ure/services.rdb\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/basic/util/sb.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/comphelper/util/comphelp.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/configmgr/source/configmgr.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/dbaccess/util/dba.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/dbaccess/util/dbu.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/dbaccess/util/sdbt.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/dbaccess/source/filter/xml/dbaxml.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/filter/source/config/cache/filterconfig1.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/forms/util/frm.component\ file:///sources
Re: another cppunit test core dump, java this time, building on xstreamos/illumos
wowso? what can I do? is this cppunit stage necessary to complete the build? What if I could disable this and go on? would it possibly work? -- Da: Stephan Bergmann A: libreoffice@lists.freedesktop.org Data: 27 febbraio 2015 18.34.08 CET Oggetto: Re: another cppunit test core dump, java this time, building on xstreamos/illumos On 02/26/2015 12:35 PM, Gabriele Bulfon wrote: 0803d0e8 libc.so.1`_lwp_kill+0x15(1, 6, 10e3, fef66000, fef66000, 0) 0803d108 libc.so.1`raise+0x2b(6, 0, 803d120, efe70dd9, 0, 0) 0803d158 libc.so.1`abort+0x10e(0, f010, 803d308, effda2d3, 1, f00b877d) 0803d168 libjvm.so`__1cCosFabort6Fb_v_+0x51(1, f00b877d, 1, 7d0) 0803d308 libjvm.so`__1cHVMErrorOreport_and_die6M_v_+0xab3(803d380, 803d4b4) 0803d3d8 libjvm.so`JVM_handle_solaris_signal+0xa6e(b, 803d6b4, 803d4b4, 1) 0803d3f8 libjvm.so`signalHandler+0x26(b, 803d6b4, 803d4b4, fef66000, 803d470, feee7f73) 0803d410 libc.so.1`__sighndlr+0x15(b, 803d6b4, 803d4b4, ef81acd4, 0, 29) 0803d470 libc.so.1`call_user_handler+0x292(b, 803d6b4, 803d4b4, fe0749ee, 0, 29) 0803d4a0 libc.so.1`sigacthandler+0x77(b, 803d6b4, 803d4b4) 0803d758 libc.so.1`memcpy+0x1b(8, fd35c7bc, 1b, 0, fef6a380, fea90180) 0803d788 libuno_sal.so.3`rtl_uString_newFromStr_WithLength+0x63(803d7cc, fd35c7bc, 1b, fe0768b3, fef6ca00) [...] libfwklo.so`_ZN3com3sun4star3uno13WeakReferenceINS1_5frame7XFrame2EED1Ev+0x1d(f35cfc40, fef6a380, 803dab8, fec06f85, fec19ac0) 0803da98 libfwklo.so`_Z41__static_initialization_and_destruction_0ii+0x4c(0, , feffc480, ef2800c4, 803dad0, fefca3b1) 0803dab8 libfwklo.so`_GLOBAL__sub_D_frame.cxx+0x1a(803daf0, fefca394, feffb0a4, f32ed90a, f34cc000, f7b60018) 0803dad8 0xf32ed950(feffb0a4, fefcebf3, feffb0a4, f7b60018, 803db30, fefd21a8) 0803daf0 libfwklo.so`_fini+0x1b(feffc480, 0, f7b60018, f, 0, 8e) 0803db30 ld.so.1`call_fini+0xb3(feffc480, ef280018, 0, 0) 0803db60 ld.so.1`atexit_fini+0x66(0, 10, fef804f0, fef804f0, 101a, 6cf04) 0803dbb0 libc.so.1`__cxa_finalize+0x85(0, 10, 80560af, 0, fef66000, 803dbbc) 0803dbd0 libc.so.1`_exithandle+0x37(feffb0a4, 80560af, 0, 0, 803dc58, 8056042) 0803dbf4 libc.so.1`exit+0x12(15, 803e978, 803ea01, 803ea9d, 803eaa8, 803eb28) That would be apparently be static css::uno::WeakReference m_xCloserFrame; in framework/source/services/frame.cxx wreaking havoc when destroyed during exit. Looks like in your case rtl_allocateMemory is already returning nullptr, probably indicating that atexit handlers of sal are run prior to those of fwk, which would be a bug. That said, static data with destructor is always bad (and just a lucky coincidence this one appears to not wreak havoc elsewhere) and should be removed, but also I don't see any immediate way how to do it in this case. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: another cppunit test core dump, java this time, building on xstreamos/illumos
/scriptframe.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/sfx2/util/sfx.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/sot/util/sot.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/svl/source/fsstor/fsstorage.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/svl/util/svl.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/toolkit/util/tk.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/ucb/source/core/ucb1.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/ucb/source/ucp/file/ucpfile1.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/ucb/source/ucp/tdoc/ucptdoc1.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/unotools/util/utl.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/unoxml/source/rdf/unordf.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/unoxml/source/service/unoxml.component\ file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/ComponentTarget/xmloff/util/xo.component -env:URE_INTERNAL_LIB_DIR=file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/ure/lib -env:LO_LIB_DIR=file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/program -env:LO_JAVA_DIR=file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/program/classes --protector /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector --protector /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/LinkTarget/Library/unobootstrapprotector.so unobootstrapprotector --protector /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/LinkTarget/Library/libvclbootstrapprotector.so vclbootstrapprotector [Thread debugging using libthread_db enabled] [New Thread 1 (LWP 1)] [New LWP2] gobject.py: gdb was not built with custom backtrace support, disabling. [New LWP3] [New LWP4] [New Thread 4 (LWP 4)] [New LWP5] [LWP3 exited] [New LWP6] [New LWP7] [LWP5 exited] [LWP6 exited] OK (1) [New LWP8] [New LWP9] [New LWP10] [New LWP11] [New LWP12] [New LWP13] [New LWP14] [LWP4 exited] [Switching to Thread 4 (defunct)] sol_thread_fetch_registers: td_ta_map_id2thr: no thread can be found to satisfy query sol_thread_fetch_registers: td_ta_map_id2thr: no thread can be found to satisfy query sol_thread_fetch_registers: td_ta_map_id2thr: no thread can be found to satisfy query Da: Gabriele Bulfon A: Stephan Bergmann libreoffice-dev Data: 27 febbraio 2015 8.55.41 CET Oggetto: Re: another cppunit test core dump, java this time, building on xstreamos/illumos Maybe this is related? http://nabble.documentfoundation.org/dbaccess-macros-test-no-orderly-shutdown-td3748013.html Looks like it's trying to exit, but causing the coredump. The patch proposed seems to be in conflict with the current source: m_pEventBroadcaster-removeEventsForProcessor( this ); m_pEventBroadcaster-terminate(); //TODO: a protocol is missing how to join with the thread before // exit(3), to ensure the thread is no longer relying on any // infrastructure while that infrastructure is being shut down // in atexit handlers; simply calling join here leads to // deadlock, as this thread holds the solar mutex while the // other thread is typically blocked waiting for the solar mutex m_pEventBroadcaster.clear(); maybe I should try anyway? Da: Gabriele Bulfon A: Stephan Bergmann libreoffice-dev Data: 26 febbraio 2015 12.35.40 CET Oggetto: Re: another cppunit test core dump, java this time, building on xstreamos/illumos Thanks. Here is what illumos mdb shows of the core: $C 0803d0e8 libc.so.1`_lwp_kill+0x15(1, 6, 10e3, fef66000, fef66000
Re: another cppunit test core dump, java this time, building on xstreamos/illumos
Maybe this is related? http://nabble.documentfoundation.org/dbaccess-macros-test-no-orderly-shutdown-td3748013.html Looks like it's trying to exit, but causing the coredump. The patch proposed seems to be in conflict with the current source: m_pEventBroadcaster-removeEventsForProcessor( this ); m_pEventBroadcaster-terminate(); //TODO: a protocol is missing how to join with the thread before // exit(3), to ensure the thread is no longer relying on any // infrastructure while that infrastructure is being shut down // in atexit handlers; simply calling join here leads to // deadlock, as this thread holds the solar mutex while the // other thread is typically blocked waiting for the solar mutex m_pEventBroadcaster.clear(); maybe I should try anyway? Da: Gabriele Bulfon A: Stephan Bergmann libreoffice-dev Data: 26 febbraio 2015 12.35.40 CET Oggetto: Re: another cppunit test core dump, java this time, building on xstreamos/illumos Thanks. Here is what illumos mdb shows of the core: $C 0803d0e8 libc.so.1`_lwp_kill+0x15(1, 6, 10e3, fef66000, fef66000, 0) 0803d108 libc.so.1`raise+0x2b(6, 0, 803d120, efe70dd9, 0, 0) 0803d158 libc.so.1`abort+0x10e(0, f010, 803d308, effda2d3, 1, f00b877d) 0803d168 libjvm.so`__1cCosFabort6Fb_v_+0x51(1, f00b877d, 1, 7d0) 0803d308 libjvm.so`__1cHVMErrorOreport_and_die6M_v_+0xab3(803d380, 803d4b4) 0803d3d8 libjvm.so`JVM_handle_solaris_signal+0xa6e(b, 803d6b4, 803d4b4, 1) 0803d3f8 libjvm.so`signalHandler+0x26(b, 803d6b4, 803d4b4, fef66000, 803d470, feee7f73) 0803d410 libc.so.1`__sighndlr+0x15(b, 803d6b4, 803d4b4, ef81acd4, 0, 29) 0803d470 libc.so.1`call_user_handler+0x292(b, 803d6b4, 803d4b4, fe0749ee, 0, 29) 0803d4a0 libc.so.1`sigacthandler+0x77(b, 803d6b4, 803d4b4) 0803d758 libc.so.1`memcpy+0x1b(8, fd35c7bc, 1b, 0, fef6a380, fea90180) 0803d788 libuno_sal.so.3`rtl_uString_newFromStr_WithLength+0x63(803d7cc, fd35c7bc, 1b, fe0768b3, fef6ca00) 0803d7a8 libuno_sal.so.3`rtl_uString_newFromSubString+0xa0(803d7cc, fd35c7b0, 2, 1b, 803d884, 86c04f0) 0803d7d8 libuno_cppu.so.3`_ZNK3rtl8OUString4copyEl+0x48(803d818, 803d884, 2, 6, 859a3b8, fe670270) 0803d878 libuno_cppu.so.3`typelib_typedescription_getByName+0x66a(803d8f4, fd35c7b0, fd310738, 803da4c, f1fe0920, 803da40) 0803d8a8 libuno_cppu.so.3`typelib_typedescriptionreference_getDescription+0x122(803d8f4, 84b88f8, 52, f1f221f4, fea92a40, fe0a8000) 0803d8c8 libuno_cppu.so.3`TYPELIB_DANGER_GET+0x61(803d8f4, 84b88f8, 0, fef66000, fea92a40, 8092c50) 0803d908 libuno_cppu.so.3`uno_type_sequence_construct+0x35(803d968, 84b88f8, 0, 11, fe5df8aa, ef2800c0) 0803d948 libuno_cppuhelpergcc3.so.3`_ZN3com3sun4star3uno8SequenceINS2_9ReferenceINS2_10XInterfaceC1El+0x54(803d968, 11, 0, fee839fe, 8f, fe692000) 0803d988 libuno_cppuhelpergcc3.so.3`_ZN4cppuL23sequenceRemoveElementAtERN3com3sun4star3uno8SequenceINS3_9ReferenceINS3_10XInterfaceEl+0x41(f1863270, e, 803da78, fda35530, fd35f000, 6) 0803d9d8 libuno_cppuhelpergcc3.so.3`_ZN4cppu25OInterfaceContainerHelper15removeInterfaceERKN3com3sun4star3uno9ReferenceINS4_10XInterfaceEEE+0xb8(857594c, 803da18, fea92a40, feeebd0a, fea92a40) 0803d9f8 libuno_cppuhelpergcc3.so.3`_ZN4cppu20OWeakConnectionPoint15removeReferenceERKN3com3sun4star3uno9ReferenceINS4_10XReferenceEEE+0x2f(8575940, 803da18, fea92a40, feeebd0a, fec19ac0, 0) 0803da38 libuno_cppuhelpergcc3.so.3`_ZN3com3sun4star3uno19WeakReferenceHelper5clearEv+0x6e(f35cfc40, fef66000, fea92a40, 0, 803da60) 0803da58 libuno_cppuhelpergcc3.so.3`_ZN3com3sun4star3uno19WeakReferenceHelperD1Ev+0x1d(f35cfc40, fef66000, fea92a40, fef6a3c0, 803dab0) 0803da78 libfwklo.so`_ZN3com3sun4star3uno13WeakReferenceINS1_5frame7XFrame2EED1Ev+0x1d(f35cfc40, fef6a380, 803dab8, fec06f85, fec19ac0) 0803da98 libfwklo.so`_Z41__static_initialization_and_destruction_0ii+0x4c(0, , feffc480, ef2800c4, 803dad0, fefca3b1) 0803dab8 libfwklo.so`_GLOBAL__sub_D_frame.cxx+0x1a(803daf0, fefca394, feffb0a4, f32ed90a, f34cc000, f7b60018) 0803dad8 0xf32ed950(feffb0a4, fefcebf3, feffb0a4, f7b60018, 803db30, fefd21a8) 0803daf0 libfwklo.so`_fini+0x1b(feffc480, 0, f7b60018, f, 0, 8e) 0803db30 ld.so.1`call_fini+0xb3(feffc480, ef280018, 0, 0) 0803db60 ld.so.1`atexit_fini+0x66(0, 10, fef804f0, fef804f0, 101a, 6cf04) 0803dbb0 libc.so.1`__cxa_finalize+0x85(0, 10, 80560af, 0, fef66000, 803dbbc) 0803dbd0 libc.so.1`_exithandle+0x37(feffb0a4, 80560af, 0, 0, 803dc58, 8056042) 0803dbf4 libc.so.1`exit+0x12(15, 803e978, 803ea01, 803ea9d, 803eaa8, 803eb28) -- Da: Stephan Bergmann A: libreoffice-dev Data: 26 febbraio 2015 12.29.00 CET Oggetto: Re: another cppunit test core dump, java this time, building on xstreamos/illumos On 02/26/2015 12:10 PM, Gabriele Bulfon wrote: # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0xfee6293b, pid=22271, tid=1 # # JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build 1.7.0_45-b18) # Java VM: Java HotSpot(TM) Client VM (24.45
Re: another cppunit test core dump, java this time, building on xstreamos/illumos
Thanks. Here is what illumos mdb shows of the core: $C 0803d0e8 libc.so.1`_lwp_kill+0x15(1, 6, 10e3, fef66000, fef66000, 0) 0803d108 libc.so.1`raise+0x2b(6, 0, 803d120, efe70dd9, 0, 0) 0803d158 libc.so.1`abort+0x10e(0, f010, 803d308, effda2d3, 1, f00b877d) 0803d168 libjvm.so`__1cCosFabort6Fb_v_+0x51(1, f00b877d, 1, 7d0) 0803d308 libjvm.so`__1cHVMErrorOreport_and_die6M_v_+0xab3(803d380, 803d4b4) 0803d3d8 libjvm.so`JVM_handle_solaris_signal+0xa6e(b, 803d6b4, 803d4b4, 1) 0803d3f8 libjvm.so`signalHandler+0x26(b, 803d6b4, 803d4b4, fef66000, 803d470, feee7f73) 0803d410 libc.so.1`__sighndlr+0x15(b, 803d6b4, 803d4b4, ef81acd4, 0, 29) 0803d470 libc.so.1`call_user_handler+0x292(b, 803d6b4, 803d4b4, fe0749ee, 0, 29) 0803d4a0 libc.so.1`sigacthandler+0x77(b, 803d6b4, 803d4b4) 0803d758 libc.so.1`memcpy+0x1b(8, fd35c7bc, 1b, 0, fef6a380, fea90180) 0803d788 libuno_sal.so.3`rtl_uString_newFromStr_WithLength+0x63(803d7cc, fd35c7bc, 1b, fe0768b3, fef6ca00) 0803d7a8 libuno_sal.so.3`rtl_uString_newFromSubString+0xa0(803d7cc, fd35c7b0, 2, 1b, 803d884, 86c04f0) 0803d7d8 libuno_cppu.so.3`_ZNK3rtl8OUString4copyEl+0x48(803d818, 803d884, 2, 6, 859a3b8, fe670270) 0803d878 libuno_cppu.so.3`typelib_typedescription_getByName+0x66a(803d8f4, fd35c7b0, fd310738, 803da4c, f1fe0920, 803da40) 0803d8a8 libuno_cppu.so.3`typelib_typedescriptionreference_getDescription+0x122(803d8f4, 84b88f8, 52, f1f221f4, fea92a40, fe0a8000) 0803d8c8 libuno_cppu.so.3`TYPELIB_DANGER_GET+0x61(803d8f4, 84b88f8, 0, fef66000, fea92a40, 8092c50) 0803d908 libuno_cppu.so.3`uno_type_sequence_construct+0x35(803d968, 84b88f8, 0, 11, fe5df8aa, ef2800c0) 0803d948 libuno_cppuhelpergcc3.so.3`_ZN3com3sun4star3uno8SequenceINS2_9ReferenceINS2_10XInterfaceC1El+0x54(803d968, 11, 0, fee839fe, 8f, fe692000) 0803d988 libuno_cppuhelpergcc3.so.3`_ZN4cppuL23sequenceRemoveElementAtERN3com3sun4star3uno8SequenceINS3_9ReferenceINS3_10XInterfaceEl+0x41(f1863270, e, 803da78, fda35530, fd35f000, 6) 0803d9d8 libuno_cppuhelpergcc3.so.3`_ZN4cppu25OInterfaceContainerHelper15removeInterfaceERKN3com3sun4star3uno9ReferenceINS4_10XInterfaceEEE+0xb8(857594c, 803da18, fea92a40, feeebd0a, fea92a40) 0803d9f8 libuno_cppuhelpergcc3.so.3`_ZN4cppu20OWeakConnectionPoint15removeReferenceERKN3com3sun4star3uno9ReferenceINS4_10XReferenceEEE+0x2f(8575940, 803da18, fea92a40, feeebd0a, fec19ac0, 0) 0803da38 libuno_cppuhelpergcc3.so.3`_ZN3com3sun4star3uno19WeakReferenceHelper5clearEv+0x6e(f35cfc40, fef66000, fea92a40, 0, 803da60) 0803da58 libuno_cppuhelpergcc3.so.3`_ZN3com3sun4star3uno19WeakReferenceHelperD1Ev+0x1d(f35cfc40, fef66000, fea92a40, fef6a3c0, 803dab0) 0803da78 libfwklo.so`_ZN3com3sun4star3uno13WeakReferenceINS1_5frame7XFrame2EED1Ev+0x1d(f35cfc40, fef6a380, 803dab8, fec06f85, fec19ac0) 0803da98 libfwklo.so`_Z41__static_initialization_and_destruction_0ii+0x4c(0, , feffc480, ef2800c4, 803dad0, fefca3b1) 0803dab8 libfwklo.so`_GLOBAL__sub_D_frame.cxx+0x1a(803daf0, fefca394, feffb0a4, f32ed90a, f34cc000, f7b60018) 0803dad8 0xf32ed950(feffb0a4, fefcebf3, feffb0a4, f7b60018, 803db30, fefd21a8) 0803daf0 libfwklo.so`_fini+0x1b(feffc480, 0, f7b60018, f, 0, 8e) 0803db30 ld.so.1`call_fini+0xb3(feffc480, ef280018, 0, 0) 0803db60 ld.so.1`atexit_fini+0x66(0, 10, fef804f0, fef804f0, 101a, 6cf04) 0803dbb0 libc.so.1`__cxa_finalize+0x85(0, 10, 80560af, 0, fef66000, 803dbbc) 0803dbd0 libc.so.1`_exithandle+0x37(feffb0a4, 80560af, 0, 0, 803dc58, 8056042) 0803dbf4 libc.so.1`exit+0x12(15, 803e978, 803ea01, 803ea9d, 803eaa8, 803eb28) -- Da: Stephan Bergmann A: libreoffice-dev Data: 26 febbraio 2015 12.29.00 CET Oggetto: Re: another cppunit test core dump, java this time, building on xstreamos/illumos On 02/26/2015 12:10 PM, Gabriele Bulfon wrote: # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0xfee6293b, pid=22271, tid=1 # # JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build 1.7.0_45-b18) # Java VM: Java HotSpot(TM) Client VM (24.45-b08 mixed mode solaris-x86 ) # Problematic frame: # C [libc.so.1+0x4293b] memcpy+0x1b # # Core dump written. Default location: /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/CppunitTest/dbaccess_macros_test.test.core/core or core.22271 # # An error report file with more information is saved as: # /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/CppunitTest/dbaccess_macros_test.test.core/hs_err_pid22271.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # It looks like /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/LinkTarget/Executable/cppunittester generated a core file at /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/CppunitTest
another cppunit test core dump, java this time, building on xstreamos/illumos
Hi,
build is moving forward, got past the nss/openssl issues (I will want to see
how to let nss work later).
All libs and binaries look to be built correctly under instdir/program, ldd
shows no unresolved issues now.
Here is what happens now.
Let me know if you need any other log/dump infos
[build CUT] dbaccess_macros_test
S=/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3
I=$S/instdir W=$S/workdir mkdir -p $W/CppunitTest/ rm -fr
$W/CppunitTest/dbaccess_macros_test.test.user mkdir
$W/CppunitTest/dbaccess_macros_test.test.userrm -fr
$W/CppunitTest/dbaccess_macros_test.test.core mkdir
$W/CppunitTest/dbaccess_macros_test.test.core cd
$W/CppunitTest/dbaccess_macros_test.test.core
(LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}$I/ure/lib:$I/program:$W/UnpackedTarball/cppunit/src/cppunit/.libs
$W/LinkTarget/Executable/cppunittester
$W/LinkTarget/CppunitTest/libtest_dbaccess_macros_test.so --headless
-env:BRAND_BASE_DIR=file://$S/instdir -env:BRAND_SHARE_SUBDIR=share
-env:UserInstallation=file://$W/CppunitTest/dbaccess_macros_test.test.user
-env:CONFIGURATION_LAYERS=xcsxcu:file://$I/share/registry
xcsxcu:file://$W/unittest/registry
-env:UNO_TYPES=file://$I/program/types/offapi.rdb
file://$I/program/types/oovbaapi.rdb file://$I/ure/share/misc/types.rdb
-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb
file://$W/ComponentTarget/basic/util/sb.component
file://$W/ComponentTarget/comphelper/util/comphelp.component
file://$W/ComponentTarget/configmgr/source/configmgr.component
file://$W/ComponentTarget/dbaccess/util/dba.component
file://$W/ComponentTarget/dbaccess/util/dbu.component
file://$W/ComponentTarget/dbaccess/util/sdbt.component
file://$W/ComponentTarget/dbaccess/source/filter/xml/dbaxml.component
file://$W/ComponentTarget/filter/source/config/cache/filterconfig1.component
file://$W/ComponentTarget/forms/util/frm.component
file://$W/ComponentTarget/framework/util/fwk.component
file://$W/ComponentTarget/i18npool/util/i18npool.component
file://$W/ComponentTarget/oox/util/oox.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/scripting/source/basprov/basprov.component
file://$W/ComponentTarget/scripting/util/scriptframe.component
file://$W/ComponentTarget/sfx2/util/sfx.component
file://$W/ComponentTarget/sot/util/sot.component
file://$W/ComponentTarget/svl/source/fsstor/fsstorage.component
file://$W/ComponentTarget/svl/util/svl.component
file://$W/ComponentTarget/toolkit/util/tk.component
file://$W/ComponentTarget/ucb/source/core/ucb1.component
file://$W/ComponentTarget/ucb/source/ucp/file/ucpfile1.component
file://$W/ComponentTarget/ucb/source/ucp/tdoc/ucptdoc1.component
file://$W/ComponentTarget/unotools/util/utl.component
file://$W/ComponentTarget/unoxml/source/rdf/unordf.component
file://$W/ComponentTarget/unoxml/source/service/unoxml.component
file://$W/ComponentTarget/xmloff/util/xo.component
-env:URE_INTERNAL_LIB_DIR=file://$I/ure/lib -env:LO_LIB_DIR=file://$I/program
-env:LO_JAVA_DIR=file://$I/program/classes --protector
$W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector
--protector $W/LinkTarget/Library/unobootstrapprotector.so
unobootstrapprotector --protector
$W/LinkTarget/Library/libvclbootstrapprotector.so
vclbootstrapprotector$W/CppunitTest/dbaccess_macros_test.test.log 21;|| (
RET=$?; $S/solenv/bin/gdb-core-bt.sh $W/LinkTarget/Executable/cppunittester
$W/CppunitTest/dbaccess_macros_test.test.core
$RET$W/CppunitTest/dbaccess_macros_test.test.log 21; cat
$W/CppunitTest/dbaccess_macros_test.test.log; $S/solenv/bin/unittest-failed.sh
Cppunit dbaccess_macros_test))
/bin/sh: line 1: 22271: Abort(coredump)
OK (1)
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0xfee6293b, pid=22271, tid=1
#
# JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build 1.7.0_45-b18)
# Java VM: Java HotSpot(TM) Client VM (24.45-b08 mixed mode solaris-x86 )
# Problematic frame:
# C [libc.so.1+0x4293b] memcpy+0x1b
#
# Core dump written. Default location:
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/CppunitTest/dbaccess_macros_test.test.core/core
or core.22271
#
# An error report file with more information is saved as:
#
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/CppunitTest/dbaccess_macros_test.test.core/hs_err_pid22271.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.sun.com/bugreport/crash.jsp
#
It looks like
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/LinkTarget/Executable/cppunittester
generated a core file at
Re: error during build of mork_helper, on illumos/xstreamos
Yes, this way is much better than replicating the LINUX part into SOLARIS. I had to do the same on some other mk. I'll send you the full patch zip as soon as I reach a full build with no errors. -- Da: Richard PALO A: libreoffice Data: 22 febbraio 2015 9.13.14 CET Oggetto: Re: error during build of mork_helper, on illumos/xstreamos -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 21/02/15 08:29, Richard PALO a écrit : In pkgsrc this is patched as follows: $NetBSD: patch-vcl_Library__vcl.mk,v 1.1 2015/02/04 18:19:34 ryoon Exp $ --- vcl/Library_vcl.mk.orig 2015-01-22 20:05:28.0 + +++ vcl/Library_vcl.mk @@ -703,7 +703,7 @@ endif endif endif -ifeq ($(OS),LINUX) +ifeq ($(GUIBASE),unx) $(eval $(call gb_Library_add_libs,vcl,\ -lm \ -ldl \ If this works for you, I'll prepare to upstream this patch. The author of this patch responded to me that he'll upstream this himself as well as a few others of the same sort (in pkgsrc) soon. As to the '-Wl,-Bdirect' and '-Wl,-zdefs' in solaris.mk I'm testing if this passes, if so I'll upstream that as well.. (builds/runs here without it, at least on gcc49) As hoped, I had no fallout from this so will submit the reintegration of this bit to gerritt today. - -- Richard PALO -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJU6Y+aAAoJECAB22fHtp27oOYIAIBtDwPr7U2HfCrbFNNSOsbU zZZj+qfLv4DbLUm3ZdCS5zwYUwl/agEkltsO+tolzhTT6YFIMXqxNffMbFrITh9z TmMu6PgR8JtXhnfzyWhT9gxNucNphKiwc2wwvWNDyxe5bOPYWIZTDtkGKWNbPjuE +sLGGIZ7YBaiFazRww/3cFKy+YwmOyXBFCsS3LhHEw8bgn/UnwdA0kmgBsSkYmKw YTwPd4iqm0kKis54jnr8CElzUb/Unzv6Sjz6JmNdbZc+OpSsQhFrela7IZJWSs7N oNe2TmDZrNv8XGLTlsvipA4lZNCSWJ5fiPOp19NkX0YezrEFTFmP8uL3uL2w3hA= =SRUy -END PGP SIGNATURE- ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
cppunit errors in vcl_app_test, on illumos/xstreamos
I almost have it done. All libs compile, binaries too, but I get this: terminate called after throwing an instance of 'CppUnit::DynamicLibraryManagerException' what(): Failed to load dynamic library: /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/LinkTarget/CppunitTest/libtest_vcl_app_test.so It looks like /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/LinkTarget/Executable/cppunittester generated a core file at /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/CppunitTest/vcl_app_test.test.core/core Backtraces: [New LWP 1] [New LWP 1] ... ... What I noticed is that many of the libs, built before vcl lib, shows a correct linking with ldd. Some others, just after vcl lib and vcl lib itself, shows the strange gcc link problem: libstdc++.so.6 =/usr/sfw/lib/libstdc++.so.6 libstdc++.so.6 (GLIBCXX_3.4.15) =(version not found) libstdc++.so.6 (CXXABI_1.3) =(version not found) and elfdump shows why: [67] RUNPATH 0x428ac4 /usr/sfw/lib:/usr/gcc/4.7/lib:$ORIGIN:$ORIGIN/../ure-link/lib:/usr/lib/mps [68] RPATH 0x428ac4 /usr/sfw/lib:/usr/gcc/4.7/lib:$ORIGIN:$ORIGIN/../ure-link/lib:/usr/lib/mps why /usr/sfw/lib is placed before /usr/gcc/4.7/lib?? who is doing this?? I have forced -Wl,-rpath,/usr/gcc/4.7/lib -L/usr/gcc/4.7/lib in LDFLAGS during configure and make. I believe /usr/sfw/lib is taken automagically by the build system because there's a libstdc++.so.6 (an old 3.4 for compatibiliy). Maybe this is causing the cppunit failure? -- Da: Richard PALO A: libreoffice Data: 22 febbraio 2015 9.13.14 CET Oggetto: Re: error during build of mork_helper, on illumos/xstreamos -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 21/02/15 08:29, Richard PALO a écrit : In pkgsrc this is patched as follows: $NetBSD: patch-vcl_Library__vcl.mk,v 1.1 2015/02/04 18:19:34 ryoon Exp $ --- vcl/Library_vcl.mk.orig 2015-01-22 20:05:28.0 + +++ vcl/Library_vcl.mk @@ -703,7 +703,7 @@ endif endif endif -ifeq ($(OS),LINUX) +ifeq ($(GUIBASE),unx) $(eval $(call gb_Library_add_libs,vcl,\ -lm \ -ldl \ If this works for you, I'll prepare to upstream this patch. The author of this patch responded to me that he'll upstream this himself as well as a few others of the same sort (in pkgsrc) soon. As to the '-Wl,-Bdirect' and '-Wl,-zdefs' in solaris.mk I'm testing if this passes, if so I'll upstream that as well.. (builds/runs here without it, at least on gcc49) As hoped, I had no fallout from this so will submit the reintegration of this bit to gerritt today. - -- Richard PALO -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJU6Y+aAAoJECAB22fHtp27oOYIAIBtDwPr7U2HfCrbFNNSOsbU zZZj+qfLv4DbLUm3ZdCS5zwYUwl/agEkltsO+tolzhTT6YFIMXqxNffMbFrITh9z TmMu6PgR8JtXhnfzyWhT9gxNucNphKiwc2wwvWNDyxe5bOPYWIZTDtkGKWNbPjuE +sLGGIZ7YBaiFazRww/3cFKy+YwmOyXBFCsS3LhHEw8bgn/UnwdA0kmgBsSkYmKw YTwPd4iqm0kKis54jnr8CElzUb/Unzv6Sjz6JmNdbZc+OpSsQhFrela7IZJWSs7N oNe2TmDZrNv8XGLTlsvipA4lZNCSWJ5fiPOp19NkX0YezrEFTFmP8uL3uL2w3hA= =SRUy -END PGP SIGNATURE- ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: cppunit errors in vcl_app_test, on illumos/xstreamos
Oh yes, I found this in Library_vcl.mk: ifeq ($(CPUNAME),SPARC64) $(eval $(call gb_Library_add_ldflags,vcl,\ -R/usr/sfw/lib/64 \ )) else $(eval $(call gb_Library_add_ldflags,vcl,\ -R/usr/sfw/lib \ )) endif My system fall into the else section...and this is breaking my build. I will try commenting out this and rebuild from scratch. There should be a better way to patch this. Gabriele. Da: Gabriele Bulfon A: Richard PALO libreoffice Data: 23 febbraio 2015 9.27.01 CET Oggetto: cppunit errors in vcl_app_test, on illumos/xstreamos I almost have it done. All libs compile, binaries too, but I get this: terminate called after throwing an instance of 'CppUnit::DynamicLibraryManagerException' what(): Failed to load dynamic library: /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/LinkTarget/CppunitTest/libtest_vcl_app_test.so It looks like /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/LinkTarget/Executable/cppunittester generated a core file at /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/CppunitTest/vcl_app_test.test.core/core Backtraces: [New LWP 1] [New LWP 1] ... ... What I noticed is that many of the libs, built before vcl lib, shows a correct linking with ldd. Some others, just after vcl lib and vcl lib itself, shows the strange gcc link problem: libstdc++.so.6 =/usr/sfw/lib/libstdc++.so.6 libstdc++.so.6 (GLIBCXX_3.4.15) =(version not found) libstdc++.so.6 (CXXABI_1.3) =(version not found) and elfdump shows why: [67] RUNPATH 0x428ac4 /usr/sfw/lib:/usr/gcc/4.7/lib:$ORIGIN:$ORIGIN/../ure-link/lib:/usr/lib/mps [68] RPATH 0x428ac4 /usr/sfw/lib:/usr/gcc/4.7/lib:$ORIGIN:$ORIGIN/../ure-link/lib:/usr/lib/mps why /usr/sfw/lib is placed before /usr/gcc/4.7/lib?? who is doing this?? I have forced -Wl,-rpath,/usr/gcc/4.7/lib -L/usr/gcc/4.7/lib in LDFLAGS during configure and make. I believe /usr/sfw/lib is taken automagically by the build system because there's a libstdc++.so.6 (an old 3.4 for compatibiliy). Maybe this is causing the cppunit failure? -- Da: Richard PALO A: libreoffice Data: 22 febbraio 2015 9.13.14 CET Oggetto: Re: error during build of mork_helper, on illumos/xstreamos -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 21/02/15 08:29, Richard PALO a écrit : In pkgsrc this is patched as follows: $NetBSD: patch-vcl_Library__vcl.mk,v 1.1 2015/02/04 18:19:34 ryoon Exp $ --- vcl/Library_vcl.mk.orig 2015-01-22 20:05:28.0 + +++ vcl/Library_vcl.mk @@ -703,7 +703,7 @@ endif endif endif -ifeq ($(OS),LINUX) +ifeq ($(GUIBASE),unx) $(eval $(call gb_Library_add_libs,vcl,\ -lm \ -ldl \ If this works for you, I'll prepare to upstream this patch. The author of this patch responded to me that he'll upstream this himself as well as a few others of the same sort (in pkgsrc) soon. As to the '-Wl,-Bdirect' and '-Wl,-zdefs' in solaris.mk I'm testing if this passes, if so I'll upstream that as well.. (builds/runs here without it, at least on gcc49) As hoped, I had no fallout from this so will submit the reintegration of this bit to gerritt today. - -- Richard PALO -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJU6Y+aAAoJECAB22fHtp27oOYIAIBtDwPr7U2HfCrbFNNSOsbU zZZj+qfLv4DbLUm3ZdCS5zwYUwl/agEkltsO+tolzhTT6YFIMXqxNffMbFrITh9z TmMu6PgR8JtXhnfzyWhT9gxNucNphKiwc2wwvWNDyxe5bOPYWIZTDtkGKWNbPjuE +sLGGIZ7YBaiFazRww/3cFKy+YwmOyXBFCsS3LhHEw8bgn/UnwdA0kmgBsSkYmKw YTwPd4iqm0kKis54jnr8CElzUb/Unzv6Sjz6JmNdbZc+OpSsQhFrela7IZJWSs7N oNe2TmDZrNv8XGLTlsvipA4lZNCSWJ5fiPOp19NkX0YezrEFTFmP8uL3uL2w3hA= =SRUy -END PGP SIGNATURE- ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___LibreOffice mailing listLibreOffice@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[found]: error during build of mork_helper, on illumos/xstreamos
Libcups is broken, has a stupid bug when built under Solaris : the so file
comes up referencing a main... Looks like this doesn't happen on Linux because
of differences between linkers.
So when you link against libcups, and it's not a program but a shared library,
I faked a main in an object file, and it went on for that library.
...pity there are many in LO linking libcups
I'm checking with illumos guys for any existent patch for libcups.
Thanks :)
Gabriele
Inviato da iPad
Il giorno 20/feb/2015, alle ore 16:23, Gabriele Bulfon
gabriele.bul...@sonicle.com ha scritto:
I believe here g++ is commanding the ld linker, so -shared is interpreted
by g++ and translated into solaris linking.
All the previous .so files are linked the same way with no issue.
What is strange here, is that libcups.so is referencing a main!
I will check for other components linking cups if they use specific flags.
--
Da: Stephan Bergmann sberg...@redhat.com
A: libreoffice@lists.freedesktop.org
Data: 20 febbraio 2015 15.50.12 CET
Oggetto: Re: error during build of mork_helper, on illumos/xstreamos
On 02/20/2015 09:52 AM, Gabriele Bulfon wrote:
Undefined first referenced
symbol in file
main /usr/lib/libcups.so
??? looking for a main in libcups.so???
here is what it's trying to do:
[build LNK] Library/libvcllo.so
S=/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3
I=$S/instdir W=$S/workdir mkdir -p $W/Dep/LinkTarget/Library/
RESPONSEFILE=/tmp/gbuild.OgyDJO
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}$I/ure/lib:$I/program
$W/LinkTarget/Executable/concat-deps ${RESPONSEFILE}
$W/Dep/LinkTarget/Library/libvcllo.so.d.tmp rm -f ${RESPONSEFILE}
mv
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/Dep/LinkTarget/Library/libvcllo.so.d.tmp
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/Dep/LinkTarget/Library/libvcllo.so.d
S=/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3
I=$S/instdir W=$S/workdir /usr/gcc/4.7/bin/g++ -shared
Didn't the Solaris linker use something like -G to tell it to build a
shared library? Maybe the GCC -shared doesn't properly translate to
something useful for the linker in your tool-chain.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: error during build of mork_helper, on illumos/xstreamos
$W/CxxObject/vcl/source/app/i18nhelp.o $W/CxxObject/vcl/source/app/idlemgr.o $W/CxxObject/vcl/source/app/salvtables.o $W/CxxObject/vcl/source/app/session.o $W/CxxObject/vcl/source/app/settings.o $W/CxxObject/vcl/source/app/IconThemeInfo.o $W/CxxObject/vcl/source/app/IconThemeScanner.o $W/CxxObject/vcl/source/app/IconThemeSelector.o $W/CxxObject/vcl/source/app/sound.o $W/CxxObject/vcl/source/app/stdtext.o $W/CxxObject/vcl/source/app/svapp.o $W/CxxObject/vcl/source/app/svdata.o $W/CxxObject/vcl/source/app/svmain.o $W/CxxObject/vcl/source/app/svmainhook.o $W/CxxObject/vcl/source/app/timer.o $W/CxxObject/vcl/source/app/unohelp2.o $W/CxxObject/vcl/source/app/unohelp.o $W/CxxObject/vcl/source/app/vclevent.o $W/CxxObject/vcl/source/components/dtranscomp.o $W/CxxObject/vcl/source/components/factory.o $W/CxxObject/vcl/source/components/fontident.o $W/CxxObject/vcl/source/filter/FilterConfigCache.o $W/CxxObject/vcl/source/filter/FilterConfigItem.o $W/CxxObject/vcl/source/filter/graphicfilter.o $W/CxxObject/vcl/source/filter/graphicfilter2.o $W/CxxObject/vcl/source/filter/GraphicNativeTransform.o $W/CxxObject/vcl/source/filter/GraphicNativeMetadata.o $W/CxxObject/vcl/source/filter/sgfbram.o $W/CxxObject/vcl/source/filter/sgvmain.o $W/CxxObject/vcl/source/filter/sgvspln.o $W/CxxObject/vcl/source/filter/sgvtext.o $W/CxxObject/vcl/source/filter/igif/decode.o $W/CxxObject/vcl/source/filter/igif/gifread.o $W/CxxObject/vcl/source/filter/ixbm/xbmread.o $W/CxxObject/vcl/source/filter/ixpm/xpmread.o $W/CxxObject/vcl/source/filter/jpeg/Exif.o $W/CxxObject/vcl/source/filter/jpeg/jpeg.o $W/CxxObject/vcl/source/filter/jpeg/jpegc.o $W/CxxObject/vcl/source/filter/jpeg/JpegReader.o $W/CxxObject/vcl/source/filter/jpeg/JpegWriter.o $W/CxxObject/vcl/source/filter/jpeg/JpegTransform.o $W/CxxObject/vcl/source/filter/wmf/emfwr.o $W/CxxObject/vcl/source/filter/wmf/enhwmf.o $W/CxxObject/vcl/source/filter/wmf/winmtf.o $W/CxxObject/vcl/source/filter/wmf/winwmf.o $W/CxxObject/vcl/source/filter/wmf/wmf.o $W/CxxObject/vcl/source/filter/wmf/wmfwr.o $W/CxxObject/vcl/source/font/PhysicalFontCollection.o $W/CxxObject/vcl/source/font/PhysicalFontFace.o $W/CxxObject/vcl/source/font/PhysicalFontFamily.o $W/CxxObject/vcl/source/fontsubset/cff.o $W/CxxObject/vcl/source/fontsubset/fontsubset.o $W/CxxObject/vcl/source/fontsubset/gsub.o $W/CxxObject/vcl/source/fontsubset/list.o $W/CxxObject/vcl/source/fontsubset/sft.o $W/CxxObject/vcl/source/fontsubset/ttcr.o $W/CxxObject/vcl/source/fontsubset/xlat.o $W/CxxObject/vcl/generic/app/gensys.o $W/CxxObject/vcl/generic/app/geninst.o $W/CxxObject/vcl/generic/app/gendisp.o $W/CxxObject/vcl/generic/print/bitmap_gfx.o $W/CxxObject/vcl/generic/print/common_gfx.o $W/CxxObject/vcl/generic/print/glyphset.o $W/CxxObject/vcl/generic/print/printerjob.o $W/CxxObject/vcl/generic/print/psputil.o $W/CxxObject/vcl/generic/print/genpspgraphics.o $W/CxxObject/vcl/generic/print/genprnpsp.o $W/CxxObject/vcl/generic/print/prtsetup.o $W/CxxObject/vcl/generic/print/text_gfx.o $W/CxxObject/vcl/generic/fontmanager/fontsubst.o $W/CxxObject/vcl/generic/glyphs/gcach_ftyp.o $W/CxxObject/vcl/generic/glyphs/gcach_layout.o $W/CxxObject/vcl/generic/glyphs/gcach_rbmp.o $W/CxxObject/vcl/generic/glyphs/glyphcache.o $W/CxxObject/vcl/generic/glyphs/scrptrun.o $W/CxxObject/vcl/generic/fontmanager/fontcache.o $W/CxxObject/vcl/generic/fontmanager/fontconfig.o $W/CxxObject/vcl/generic/fontmanager/fontmanager.o $W/CxxObject/vcl/generic/fontmanager/helper.o $W/CxxObject/vcl/generic/fontmanager/parseAFM.o $W/CxxObject/vcl/unx/generic/plugadapt/salplug.o $W/CxxObject/vcl/unx/generic/printer/jobdata.o $W/CxxObject/vcl/unx/generic/printer/ppdparser.o $W/CxxObject/vcl/unx/generic/gdi/x11windowprovider.o $W/CxxObject/vcl/unx/generic/printer/cupsmgr.o $W/CxxObject/vcl/unx/generic/printer/printerinfomanager.o $W/CxxObject/vcl/opengl/x11/X11DeviceInfo.o -Wl,--start-group -lm -lnsl -lsocket -lstdc++ -ljpeg -Wl,-rpath,/usr/lib/mps -L/usr/lib/mps -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lGLEW -lGLU -lGL -lharfbuzz -licuuc -llcms2 -lcups -ldbus-glib-1 -ldbus-1 -lgobject-2.0 -lglib-2.0-lfontconfig -lfreetype -lm -ldl -lpthread -lGL -lGLU -lX11 -Wl,--end-group -Wl,-zrecord -lsvllo -ltllo -lutllo -lsotlo -lucbhelper -lbasegfxlo -lcomphelper -luno_cppuhelpergcc3 -li18nlangtag -li18nutil -luno_cppu -luno_sal -luno_salhelpergcc3 -lxmlreaderlo -ljvmaccesslo -o $I/program/libvcllo.so -- Da: Michael Stahl A: libreoffice@lists.freedesktop.org Data: 19 febbraio 2015 23.06.08 CET Oggetto: Re: error during build of mork_helper, on illumos/xstreamos On 19.02.2015 19:13, Gabriele Bulfon wrote: *Da:* Gabriele Bulfon *A:* libreoffice@lists.freedesktop.org *Data:* 19 febbraio 2015 13.04.57 CET *Oggetto:* error during build
Re: error during build of mork_helper, on illumos/xstreamos
I believe here g++ is commanding the ld linker, so -shared is interpreted by
g++ and translated into solaris linking.
All the previous .so files are linked the same way with no issue.
What is strange here, is that libcups.so is referencing a main!
I will check for other components linking cups if they use specific flags.
--
Da: Stephan Bergmann
A: libreoffice@lists.freedesktop.org
Data: 20 febbraio 2015 15.50.12 CET
Oggetto: Re: error during build of mork_helper, on illumos/xstreamos
On 02/20/2015 09:52 AM, Gabriele Bulfon wrote:
Undefined first referenced
symbol in file
main /usr/lib/libcups.so
??? looking for a main in libcups.so???
here is what it's trying to do:
[build LNK] Library/libvcllo.so
S=/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3
I=$S/instdir W=$S/workdir mkdir -p $W/Dep/LinkTarget/Library/
RESPONSEFILE=/tmp/gbuild.OgyDJO
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}$I/ure/lib:$I/program
$W/LinkTarget/Executable/concat-deps ${RESPONSEFILE}
$W/Dep/LinkTarget/Library/libvcllo.so.d.tmp rm -f ${RESPONSEFILE}
mv
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/Dep/LinkTarget/Library/libvcllo.so.d.tmp
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/Dep/LinkTarget/Library/libvcllo.so.d
S=/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3
I=$S/instdir W=$S/workdir /usr/gcc/4.7/bin/g++ -shared
Didn't the Solaris linker use something like -G to tell it to build a
shared library? Maybe the GCC -shared doesn't properly translate to
something useful for the linker in your tool-chain.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice-commits] core.git: Branch 'libreoffice-4-4' - bridges/Library_cpp_uno.mk bridges/source
bridges/Library_cpp_uno.mk |1
bridges/source/cpp_uno/gcc3_solaris_intel/callvirtualmethod.cxx | 117
++
bridges/source/cpp_uno/gcc3_solaris_intel/callvirtualmethod.hxx | 50
bridges/source/cpp_uno/gcc3_solaris_intel/uno2cpp.cxx | 88 ---
4 files changed, 171 insertions(+), 85 deletions(-)
New commits:
commit 4801b29677462f7206fa281f06646e5cd8d81bfa
Author: Gabriele Bulfon gabriele.bul...@sonicle.com
Date: Thu Feb 19 14:36:39 2015 +0100
Adapt gcc3_solaris_intel bridge to GCC 4.7
...similarly to 0fdbb5b0eabbaa571f3747fda12a56c938cba474 Make
cpp_uno/gcc3_linux_x86-64 bridge work with GCC 4.7
Change-Id: Idcafcb07678d02446172d7fde30631a342f6437e
(cherry picked from commit 834afd885bd74ff80b59898d3f63ba940a58c1d8)
Signed-off-by: Michael Stahl mst...@redhat.com
diff --git a/bridges/Library_cpp_uno.mk b/bridges/Library_cpp_uno.mk
index 5b7377a..61ffa29 100644
--- a/bridges/Library_cpp_uno.mk
+++ b/bridges/Library_cpp_uno.mk
@@ -74,6 +74,7 @@ bridge_noncallexception_objects := callvirtualmethod
else ifeq ($(OS),SOLARIS)
bridges_SELECTED_BRIDGE := gcc3_solaris_intel
bridge_exception_objects := cpp2uno except uno2cpp
+bridge_noncallexception_objects := callvirtualmethod
else ifeq ($(COM),MSC)
bridges_SELECTED_BRIDGE := msvc_win32_intel
bridge_exception_objects := cpp2uno dllinit uno2cpp
diff --git a/bridges/source/cpp_uno/gcc3_solaris_intel/callvirtualmethod.cxx
b/bridges/source/cpp_uno/gcc3_solaris_intel/callvirtualmethod.cxx
new file mode 100644
index 000..00f9bdc
--- /dev/null
+++ b/bridges/source/cpp_uno/gcc3_solaris_intel/callvirtualmethod.cxx
@@ -0,0 +1,117 @@
+/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
+/*
+ * This file is part of the LibreOffice project.
+ *
+ * This Source Code Form is subject to the terms of the Mozilla Public
+ * License, v. 2.0. If a copy of the MPL was not distributed with this
+ * file, You can obtain one at http://mozilla.org/MPL/2.0/.
+ *
+ * This file incorporates work covered by the following license notice:
+ *
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed
+ * with this work for additional information regarding copyright
+ * ownership. The ASF licenses this file to you under the Apache
+ * License, Version 2.0 (the License); you may not use this file
+ * except in compliance with the License. You may obtain a copy of
+ * the License at http://www.apache.org/licenses/LICENSE-2.0 .
+ */
+
+#include com/sun/star/uno/genfunc.hxx
+#include com/sun/star/uno/RuntimeException.hpp
+#include uno/data.h
+
+#include bridges/cpp_uno/shared/bridge.hxx
+#include bridges/cpp_uno/shared/types.hxx
+#include bridges/cpp_uno/shared/unointerfaceproxy.hxx
+#include bridges/cpp_uno/shared/vtables.hxx
+
+#include share.hxx
+
+#include callvirtualmethod.hxx
+
+void CPPU_CURRENT_NAMESPACE::callVirtualMethod(
+void * pAdjustedThisPtr,
+sal_Int32 nVtableIndex,
+void * pRegisterReturn,
+typelib_TypeClass eReturnType,
+sal_Int32 * pStackLongs,
+sal_Int32 nStackLongs )
+{
+// parameter list is mixed list of * and values
+// reference parameters are pointers
+
+assert(pStackLongs pAdjustedThisPtr);
+static_assert((sizeof(void *) == 4) (sizeof(sal_Int32) == 4), ###
unexpected size of int!);
+assert(nStackLongs pStackLongs ### no stack in callVirtualMethod
!);
+
+// never called
+if (! pAdjustedThisPtr)
CPPU_CURRENT_NAMESPACE::dummy_can_throw_anything(xxx); // address something
+
+long edx, eax; // for register returns
+void * stackptr;
+asm volatile (
+mov %%esp, %2\n\t
+ // preserve potential 128bit stack alignment
+and $0xfff0, %%esp\n\t
+mov %3, %%eax\n\t
+lea -4(,%%eax,4), %%eax\n\t
+and $0xf, %%eax\n\t
+sub $0xc, %%eax\n\t
+add %%eax, %%esp\n\t
+// copy values
+mov %3, %%eax\n\t
+mov %%eax, %%edx\n\t
+dec %%edx\n\t
+shl $2, %%edx\n\t
+add %4, %%edx\n
+Lcopy:\n\t
+pushl 0(%%edx)\n\t
+sub $4, %%edx\n\t
+dec %%eax\n\t
+jne Lcopy\n\t
+// do the actual call
+mov %5, %%edx\n\t
+mov 0(%%edx), %%edx\n\t
+mov %6, %%eax\n\t
+shl $2, %%eax\n\t
+add %%eax, %%edx\n\t
+mov 0(%%edx), %%edx\n\t
+call *%%edx\n\t
+// save return registers
+ mov %%eax, %0\n\t
+ mov %%edx, %1\n\t
+// cleanup stack
+mov %2, %%esp\n\t
+: =m(eax), =m(edx), =m(stackptr)
+: m(nStackLongs), m(pStackLongs), m(pAdjustedThisPtr),
m(nVtableIndex)
+: eax, ecx, edx );
+switch( eReturnType )
+{
+case typelib_TypeClass_HYPER:
+case typelib_TypeClass_UNSIGNED_HYPER
[Solved]: uno.bin core dump during illumos build - patch included
Hi, as suggested, I patched the solaris_intel sources to support gcc 4.7. Let me know if the attached patch is fine for you to apply. Now I'm going on building, when everything will go through, I will provide you with all the patches we had to apply Gabriele. -- Da: Stephan Bergmann A: libreoffice@lists.freedesktop.org Data: 16 febbraio 2015 14.29.32 CET Oggetto: Re: uno.bin core dump during build On 02/16/2015 02:11 PM, Gabriele Bulfon wrote: looking at the solari_intel sources, uno2cpp.cxx already contains code similar to the patch you pointed: [...] without the need for a new callvirtualmethod.cxx The remaining part of the patches actually just take out an unused call (dummy_can_throw_anything) and add some throw() around. Did you See comment in callvirtualmethod.cxx for details.? How can we track if that solar files are already taking into account gcc 4.7? It doesn't. If you like you can debug into __cxa_throw to see the reason it calls std::terminate. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice sonicle-xstreamos-gcc47-cpp_uno.patch Description: binary/octet-stream ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice-commits] core.git: bridges/Library_cpp_uno.mk bridges/source
bridges/Library_cpp_uno.mk |1
bridges/source/cpp_uno/gcc3_solaris_intel/callvirtualmethod.cxx | 117
++
bridges/source/cpp_uno/gcc3_solaris_intel/callvirtualmethod.hxx | 50
bridges/source/cpp_uno/gcc3_solaris_intel/uno2cpp.cxx | 88 ---
4 files changed, 171 insertions(+), 85 deletions(-)
New commits:
commit 834afd885bd74ff80b59898d3f63ba940a58c1d8
Author: Gabriele Bulfon gabriele.bul...@sonicle.com
Date: Thu Feb 19 14:36:39 2015 +0100
Adapt gcc3_solaris_intel bridge to GCC 4.7
...similarly to 0fdbb5b0eabbaa571f3747fda12a56c938cba474 Make
cpp_uno/gcc3_linux_x86-64 bridge work with GCC 4.7
Change-Id: Idcafcb07678d02446172d7fde30631a342f6437e
diff --git a/bridges/Library_cpp_uno.mk b/bridges/Library_cpp_uno.mk
index 5d9454c..34ecf04 100644
--- a/bridges/Library_cpp_uno.mk
+++ b/bridges/Library_cpp_uno.mk
@@ -74,6 +74,7 @@ bridge_noncallexception_objects := callvirtualmethod
else ifeq ($(OS),SOLARIS)
bridges_SELECTED_BRIDGE := gcc3_solaris_intel
bridge_exception_objects := cpp2uno except uno2cpp
+bridge_noncallexception_objects := callvirtualmethod
else ifeq ($(COM),MSC)
bridges_SELECTED_BRIDGE := msvc_win32_intel
bridge_exception_objects := cpp2uno dllinit uno2cpp
diff --git a/bridges/source/cpp_uno/gcc3_solaris_intel/callvirtualmethod.cxx
b/bridges/source/cpp_uno/gcc3_solaris_intel/callvirtualmethod.cxx
new file mode 100644
index 000..00f9bdc
--- /dev/null
+++ b/bridges/source/cpp_uno/gcc3_solaris_intel/callvirtualmethod.cxx
@@ -0,0 +1,117 @@
+/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
+/*
+ * This file is part of the LibreOffice project.
+ *
+ * This Source Code Form is subject to the terms of the Mozilla Public
+ * License, v. 2.0. If a copy of the MPL was not distributed with this
+ * file, You can obtain one at http://mozilla.org/MPL/2.0/.
+ *
+ * This file incorporates work covered by the following license notice:
+ *
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed
+ * with this work for additional information regarding copyright
+ * ownership. The ASF licenses this file to you under the Apache
+ * License, Version 2.0 (the License); you may not use this file
+ * except in compliance with the License. You may obtain a copy of
+ * the License at http://www.apache.org/licenses/LICENSE-2.0 .
+ */
+
+#include com/sun/star/uno/genfunc.hxx
+#include com/sun/star/uno/RuntimeException.hpp
+#include uno/data.h
+
+#include bridges/cpp_uno/shared/bridge.hxx
+#include bridges/cpp_uno/shared/types.hxx
+#include bridges/cpp_uno/shared/unointerfaceproxy.hxx
+#include bridges/cpp_uno/shared/vtables.hxx
+
+#include share.hxx
+
+#include callvirtualmethod.hxx
+
+void CPPU_CURRENT_NAMESPACE::callVirtualMethod(
+void * pAdjustedThisPtr,
+sal_Int32 nVtableIndex,
+void * pRegisterReturn,
+typelib_TypeClass eReturnType,
+sal_Int32 * pStackLongs,
+sal_Int32 nStackLongs )
+{
+// parameter list is mixed list of * and values
+// reference parameters are pointers
+
+assert(pStackLongs pAdjustedThisPtr);
+static_assert((sizeof(void *) == 4) (sizeof(sal_Int32) == 4), ###
unexpected size of int!);
+assert(nStackLongs pStackLongs ### no stack in callVirtualMethod
!);
+
+// never called
+if (! pAdjustedThisPtr)
CPPU_CURRENT_NAMESPACE::dummy_can_throw_anything(xxx); // address something
+
+long edx, eax; // for register returns
+void * stackptr;
+asm volatile (
+mov %%esp, %2\n\t
+ // preserve potential 128bit stack alignment
+and $0xfff0, %%esp\n\t
+mov %3, %%eax\n\t
+lea -4(,%%eax,4), %%eax\n\t
+and $0xf, %%eax\n\t
+sub $0xc, %%eax\n\t
+add %%eax, %%esp\n\t
+// copy values
+mov %3, %%eax\n\t
+mov %%eax, %%edx\n\t
+dec %%edx\n\t
+shl $2, %%edx\n\t
+add %4, %%edx\n
+Lcopy:\n\t
+pushl 0(%%edx)\n\t
+sub $4, %%edx\n\t
+dec %%eax\n\t
+jne Lcopy\n\t
+// do the actual call
+mov %5, %%edx\n\t
+mov 0(%%edx), %%edx\n\t
+mov %6, %%eax\n\t
+shl $2, %%eax\n\t
+add %%eax, %%edx\n\t
+mov 0(%%edx), %%edx\n\t
+call *%%edx\n\t
+// save return registers
+ mov %%eax, %0\n\t
+ mov %%edx, %1\n\t
+// cleanup stack
+mov %2, %%esp\n\t
+: =m(eax), =m(edx), =m(stackptr)
+: m(nStackLongs), m(pStackLongs), m(pAdjustedThisPtr),
m(nVtableIndex)
+: eax, ecx, edx );
+switch( eReturnType )
+{
+case typelib_TypeClass_HYPER:
+case typelib_TypeClass_UNSIGNED_HYPER:
+((long*)pRegisterReturn)[1] = edx;
+case typelib_TypeClass_LONG:
+case typelib_TypeClass_UNSIGNED_LONG
Re: error during build of mork_helper, on illumos/xstreamos
++.so.6 =/usr/gcc/4.7/lib/libstdc++.so.6 libjvmfwklo.so =/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/program/../ure-link/lib/libjvmfwklo.so libgcc_s.so.1 =/usr/gcc/4.7/lib/libgcc_s.so.1 libsaxlo.so =/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/program/libsaxlo.so libreglo.so =/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/ure/lib/libreglo.so libunoidllo.so =/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/ure/lib/libunoidllo.so liblangtag.so.1 =/usr/lib/liblangtag.so.1 libicui18n.so.51 =/usr/lib/libicui18n.so.51 libmp.so.2 =/lib/libmp.so.2 libmd.so.1 =/lib/libmd.so.1 libXau.so.6 =/usr/lib/libXau.so.6 libXdmcp.so.6 =/usr/lib/libXdmcp.so.6 libffi.so.5 =/usr/lib/libffi.so.5 libxml2.so.2 =/lib/libxml2.so.2 libstorelo.so =/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/ure/lib/libstorelo.so libXevie.so.1 =/usr/lib/libXevie.so.1 libXss.so.1 =/usr/lib/libXss.so.1 mech_krb5.so.1 =/usr/lib/gss/mech_krb5.so.1 libpkcs11.so.1 =/usr/lib/libpkcs11.so.1 libkstat.so.1 =/lib/libkstat.so.1 libcryptoutil.so.1 =/lib/libcryptoutil.so.1 Da: Gabriele Bulfon A: libreoffice@lists.freedesktop.org Data: 19 febbraio 2015 13.04.57 CET Oggetto: error during build of mork_helper, on illumos/xstreamos I have this error now going on the build process: S=/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3 I=$S/instdir W=$S/workdir /usr/gcc/4.7/bin/g++-Wl,-z,origin '-Wl,-rpath,$ORIGIN/../Library' -L$I/ure/lib -L$I/program -L/usr/gcc/4.7/lib -L/lib -L/usr/lib -Wl,-z,combreloc -L$W/LinkTarget/StaticLibrary -L$I/sdk/lib -L$I/ure/lib -L$I/program -L$W/LinkTarget/Library $W/CxxObject/connectivity/source/drivers/mork/mork_helper.o -Wl,--start-group -lm -lnsl -lsocket -lstdc++ -Wl,--end-group -Wl,-zrecord -luno_cppu -luno_cppuhelpergcc3 -lmorklo -luno_sal -o $W/LinkTarget/Executable/mork_helper Undefined first referenced symbol in file X11OpenGLDeviceInfo::isDeviceBlocked() /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/program/libvcllo.so X11OpenGLDeviceInfo::~X11OpenGLDeviceInfo() /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/program/libvcllo.so X11OpenGLDeviceInfo::X11OpenGLDeviceInfo() /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/program/libvcllo.so Looks like some LO code is not built for some reason, leaving out those X11OpenGLDeviceInfo functions? Any help? Gabriele. ___LibreOffice mailing listLibreOffice@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: uno.bin core dump during build
Got it ;) sorry, I didn't get I had to read there :) Working on it, hope to have patches soon for it -- Da: Stephan Bergmann A: libreoffice@lists.freedesktop.org Data: 16 febbraio 2015 14.29.32 CET Oggetto: Re: uno.bin core dump during build On 02/16/2015 02:11 PM, Gabriele Bulfon wrote: looking at the solari_intel sources, uno2cpp.cxx already contains code similar to the patch you pointed: [...] without the need for a new callvirtualmethod.cxx The remaining part of the patches actually just take out an unused call (dummy_can_throw_anything) and add some throw() around. Did you See comment in callvirtualmethod.cxx for details.? How can we track if that solar files are already taking into account gcc 4.7? It doesn't. If you like you can debug into __cxa_throw to see the reason it calls std::terminate. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: uno.bin core dump during build
looking at the solari_intel sources, uno2cpp.cxx already contains code
similar
to the patch you pointed:
using namespace ::com::sun::star::uno;
namespace
{
static void __attribute__((noinline)) callVirtualMethod(
void * pAdjustedThisPtr,
sal_Int32 nVtableIndex,
void * pRegisterReturn,
typelib_TypeClass eReturnType,
sal_Int32 * pStackLongs,
sal_Int32 nStackLongs )
{
and
asm volatile (
mov %%esp, %2\n\t
// preserve potential 128bit stack alignment
and $0xfff0, %%esp\n\t
mov %3, %%eax\n\t
lea -4(,%%eax,4), %%eax\n\t
and $0xf, %%eax\n\t
sub $0xc, %%eax\n\t
...
...
...
without the need for a new callvirtualmethod.cxx
The remaining part of the patches actually just take out an unused call
(dummy_can_throw_anything)
and add some throw() around.
How can we track if that solar files are already taking into account gcc 4.7?
--
Da: Stephan Bergmann
A: libreoffice@lists.freedesktop.org
Data: 16 febbraio 2015 13.38.47 CET
Oggetto: Re: uno.bin core dump during build
On 02/16/2015 11:38 AM, Gabriele Bulfon wrote:
while building on XStreamOS / illumos, looks like uno.bin gets corrupted
then causing a core dump at first build usage.
Most likely bridges/source/cpp_uno/gcc3_solar_intel/ needs the
equivalent of
Make cpp_uno/gcc3_linux_x86-64 bridge work with GCC 4.7.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
uno.bin core dump during build
Hi,
while building on XStreamOS / illumos, looks like uno.bin gets corrupted then
causing a core dump at first build usage.
I checked with ldd that uno.bin and built libs are correctly linking.
the dumping build command:
sonicle@xstreamdev:/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/build/i86/instdir$
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/build/i86/instdir/ure/lib:/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/build/i86/instdir/program
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/build/i86/instdir/ure/bin/uno.bin
-s com.sun.star.test.bridge.BridgeTest --
com.sun.star.test.bridge.CppTestObject
-env:LO_BUILD_LIB_DIR=file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/build/i86/workdir/LinkTarget/Library
-env:URE_MORE_SERVICES=file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/build/i86/workdir/Rdb/uno_services.rdb
-env:URE_MORE_TYPES=file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/build/i86/workdir/UnoApiTarget/bridgetest.rdb
terminate called after throwing an instance of
'com::sun::star::uno::RuntimeException'
Abort (core dumped)
the core stack trace:
core file = core -- program
``/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/ure/bin/uno.bin''
on platform i86pc
SIGABRT: Abort
$C
080461d8 libc.so.1`_lwp_kill+0x15(1, 6, 5aa, fef66000, fef66000, 8046570)
080461f8 libc.so.1`raise+0x2b(6, 0, 8046210, fedd7000, 0, 0)
08046248 libc.so.1`abort+0x10e(809e040, 1, 2, fef67c00, feda7f9b, 809e040)
08046288
libstdc++.so.6.0.17`_ZN9__gnu_cxx27__verbose_terminate_handlerEv+0x17e(80462b0,
fefc3410, 0, 809e010, 0, fe8e2a28)
080462b8 libstdc++.so.6.0.17`_ZN10__cxxabiv111__terminateEPFvvE+0x19(fedabdb4,
474e5543, 80a0a70, 80462e8, feda8862, 809e040)
080462e8 libstdc++.so.6.0.17`__cxa_call_terminate+0x57(809e040, 8046348,
8046350, 804634c, fe41e580, 804632c)
080463a8 libstdc++.so.6.0.17`__gxx_personality_v0+0x49c(1, 6, 432b2b00,
474e5543, 809e040, 8046570)
080464b8 libgcc_s.so.1`_Unwind_RaiseException_Phase2+0x52(8046570, 1, 432b2b00,
474e5543, 809e040, 8046570)
080466c8 libgcc_s.so.1`_Unwind_RaiseException+0x12a(809e040, fefc3410,
fe350bb8, 28, fe31b112, fe8b0970)
080466f8 libstdc++.so.6.0.17`__cxa_throw+0x82(809e060, fe348e40, fe3161d2,
804674c, feeec9fd, 47)
08046728
libtesttools_cppobj.so`_ZN13bridge_object9Test_Impl13getRaiseAttr1Ev+0x46(fe4a63cc,
fe405c57, fedcba98, 804674c, fe405456, 0)
0804676c
libgcc3_uno.so`_ZN12_GLOBAL__N_1L17callVirtualMethodEPvlS0_18_typelib_TypeClassPll+0x64(fe4a63e0,
25, 8046b58, 6, 80467a0, 1)
0804683c
libgcc3_uno.so`_ZN12_GLOBAL__N_1L8cpp_callEPN7bridges7cpp_uno6shared17UnoInterfaceProxyENS2_10VtableSlotEP33_typelib_TypeDescriptionReferencelP24_typelib_MethodParameterPvPSA_PP8_uno_Any+0x46d(8098a18,
0, 25, 808c5b8, 0, 0)
080468ec
libgcc3_uno.so`_ZN7bridges7cpp_uno6shared25unoInterfaceProxyDispatchEP14_uno_InterfacePK24_typelib_TypeDescriptionPvPS7_PP8_uno_Any+0xa1(8098a18,
80934a8, 8046b58, 8046910, 8046938, 808c5b8)
0804699c
libgcc3_uno.so`_ZN12_GLOBAL__N_1L12cpp2uno_callEPN7bridges7cpp_uno6shared17CppInterfaceProxyEPK24_typelib_TypeDescriptionP33_typelib_TypeDescriptionReferencelP24_typelib_MethodParameterPPvPx+0x3d3(808d4d8,
80934a8, 808c5b8, 0, 0, 8046b70)
08046b2c libgcc3_uno.so`_ZN12_GLOBAL__N_1L11cpp_mediateEllPPvPx+0x29e(25, 0,
8046b70, 8046b58, 8046b5c, 8046b70)
08046b6c libgcc3_uno.so`_ZN12_GLOBAL__N_1L15cpp_vtable_callEiiPPv+0x2f(808d4ec,
fe397494, 3fb9, 999a, 3fc9, )
08047448
libtesttools_bridgetest.so`_ZN11bridge_testL11performTestERKN3com3sun4star3uno9ReferenceINS3_17XComponentContextEEERKNS4_IN4test9testtools10bridgetest11XBridgeTestEEEb+0x1901(fe7c5614,
80474b4, 0, fe7c5614, 0, 8084000)
08047528
libtesttools_bridgetest.so`_ZN11bridge_test14TestBridgeImpl3runERKN3com3sun4star3uno8SequenceIN3rtl8OUStringEEE+0x4c5(fe7c55f8,
8047614, 0, 8047608, 0, fe8c3000)
08047708 _ZL8sal_mainv+0xfa0(8, 8047760, 8047738, 8071e90, feffb0a4, fef6fe2c)
08047738 main+0x2c(8, 8047760, 8047784, 8064862, 8071ea0, 0)
08047754 _start+0x83(8, 804785c, 80478c7, 80478ca, 80478ee, 80478f1)
...any idea?
Gabriele
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: core dumped while bulding on illumos XStreamOS
Thanks Michael, I got this, on gdb. Take into account: default python is 2.6, installed also 2.7 and 3.3, config.log shows python3 is taken. (gdb) run Starting program: /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/ure/bin/uno.bin -s com.sun.star.test.bridge.BridgeTest -- com.sun.star.test.bridge.CppTestObject -env:LO_BUILD_LIB_DIR=file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/LinkTarget/Library -env:URE_MORE_SERVICES=file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/Rdb/uno_services.rdb -env:URE_MORE_TYPES=file:///sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/UnoApiTarget/bridgetest.rdb [Thread debugging using libthread_db enabled] [New Thread 1 (LWP 1)] Traceback (most recent call last): File /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/ure/lib/libuno_sal.so.3-gdb.py, line 12, in import importlib ImportError: No module named importlib [New LWP2] Traceback (most recent call last): File /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/instdir/ure/lib/libuno_cppu.so.3-gdb.py, line 12, in import importlib ImportError: No module named importlib terminate called after throwing an instance of 'com::sun::star::uno::RuntimeException' Program received signal SIGABRT, Aborted. [Switching to Thread 1 (LWP 1)] 0xfeef7da5 in _lwp_kill () from /lib/libc.so.1 -- Da: Michael Stahl A: libreoffice@lists.freedesktop.org Data: 16 febbraio 2015 11.52.48 CET Oggetto: Re: core dumped while bulding on illumos XStreamOS On 15.02.2015 00:16, Gabriele Bulfon wrote: This one looks harder.still building on illumos...core dumped?! terminate called after throwing an instance of 'com::sun::star::uno::RuntimeException' make[2]: *** [/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/CustomTarget/testtools/uno_test.done] Abort (core dumped) you need to run the command in a debugger and see where the uno::RuntimeException is thrown; you can use the BUILDTOOLTRACE variable for that. for example the following runs the command from testtools/CustomTarget_uno_test.mk in gdb: make testtools VERBOSE=t PARALLELISM=1 BUILDTOOLTRACE=gdb --args ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
still error on cairotextrenderer.cxx and GlyphCache
I can't seem to get outta here [build CXX] vcl/unx/x11/xlimits.cxx /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/vcl/unx/generic/gdi/cairotextrender.cxx: In member function âbool CairoTextRender::setFont(const FontSelectPattern*, int)â: /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/vcl/unx/generic/gdi/cairotextrender.cxx:65:13: error: incomplete type âGlyphCacheâ used in nested name specifier /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/vcl/unx/generic/gdi/cairotextrender.cxx:79:31: error: incomplete type âGlyphCacheâ used in nested name specifier /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/vcl/unx/generic/gdi/cairotextrender.cxx:83:25: error: invalid use of incomplete type âclass ServerFontâ anyone can help? Still building on XStreamOS Desktop / illumos :) Gabriele ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Solved]: still error on cairotextrenderer.cxx and GlyphCache
Looks like generic/glyphcache.hxx is not included when graphite is disabled on build :) It gets included only by graphite ifdef code on cairotextrenderer.cxx I had to patch this file to include glyphcache before, and it works :) Gabriele. Da: Gabriele Bulfon A: libreoffice@lists.freedesktop.org Data: 14 febbraio 2015 12.16.40 CET Oggetto: still error on cairotextrenderer.cxx and GlyphCache I can't seem to get outta here [build CXX] vcl/unx/x11/xlimits.cxx /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/vcl/unx/generic/gdi/cairotextrender.cxx: In member function âbool CairoTextRender::setFont(const FontSelectPattern*, int)â: /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/vcl/unx/generic/gdi/cairotextrender.cxx:65:13: error: incomplete type âGlyphCacheâ used in nested name specifier /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/vcl/unx/generic/gdi/cairotextrender.cxx:79:31: error: incomplete type âGlyphCacheâ used in nested name specifier /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/vcl/unx/generic/gdi/cairotextrender.cxx:83:25: error: invalid use of incomplete type âclass ServerFontâ anyone can help? Still building on XStreamOS Desktop / illumos :) Gabriele ___LibreOffice mailing listLibreOffice@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
core dumped while bulding on illumos XStreamOS
This one looks harderstill building on illumos...core dumped?! terminate called after throwing an instance of 'com::sun::star::uno::RuntimeException' S=/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3 I=$S/instdir W=$S/workdir mkdir -p $W/CxxObject/vcl/qa/cppunit/app/ $W/Dep/CxxObject/vcl/qa/cppunit/app/ cd /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3 /usr/gcc/4.7/bin/g++ -DCPPU_ENV=gcc3 -DINTEL -DLIBO_INTERNAL_ONLY -DNDEBUG -DOPTIMIZE -DOSL_DEBUG_LEVEL=0 -DSOLARIS -DSUN -DSUN4 -DSYSV -DUNIX -DUNX -D_POSIX_PTHREAD_SEMANTICS -D_PTHREADS -D_REENTRANT -DRTL_USING -I/usr/include/odbc -DCPPUNIT_PLUGIN_EXPORT='extern C SAL_DLLPUBLIC_EXPORT' -DHAVE_GCC_VISIBILITY_FEATURE -fvisibility=hidden -Wall -Wnon-virtual-dtor -Wendif-labels -Wextra -Wundef -Wunused-macros -fmessage-length=0 -fno-common -pipe -fvisibility-inlines-hidden -fPIC -Wshadow -Woverloaded-virtual -std=gnu++11-DEXCEPTIONS_ON -fexceptions -fno-enforce-eh-specs -m32 -c $S/vcl/qa/cppunit/app/test_IconThemeSelector.cxx -o $W/CxxObject/vcl/qa/cppunit/app/test_IconThemeSelector.o -MMD -MT $W/CxxObject/vcl/qa/cppunit/app/test_IconThemeSelector.o -MP -MF $W/Dep/CxxObject/vcl/qa/cppunit/app/test_IconThemeSelector.d_ -I$S/vcl/qa/cppunit/app/ -I$W/UnpackedTarball/boost -I$S/include -I/usr/local/include -I/usr/jdk/jdk1.7.0_45/include -I/usr/jdk/jdk1.7.0_45/include/solaris -I$S/config_host mv $W/Dep/CxxObject/vcl/qa/cppunit/app/test_IconThemeSelector.d_ $W/Dep/CxxObject/vcl/qa/cppunit/app/test_IconThemeSelector.d make[2]: *** [/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.3/workdir/CustomTarget/testtools/uno_test.done] Abort (core dumped) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
patch for alloca on xstreamos/illumos
Hi, going on building, I found a couple of vcl sources using alloca, requiring an include on solaris/illumos. So I had to patch both toolkit/source/awt/vclxgraphics.cxx and toolkit/source/awt/vclxfont.cxx to add this: #ifdef __sun__ #include #endif and now it goes on ;) Gabriele. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
error building cairotextrenderer.cxx on xstreamos/illumos
Hi,
going on building, got these errors on cairotextrenderer.cxx:
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/vcl/unx/generic/gdi/cairotextrender.cxx:
In member function 'bool CairoTextRender::setFont(const FontSelectPattern*,
int)':
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/vcl/unx/generic/gdi/cairotextrender.cxx:65:13:
error: incomplete type 'GlyphCache' used in nested name specifier
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/vcl/unx/generic/gdi/cairotextrender.cxx:79:31:
error: incomplete type 'GlyphCache' used in nested name specifier
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/vcl/unx/generic/gdi/cairotextrender.cxx:83:25:
error: invalid use of incomplete type 'class ServerFont'
In file included from
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/vcl/inc/cairotextrender.hxx:23:0,
from
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/vcl/unx/generic/gdi/cairotextrender.cxx:20:
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/vcl/inc/textrender.hxx:34:7:
error: forward declaration of 'class ServerFont'
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/vcl/unx/generic/gdi/cairotextrender.cxx:85:13:
error: incomplete type 'GlyphCache' used in nested name specifier
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/vcl/unx/generic/gdi/cairotextrender.cxx:96:13:
error: 'ImplServerFontEntry' was not declared in this scope
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/vcl/unx/generic/gdi/cairotextrender.cxx:96:34:
error: 'pSFE' was not declared in this scope
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/vcl/unx/generic/gdi/cairotextrender.cxx:96:53:
error: expected type-specifier before 'ImplServerFontEntry'
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/vcl/unx/generic/gdi/cairotextrender.cxx:96:53:
error: expected '' before 'ImplServerFontEntry'
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/vcl/unx/generic/gdi/cairotextrender.cxx:96:53:
error: expected '(' before 'ImplServerFontEntry'
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/vcl/unx/generic/gdi/cairotextrender.cxx:96:73:
error: expected primary-expression before '' token
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/vcl/unx/generic/gdi/cairotextrender.cxx:96:97:
error: expected ')' before ';' token
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/vcl/unx/generic/gdi/cairotextrender.cxx:
At global scope:
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/vcl/unx/generic/gdi/cairotextrender.cxx:108:6:
error: 'ImplServerFontEntry' has not been declared
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Solved]: error building fastserializer on xstreamos/illumos
Upgraded Boost to 1.55 and build goes on. I also solved the next issue: xmlsec could not configure because of no crypto lib detected. I have a patch to add --with-openssl=/usr on OS=SOLARIS to external/libxmlsec/ExternalProject_xmlsec.mk It's building now...going on.will let you know ;) -- Da: Stephan Bergmann A: libreoffice@lists.freedesktop.org Data: 21 gennaio 2015 11.40.30 CET Oggetto: Re: error building fastserializer on xstreamos/illumos On 01/20/2015 06:26 PM, Gabriele Bulfon wrote: Our boost is 1.49.0, I would rather let it use system one, instead of having another one around. What is the minimum required? LO's configure.ac checks for AX_BOOST_BASE(1.47) and then does some AC_CHECK_HEADER and more specific AC_COMPILE_IFELSE checks, but that's apparently not precise enough to catch the problem you experience. Feel free to improve. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
error building vclxbitmap.cxx on xstreamos/illumos
Hi, next error, right in the middle of an enum declaration...:
[build CXX] toolkit/source/awt/vclxbitmap.cxx
In file included from
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/include/vcl/ctrl.hxx:26:0,
from
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/include/vcl/button.hxx:27,
from
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/vcl/unx/generic/printer/cupsmgr.cxx:37:
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/include/vcl/window.hxx:245:5:
error: expected identifier before '(' token
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/include/vcl/window.hxx:245:5:
error: expected '}' before '(' token
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/include/vcl/window.hxx:245:5:
error: expected unqualified-id before 'unsigned'
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/include/vcl/window.hxx:245:5:
error: expected ')' before 'unsigned'
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/include/vcl/window.hxx:255:1:
error: expected declaration before '}' token
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: error building vclxbitmap.cxx on xstreamos/illumos
yes, I added a patch to add this just before the enum, and it goes on : #ifdef TRANSPARENT # undef TRANSPARENT #endif going on ;) thanks! -- Da: Richard PALO A: Stephan Bergmann libreoffice@lists.freedesktop.org Data: 22 gennaio 2015 18.12.00 CET Oggetto: Re: error building vclxbitmap.cxx on xstreamos/illumos -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 22/01/15 15:20, Stephan Bergmann a écrit : If line 245 of include/vcl/window.hxx reads TRANSPARENT= 12, for you, then most likely you happen to include some definition of a macro named TRANSPARENT. ___ on SunOS: $ grep TRANSPARENT /usr/include/sys/stream.h #define TRANSPARENT (unsigned int)(-1) -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJUwS9dAAoJECAB22fHtp27me4H/j2akRFE9XW1V76jGnNd0RRX f5nQnVtLqd/yruPaoRyADaaD8fzlKfhYA05pQ0n64WoAV+P2wQba7UIbiZGyLHL9 6yzx7thG8v8cNgkVFXssWPJFnKCHKFvvVofPtJiz2RfNN1UicnszQZTAxvkicISP Fw5IJfGfyShof16o6sGIg8v+a/lv7h2lxcUfq0wf7aC0yMIBJ/ilFdBgsCo0EzKM OIdaLyfnDIkZqlunEDHdBDenbXfHC2g7DAaIMN63S80s3RKxEmADnkNe9NenlJS5 2fjFfheUuKjJIghShtaVyRCnKIEZW2iE6JqBUShpcgocCyBcsgjst2JB/ta5NW0= =kETx -END PGP SIGNATURE- ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Solved: 4.4.0.1 build error on libstdc++ on solaris/illumos
Because our default gcc is 4.4.7 on XStreamOS, but I'm building with gcc 4.7, installed as an added option under /usr/gcc/4.7, I had to patch solaris.mk to link there, so here is the patch I'm using. What do you suggest in this case? --- libreoffice-4.4.0.1/solenv/gbuild/platform/solaris.mk Sat Jan 17 10:36:18 2015 +++ libreoffice-4.4.0.1/solenv/gbuild/platform/solaris.mk.new Tue Jan 20 12:33:59 2015 @@ -65,6 +65,7 @@ endif gb_LinkTarget_LDFLAGS += \ + -L$(SYSBASE)/usr/gcc/4.7/lib \ -L$(SYSBASE)/lib \ -L$(SYSBASE)/usr/lib \ -Wl,-z,combreloc \ @@ -83,11 +84,11 @@ endif -ifneq ($(gb_DEBUGLEVEL),0) -gb_LINKEROPTFLAGS := -else -gb_LINKEROPTFLAGS := -Wl,-O1 -endif +#ifneq ($(gb_DEBUGLEVEL),0) +#gb_LINKEROPTFLAGS := +#else +#gb_LINKEROPTFLAGS := -Wl,-O1 +#endif ifeq ($(gb_SYMBOL),$(true)) gb_LINKERSTRIPDEBUGFLAGS := @@ -198,6 +199,7 @@ -lm \ -lnsl \ -lsocket \ + -lstdc++ \ gb_Library_FILENAMES := \ $(foreach lib,$(gb_Library_OOOLIBS),$(lib):$(gb_Library_SYSPRE)$(lib)$(gb_Library_OOOEXT)) \ Da: Gabriele Bulfon A: Richard PALO Norbert Thiebaud Cc: Michael Stahl libreoffice Data: 19 gennaio 2015 13.30.25 CET Oggetto: 4.4.0.1 build error on libstdc++ on solaris/illumos Ok, now build goes on. Tried to figure out this, looks like libstdc++ is not correctly linked: Undefined first referenced symbol in file std::basic_string , std::allocator ::basic_string(std::basic_string , std::allocator ) /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/workdir/CxxObject/l10ntools/source/idxdict/idxdict.o ld: fatal: symbolreferencing errors. No output written to /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/workdir/LinkTarget/Executable/idxdict collect2: error: ld returned 1 exit status -- Da: Richard PALO A: gbul...@sonicle.com Norbert Thiebaud Cc: Michael Stahl libreoffice Data: 18 gennaio 2015 22.56.51 CET Oggetto: Re: 4.4.0.1 build error on sal/types.h on solaris/illumos -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 18/01/15 21:33, Gabriele Bulfon a écrit : Ok, I commented out these on Solaris.mk: #ifneq ($(gb_DEBUGLEVEL),0) #gb_LINKEROPTFLAGS := #else #gb_LINKEROPTFLAGS := -Wl,-O1 #endif will let you know :) -- Da: Norbert Thiebaud A: gbul...@sonicle.com Cc: Michael Stahl libreoffice Richard PALO Data: 18 gennaio 2015 20.15.22 CET Oggetto: Re: 4.4.0.1 build error on sal/types.h on solaris/illumos On Sun, Jan 18, 2015 at 12:18 PM, Gabriele Bulfon wrote: Ok, I checked and it looks fine, so solaris.mk should be taken. Also config.log shows correct variables for OS, CPU and COM. What actually happens is during make, after it has downloaded and extracted various stuff. The last one is translations file. Then it goes on building concat-deps, and linking fails: [build C ] solenv/bin/concat-deps.c [build LNK] Executable/concat-deps ld: fatal: unrecognized option '-O' ld: fatal: unrecognized option '-1' ld: fatal: use the -z help option for usage information collect2: error: ld returned 1 exit status Maybe just concat-deps have problems linking with wrong options on Solaris? Yes it is quite possible... concat-deps is a small utility I wrote to speed up the original perl-based one... and I'm quite sure I never tried to link it on Solaris. Otoh concat-deps is built using the standard gbuild mechanism for that: see solenv/Executable_concat-deps.mk so it is more likely that the problem is generic and that concat-deps just happen to be the first one to be linked. BTW, is there any way to issue gmake and let it show what command LNK is doing? It tried forcing a -n but I did not get the command debugged verbose=t make Norbert Yeah, this should go as not valid for solaris ld. Apparently comes from here: commit 3c4cd1deaf71d0d800957b3580d426c721bf7844 Author: Jonathan Adams Date: Fri Mar 16 21:50:37 2012 +0100 gbuild: switch solaris.mk to GCC -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJUvCwiAAoJECAB22fHtp27MBMH/2IYZRT44q8six0NjeXYkG6B vDe0AJund3FTcN/t9zT0bpFx9mPCCdVxWbqqdv0CFKYQrfSLhPRaksuWrAnK1mOI Nl5vcDxI8D0ls6N1c40ZIAcpI3mOeY1Xye6rpKwYJSjWxqOZHxgWEMMvIrzd9Jxb wnChiTHrDj4ljX1QCPWLxJQB0+e3gXrFmcLvQSEhIPslGPou4i14ur3tf2vVwk0a FZzCoiYfCnUil7vQJHA8vUtbVASMxX4sJ6iYOfD0K/Z+11c4PwF4xZZtZCtG6Rek qLd/Yz/OhqIg2POqJeaDL8S9fYOfrWUgfKuwcFhqBgqDQMknQH8DSeJt6IPAea0= =ZdNh -END PGP SIGNATURE- ___LibreOffice mailing listLibreOffice@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Solved: 4.4.0.1 build error on libstdc++ on solaris/illumos
I thought the same. But maybe g++ thinks it's going to run gnu ld, while it's going to run sun ld. Secondly, I surely had to add /usr/gcc/4.7/lib to the link path, but maybe I can avoid specifying -lstdc++, maybe... I'll try and send you feedback :) -- Da: Michael Stahl A: libreoffice@lists.freedesktop.org Data: 20 gennaio 2015 18.02.27 CET Oggetto: Re: Solved: 4.4.0.1 build error on libstdc++ on solaris/illumos On 20.01.2015 13:38, Gabriele Bulfon wrote: Because our default gcc is 4.4.7 on XStreamOS, but I'm building with gcc 4.7, installed as an added option under /usr/gcc/4.7, I had to patch solaris.mk to link there, so here is the patch I'm using. What do you suggest in this case? i find it a bit odd that you need to link libstdc++ explicitly, shouldn't g++ do that by itself? perhaps there is some mistake in your setup, but i've never built gcc myself so no idea what could go wrong... ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: error building fastserializer on xstreamos/illumos
Our boost is 1.49.0, I would rather let it use system one, instead of having another one around. What is the minimum required? Gabriele. -- Da: Michael Stahl A: libreoffice@lists.freedesktop.org Data: 20 gennaio 2015 18.08.14 CET Oggetto: Re: error building fastserializer on xstreamos/illumos On 20.01.2015 17:49, Gabriele Bulfon wrote: Back here again, going on building :) next error is a Boost error on fastserializer, a lot of errors actually: /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/sax/source/tools/CachedOutputStream.hxx:50:46: error: no matching function for call to 'boost::shared_ptr ::shared_ptr(std::nullptr_t)' probably your system boost is quite old and not C++11 ready... try --without-system-boost ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
error building fastserializer on xstreamos/illumos
Back here again, going on building :) next error is a Boost error on fastserializer, a lot of errors actually: ... [build CXX] sax/source/tools/fastserializer.cxx S=/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2 I=$S/instdir W=$S/workdir mkdir -p $W/CxxObject/sax/source/tools/ $W/Dep/CxxObject/sax/source/tools/ cd /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2 /usr/gcc/4.7/bin/g++ -DCPPU_ENV=gcc3 -DINTEL -DLIBO_INTERNAL_ONLY -DNDEBUG -DOPTIMIZE -DOSL_DEBUG_LEVEL=0 -DSOLARIS -DSUN -DSUN4 -DSYSV -DUNIX -DUNX -D_POSIX_PTHREAD_SEMANTICS -D_PTHREADS -D_REENTRANT -DRTL_USING -DSAX_DLLIMPLEMENTATION -DHAVE_GCC_VISIBILITY_FEATURE -fvisibility=hidden -Wall -Wnon-virtual-dtor -Wendif-labels -Wextra -Wundef -Wunused-macros -fmessage-length=0 -fno-common -pipe -fvisibility-inlines-hidden -fPIC -Wshadow -Woverloaded-virtual -std=gnu++11-DEXCEPTIONS_ON -fexceptions -fno-enforce-eh-specs -m32 -c $S/sax/source/tools/fastserializer.cxx -o $W/CxxObject/sax/source/tools/fastserializer.o -MMD -MT $W/CxxObject/sax/source/tools/fastserializer.o -MP -MF $W/Dep/CxxObject/sax/source/tools/fastserializer.d_ -I$S/sax/source/tools/ -I$S/sax/inc -I$S/include -I/usr/local/include -I/usr/jdk/jdk1.7.0_45/include -I/usr/jdk/jdk1.7.0_45/include/solaris -I$S/config_host -I/usr/include -I$W/UnoApiHeadersTarget/udkapi/normal -I$W/UnoApiHeadersTarget/offapi/normal mv $W/Dep/CxxObject/sax/source/tools/fastserializer.d_ $W/Dep/CxxObject/sax/source/tools/fastserializer.d In file included from /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/sax/source/tools/fastserializer.hxx:28:0, from /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/sax/source/tools/fastserializer.cxx:20: /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/sax/source/tools/CachedOutputStream.hxx: In constructor 'sax_fastparser::CachedOutputStream::CachedOutputStream()': /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/sax/source/tools/CachedOutputStream.hxx:50:46: error: no matching function for call to 'boost::shared_ptr ::shared_ptr(std::nullptr_t)' /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/sax/source/tools/CachedOutputStream.hxx:50:46: note: candidates are: In file included from /usr/include/boost/shared_ptr.hpp:17:0, from /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/include/sax/fshelper.hxx:25, from /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/sax/source/tools/fastserializer.hxx:27, from /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/sax/source/tools/fastserializer.cxx:20: /usr/include/boost/smart_ptr/shared_ptr.hpp:362:5: note: template boost::shared_ptr::shared_ptr(boost::shared_ptr , typename boost::detail::sp_enable_if_convertible ::type) /usr/include/boost/smart_ptr/shared_ptr.hpp:362:5: note: template argument deduction/substitution failed: In file included from /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/sax/source/tools/fastserializer.hxx:28:0, from /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/sax/source/tools/fastserializer.cxx:20: /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/sax/source/tools/CachedOutputStream.hxx:50:46: note: mismatched types 'boost::shared_ptr ' and 'std::nullptr_t' In file included from /usr/include/boost/shared_ptr.hpp:17:0, from /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/include/sax/fshelper.hxx:25, from /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/sax/source/tools/fastserializer.hxx:27, from /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/sax/source/tools/fastserializer.cxx:20: /usr/include/boost/smart_ptr/shared_ptr.hpp:353:5: note: boost::shared_ptr ::shared_ptr(boost::shared_ptr ) [with T = sax_fastparser::ForMergeBase; boost::shared_ptr = boost::shared_ptr ] /usr/include/boost/smart_ptr/shared_ptr.hpp:353:5: note: no known conversion for argument 1 from 'std::nullptr_t' to 'boost::shared_ptr ' /usr/include/boost/smart_ptr/shared_ptr.hpp:295:14: note: template boost::shared_ptr::shared_ptr(Ap, typename boost::detail::sp_enable_if_auto_ptr ::type) /usr/include/boost/smart_ptr/shared_ptr.hpp:295:14: note: template argument deduction/substitution failed: /usr/include/boost/smart_ptr/shared_ptr.hpp: In substitution of 'template boost::shared_ptr::shared_ptr(Ap, typename boost::detail::sp_enable_if_auto_ptr ::type) [with Ap =
Re: error building fastserializer on xstreamos/illumos
Actually I noticed this started to happen after I installed some other package on the system and restarted build. I also noticed that this is a point in build way before I was arrived (xmlsec libs). Is there any reason why fastserializer was not built at all before? -- Da: Michael Stahl A: libreoffice@lists.freedesktop.org Data: 20 gennaio 2015 18.08.14 CET Oggetto: Re: error building fastserializer on xstreamos/illumos On 20.01.2015 17:49, Gabriele Bulfon wrote: Back here again, going on building :) next error is a Boost error on fastserializer, a lot of errors actually: /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/sax/source/tools/CachedOutputStream.hxx:50:46: error: no matching function for call to 'boost::shared_ptr ::shared_ptr(std::nullptr_t)' probably your system boost is quite old and not C++11 ready... try --without-system-boost ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
4.4.0.1 build error on libstdc++ on solaris/illumos
Ok, now build goes on. Tried to figure out this, looks like libstdc++ is not correctly linked: Undefined first referenced symbol in file std::basic_string , std::allocator ::basic_string(std::basic_string , std::allocator ) /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/workdir/CxxObject/l10ntools/source/idxdict/idxdict.o ld: fatal: symbolreferencing errors. No output written to /sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/workdir/LinkTarget/Executable/idxdict collect2: error: ld returned 1 exit status -- Da: Richard PALO A: gbul...@sonicle.com Norbert Thiebaud Cc: Michael Stahl libreoffice Data: 18 gennaio 2015 22.56.51 CET Oggetto: Re: 4.4.0.1 build error on sal/types.h on solaris/illumos -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 18/01/15 21:33, Gabriele Bulfon a écrit : Ok, I commented out these on Solaris.mk: #ifneq ($(gb_DEBUGLEVEL),0) #gb_LINKEROPTFLAGS := #else #gb_LINKEROPTFLAGS := -Wl,-O1 #endif will let you know :) -- Da: Norbert Thiebaud A: gbul...@sonicle.com Cc: Michael Stahl libreoffice Richard PALO Data: 18 gennaio 2015 20.15.22 CET Oggetto: Re: 4.4.0.1 build error on sal/types.h on solaris/illumos On Sun, Jan 18, 2015 at 12:18 PM, Gabriele Bulfon wrote: Ok, I checked and it looks fine, so solaris.mk should be taken. Also config.log shows correct variables for OS, CPU and COM. What actually happens is during make, after it has downloaded and extracted various stuff. The last one is translations file. Then it goes on building concat-deps, and linking fails: [build C ] solenv/bin/concat-deps.c [build LNK] Executable/concat-deps ld: fatal: unrecognized option '-O' ld: fatal: unrecognized option '-1' ld: fatal: use the -z help option for usage information collect2: error: ld returned 1 exit status Maybe just concat-deps have problems linking with wrong options on Solaris? Yes it is quite possible... concat-deps is a small utility I wrote to speed up the original perl-based one... and I'm quite sure I never tried to link it on Solaris. Otoh concat-deps is built using the standard gbuild mechanism for that: see solenv/Executable_concat-deps.mk so it is more likely that the problem is generic and that concat-deps just happen to be the first one to be linked. BTW, is there any way to issue gmake and let it show what command LNK is doing? It tried forcing a -n but I did not get the command debugged verbose=t make Norbert Yeah, this should go as not valid for solaris ld. Apparently comes from here: commit 3c4cd1deaf71d0d800957b3580d426c721bf7844 Author: Jonathan Adams Date: Fri Mar 16 21:50:37 2012 +0100 gbuild: switch solaris.mk to GCC -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJUvCwiAAoJECAB22fHtp27MBMH/2IYZRT44q8six0NjeXYkG6B vDe0AJund3FTcN/t9zT0bpFx9mPCCdVxWbqqdv0CFKYQrfSLhPRaksuWrAnK1mOI Nl5vcDxI8D0ls6N1c40ZIAcpI3mOeY1Xye6rpKwYJSjWxqOZHxgWEMMvIrzd9Jxb wnChiTHrDj4ljX1QCPWLxJQB0+e3gXrFmcLvQSEhIPslGPou4i14ur3tf2vVwk0a FZzCoiYfCnUil7vQJHA8vUtbVASMxX4sJ6iYOfD0K/Z+11c4PwF4xZZtZCtG6Rek qLd/Yz/OhqIg2POqJeaDL8S9fYOfrWUgfKuwcFhqBgqDQMknQH8DSeJt6IPAea0= =ZdNh -END PGP SIGNATURE- ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: 4.4.0.1 build error on sal/types.h on solaris/illumos
Ok, I checked and it looks fine, so solaris.mk should be taken. Also config.log shows correct variables for OS, CPU and COM. What actually happens is during make, after it has downloaded and extracted various stuff. The last one is translations file. Then it goes on building concat-deps, and linking fails: [build C ] solenv/bin/concat-deps.c [build LNK] Executable/concat-deps ld: fatal: unrecognized option '-O' ld: fatal: unrecognized option '-1' ld: fatal: use the -z help option for usage information collect2: error: ld returned 1 exit status Maybe just concat-deps have problems linking with wrong options on Solaris? Also, strange, but build goes on anyway, like: [build YAC] unoidl/source/sourceprovider-parser [build LEX] unoidl/source/sourceprovider-scanner [build CAT] officecfg_qa_allheaders.hxx [build XSL] CustomTarget/officecfg/registry/officecfg/FirstStartWizard.hxx .. .. ...[long list of build stuff, until it reaches here]. [build CMP] scripting/java/ScriptProviderForBeanShell [build CMP] scripting/java/ScriptProviderForJavaScript make[2]: *** No rule to make target `/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/workdir/LinkTarget/Executable/concat-deps', needed by `/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2/workdir/Module/nonl10n/solenv'. Stop. make[2]: *** Waiting for unfinished jobs make[2]: Leaving directory `/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2' make[1]: *** [build] Error 2 make[1]: Leaving directory `/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2' gmake: *** [/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/build/i86/.built] Error 2 Obviously the last error is because we have no concat-deps binary :) I tried to look at the place where it builds concat-deps, but it's not easy to figure it out BTW, is there any way to issue gmake and let it show what command LNK is doing? It tried forcing a -n but I did not get the command debugged Thanks again! Gabriele. -- Da: Norbert Thiebaud A: gbul...@sonicle.com Cc: Michael Stahl libreoffice Richard PALO Data: 17 gennaio 2015 14.56.18 CET Oggetto: Re: 4.4.0.1 build error on sal/types.h on solaris/illumos On Sat, Jan 17, 2015 at 5:07 AM, Gabriele Bulfon wrote: Looks like 4.4.0.2 has this solaris ld patch already applied. I strongly believe gmake is not using the solaris.mk file. How can I verify if configure/make is really taking the solaris.mk platform? In gbuild.mk we include platform/$(OS)_$(CPUNAME)_$(COM).mk verify in your config_host.mk tht these resolve to SOLARIS,INTEL and GCC respectively SOLARIS_INTEL_GCC.mk just include platform/solaris.mk Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: 4.4.0.1 build error on sal/types.h on solaris/illumos
Thanks so much! Here's what I get: [build LNK] Executable/concat-deps gmake[1]: Entering directory `/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2' S=/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.2 I=$S/instdir W=$S/workdir /usr/gcc/4.7/bin/gcc-Wl,-z,origin '-Wl,-rpath,$ORIGIN/../Library' -L$I/ure/lib -L$I/program -L/lib -L/usr/lib -Wl,-z,combreloc -L$W/LinkTarget/StaticLibrary -L$I/sdk/lib -L$I/ure/lib -L$I/program -L$W/LinkTarget/Library -Wl,-O1 $W/CObject/solenv/bin/concat-deps.o -Wl,--start-group -lm -lnsl -lsocket -Wl,--end-group -Wl,-zrecord -o $W/LinkTarget/Executable/concat-deps ld: fatal: unrecognized option '-O' ld: fatal: unrecognized option '-1' ld: fatal: use the -z help option for usage information collect2: error: ld returned 1 exit status looks like -Wl,-O1 is coming in from somewhere... -- Da: Norbert Thiebaud A: gbul...@sonicle.com Cc: Michael Stahl libreoffice Richard PALO Data: 18 gennaio 2015 20.15.22 CET Oggetto: Re: 4.4.0.1 build error on sal/types.h on solaris/illumos On Sun, Jan 18, 2015 at 12:18 PM, Gabriele Bulfon wrote: Ok, I checked and it looks fine, so solaris.mk should be taken. Also config.log shows correct variables for OS, CPU and COM. What actually happens is during make, after it has downloaded and extracted various stuff. The last one is translations file. Then it goes on building concat-deps, and linking fails: [build C ] solenv/bin/concat-deps.c [build LNK] Executable/concat-deps ld: fatal: unrecognized option '-O' ld: fatal: unrecognized option '-1' ld: fatal: use the -z help option for usage information collect2: error: ld returned 1 exit status Maybe just concat-deps have problems linking with wrong options on Solaris? Yes it is quite possible... concat-deps is a small utility I wrote to speed up the original perl-based one... and I'm quite sure I never tried to link it on Solaris. Otoh concat-deps is built using the standard gbuild mechanism for that: see solenv/Executable_concat-deps.mk so it is more likely that the problem is generic and that concat-deps just happen to be the first one to be linked. BTW, is there any way to issue gmake and let it show what command LNK is doing? It tried forcing a -n but I did not get the command debugged verbose=t make Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: 4.4.0.1 build error on sal/types.h on solaris/illumos
Here's something interesting :) grepping on the root of sources: sonicle@xstreamdev$ grep Wl,-O1 * ChangeLog:no local -Wl,-O1 linker flag ChangeLog:no local -Wl,-O1 linker flag ChangeLog:add -Wl,-O1 as linker optimization flags when debug is disabled -- Da: Norbert Thiebaud A: gbul...@sonicle.com Cc: Michael Stahl libreoffice Richard PALO Data: 18 gennaio 2015 20.15.22 CET Oggetto: Re: 4.4.0.1 build error on sal/types.h on solaris/illumos On Sun, Jan 18, 2015 at 12:18 PM, Gabriele Bulfon wrote: Ok, I checked and it looks fine, so solaris.mk should be taken. Also config.log shows correct variables for OS, CPU and COM. What actually happens is during make, after it has downloaded and extracted various stuff. The last one is translations file. Then it goes on building concat-deps, and linking fails: [build C ] solenv/bin/concat-deps.c [build LNK] Executable/concat-deps ld: fatal: unrecognized option '-O' ld: fatal: unrecognized option '-1' ld: fatal: use the -z help option for usage information collect2: error: ld returned 1 exit status Maybe just concat-deps have problems linking with wrong options on Solaris? Yes it is quite possible... concat-deps is a small utility I wrote to speed up the original perl-based one... and I'm quite sure I never tried to link it on Solaris. Otoh concat-deps is built using the standard gbuild mechanism for that: see solenv/Executable_concat-deps.mk so it is more likely that the problem is generic and that concat-deps just happen to be the first one to be linked. BTW, is there any way to issue gmake and let it show what command LNK is doing? It tried forcing a -n but I did not get the command debugged verbose=t make Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: 4.4.0.1 build error on sal/types.h on solaris/illumos
Ok, I commented out these on Solaris.mk: #ifneq ($(gb_DEBUGLEVEL),0) #gb_LINKEROPTFLAGS := #else #gb_LINKEROPTFLAGS := -Wl,-O1 #endif will let you know :) -- Da: Norbert Thiebaud A: gbul...@sonicle.com Cc: Michael Stahl libreoffice Richard PALO Data: 18 gennaio 2015 20.15.22 CET Oggetto: Re: 4.4.0.1 build error on sal/types.h on solaris/illumos On Sun, Jan 18, 2015 at 12:18 PM, Gabriele Bulfon wrote: Ok, I checked and it looks fine, so solaris.mk should be taken. Also config.log shows correct variables for OS, CPU and COM. What actually happens is during make, after it has downloaded and extracted various stuff. The last one is translations file. Then it goes on building concat-deps, and linking fails: [build C ] solenv/bin/concat-deps.c [build LNK] Executable/concat-deps ld: fatal: unrecognized option '-O' ld: fatal: unrecognized option '-1' ld: fatal: use the -z help option for usage information collect2: error: ld returned 1 exit status Maybe just concat-deps have problems linking with wrong options on Solaris? Yes it is quite possible... concat-deps is a small utility I wrote to speed up the original perl-based one... and I'm quite sure I never tried to link it on Solaris. Otoh concat-deps is built using the standard gbuild mechanism for that: see solenv/Executable_concat-deps.mk so it is more likely that the problem is generic and that concat-deps just happen to be the first one to be linked. BTW, is there any way to issue gmake and let it show what command LNK is doing? It tried forcing a -n but I did not get the command debugged verbose=t make Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: 4.4.0.1 build error on sal/types.h on solaris/illumos
Great one! On 4.1.x release I could build it via LD_ALTEXEC using gnu ld. It's really much better if I can make it build with native illumos ld! Thanks! Will let you know ;) Gabriele. -- Da: Michael Stahl A: gbul...@sonicle.com libreoffice@lists.freedesktop.org Richard PALO Data: 16 gennaio 2015 20.50.59 CET Oggetto: Re: 4.4.0.1 build error on sal/types.h on solaris/illumos On 16.01.2015 19:43, Gabriele Bulfon wrote: Looks like now it takes SunOS linker, but options are wrong. Tried setting LD=/usr/gnu/bin/ld, and also using LD_ALTEXEC but no way... How can I force it to use gnu ld? we merged a couple of Solaris patches by Richard Palo, including this one: commit 573506c778410fc0eb6afc0c07bdd849613503a8 Author: Richard PALO AuthorDate: Mon Nov 10 17:36:30 2014 +0100 in general, SOLARIS should use /usr/bin/ld. Make equivalent to unxgcc.mk (with gld). NB: use $(READELF) updated in configure.ac and config_host.mk.in perhaps you two could try to agree on which is the right linker to use :) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: 4.4.0.1 build error on sal/types.h on solaris/illumos
Thanks to you all guys for helping us :) I will ty to complete this build and will then look how to setup a tinderbox, surely. Thanks! Gabriele. -- Da: Jan Holesovsky A: gbul...@sonicle.com Cc: libreoffice-dev Data: 16 gennaio 2015 20.00.52 CET Oggetto: Re: 4.4.0.1 build error on sal/types.h on solaris/illumos Hi Gabriele, Gabriele Bulfon pí?e v ?t 15. 01. 2015 v 15:05 +0100: we already succeded more than a year ago, in building libreoffice 4.1.0.4 on our illumos based XStreamOS Desktop, creating a lot of patches to support our platform. We're now in the process of upgrading to 4.4.0.1 from sources. We decided to start from scratch, with no patch at all, and port patches during build until we succeed. This, because we found a lot of ifdefs and macros about Soalris and SunOS in general, se we maybe don't need all our previous patches anymore. This is awesome! Thanks so much for that :-) When you have it building - could you please setup a tinderbox for solaris/illumnos, so that you don't have to undertake this painful porting / building again? https://wiki.documentfoundation.org/Development/Tinderbox [see especially the For Tinderbox owners part]. With the tinderbox in place, you can be sure that the master will stay buildable on your platform. Also would be great if you can up-stream your changes on the way, hopefully it is easy enough using gerrit? https://wiki.documentfoundation.org/Development/gerrit All the best, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: 4.4.0.1 build error on sal/types.h on solaris/illumos
Looks like 4.4.0.2 has this solaris ld patch already applied. I strongly believe gmake is not using the solaris.mk file. How can I verify if configure/make is really taking the solaris.mk platform? -- Da: Michael Stahl A: gbul...@sonicle.com libreoffice@lists.freedesktop.org Richard PALO Data: 16 gennaio 2015 20.50.59 CET Oggetto: Re: 4.4.0.1 build error on sal/types.h on solaris/illumos On 16.01.2015 19:43, Gabriele Bulfon wrote: Looks like now it takes SunOS linker, but options are wrong. Tried setting LD=/usr/gnu/bin/ld, and also using LD_ALTEXEC but no way... How can I force it to use gnu ld? we merged a couple of Solaris patches by Richard Palo, including this one: commit 573506c778410fc0eb6afc0c07bdd849613503a8 Author: Richard PALO AuthorDate: Mon Nov 10 17:36:30 2014 +0100 in general, SOLARIS should use /usr/bin/ld. Make equivalent to unxgcc.mk (with gld). NB: use $(READELF) updated in configure.ac and config_host.mk.in perhaps you two could try to agree on which is the right linker to use :) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
4.4.0.1 build error on sal/types.h on solaris/illumos
Hi,
we already succeded more than a year ago, in building libreoffice 4.1.0.4 on
our illumos based XStreamOS Desktop,
creating a lot of patches to support our platform.
We're now in the process of upgrading to 4.4.0.1 from sources.
We decided to start from scratch, with no patch at all, and port patches during
build until we succeed.
This, because we found a lot of ifdefs and macros about Soalris and SunOS
in general, se we maybe don't need
all our previous patches anymore.
We forced parallelism to 1, so to have a clear view of the build process and
errors.
We stumbled upon this, wich look very tricky...:
[build CXX] sal/osl/all/compat.cxx
In file included from
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.1/include/rtl/textenc.h:29:0,
from
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.1/include/rtl/tencinfo.h:25,
from
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.1/include/osl/module.h:25,
from
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.1/sal/osl/all/compat.cxx:14:
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.1/include/sal/types.h:375:27:
error: expected identifier before numeric constant
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.1/include/sal/types.h:375:27:
error: expected unqualified-id before numeric constant
/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.1/sal/osl/all/compat.cxx:138:1:
error: expected ?}? at end of input
gmake[1]: ***
[/sources/sonicle/xstream-desktop-gate/components/libreoffice/libreoffice/libreoffice-4.4.0.1/workdir/CxxObject/sal/osl/all/compat.o]
Error 1
gmake: *** [build] Error 2
Looks like the gcc parser gets confused by something in the sal/types.h, giving
error on this line:
namespace com { namespace sun { namespace star { } } }
This line was there also in 4.1.x, but diff shows many changes on the types.h
file, before the namespace line.
Can't find a reason for this.
Anyone can help?
Thanks!
Gabriele.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
built from sources, mail merge not working
Hi, our own build of LO 4.1.0.4 on XStreamOS/illumos, has problems with mailmerge. Testing the account on the options pane, says: LibreOffice could not connect to the outgoing mail server. Check your system's settings and the settings in LibreOffice. Check the server name, the port and the secure connections settings -- unsatisfied query for interface of type com.sun.star.loader.XImplementationLoader Is there anything I should enable during config to allow for mailmerge to work? Here is my configure: ./configure --prefix=/usr --mandir=/usr/share/man --bindir=/usr/bin --libdir=/usr/lib --sbindir=/usr/sbin --infodir=/usr/share/info --sysconfdir=/etc --build=i386-pc-solaris2.11 --with-parallelism=8 --enable-gtk3 --disable-python --with-system-libs --with-system-altlinuxhyph=no --with-system-lpsolve=no --with-jdk-home=/usr/jdk/jdk1.7.0_45 --with-x --enable-gstreamer --disable-gstreamer-0-10 --with-build-version=Sonicle XStreamOS-153 --with-vendor=Sonicle S.r.l. --with-lang=en-US en-GB de fr it es ru ja nl zh-CN zh-TW --srcdir=/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice/libreoffice-4.1.0.4 --enable-option-checking=fatal Thanks for any help, Gabriele. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
XStream Desktop beta EA1 - featuring LibreOffice
Hi, anyone interested can download the first early access release of XStream Desktop, featuring a fresh build of LibreOffice on an illumos based kernel. Please read the instructions for virtualized environements (vbox an vmware): http://www.sonicle.com/index.jsp?pagename=xstreamos-desktopparent;productslanguage=en We will be very pleased to receive any feedback, comments and/or requests you may provide, by registering and using the mailing list stated at the end of the page. We've been already told that the SF mailman is not exactly a good place. We will be setting up our own installation of GNU mailman and notify about the change. Feel free to suggest a different solution for this. Next step, other than fixing and adding features, will be to publish the sources repository. Hope you enjoy it! Gabriele. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Error building sc on XStreamOS/illumos
Later on build, error for missing file losessioninstall.component.
I had to patch Module_shell by duplicating Linux part for Solaris.
Is this correct?
--- libreoffice-4.1.0.1/shell/Module_shell.mk Fri Jul 19 08:27:41 2013
+++ libreoffice-4.1.0.1/shell/Module_shell.mk Fri Jul 19 08:27:28 2013
@@ -22,6 +22,14 @@
endif
endif
+ifeq ($(OS),SOLARIS)
+ifeq ($(ENABLE_GIO),TRUE)
+$(eval $(call gb_Module_add_targets,shell,\
+ Library_losessioninstall \
+))
+endif
+endif
+
ifeq ($(ENABLE_GCONF),TRUE)
$(eval $(call gb_Module_add_targets,shell,\
Library_gconfbe \
Da:
Gabriele Bulfon
A:
Kohei Yoshida
Cc:
libreoffice-dev
Data:
18 luglio 2013 16.23.49 CEST
Oggetto:
Re: Error building sc on XStreamOS/illumos
Great! Worked, and I had also to patch this:
--- libreoffice-4.1.0.1/sc/source/core/tool/scmatrix.cxxThu Jul 18
16:19:54 2013
+++ libreoffice-4.1.0.1/sc/source/core/tool/scmatrix.cxxThu Jul 18
16:19:47 2013
@@ -89,7 +89,7 @@
}
}
-static void delete_block(mdds::mtv::base_element_block* p)
+static void delete_block(const mdds::mtv::base_element_block* p)
{
if (!p)
return;
--
Da: Kohei Yoshida
A: Gabriele Bulfon
Cc: libreoffice-dev
Data: 18 luglio 2013 14.11.02 CEST
Oggetto: Re: Error building sc on XStreamOS/illumos
On 07/18/2013 03:12 AM, Gabriele Bulfon wrote:
Hi,
building went on after setup_native, and I got an error while building sc:
In file included from
/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/sc/inc/column.hxx:28,
from
/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/sc/inc/table.hxx:28,
from
/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/sc/source/core/data/bcaslot.cxx:30:
/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/sc/inc/mtvelements.hxx:66:
error: wrong number of template arguments (2, should be 1)
/usr/include/mdds/multi_type_vector_custom_func1.hpp:40: error:
provided for 'template
struct mdds::mtv::custom_block_func1'
/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/sc/inc/mtvelements.hxx:66:
error: invalid type in declaration before ';' token
/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/sc/inc/mtvelements.hxx:70:
error: wrong number of template arguments (2, should be 1)
/usr/include/mdds/multi_type_vector_custom_func1.hpp:40: error:
provided for 'template
struct mdds::mtv::custom_block_func1'
what's wrong?
You are probably using mdds 0.9.0 to build the 4.1 branch. You need to
either downgrade it to 0.8.1 (which you can easily by specifying
--without-system-mdds), or patch mtvelements.hxx to get it to build with
mdds 0.9.0. Patching should be easy; all you have to do is to remove
the block type ID's from the template arguments i.e. making the
following change
diff --git a/sc/inc/mtvelements.hxx b/sc/inc/mtvelements.hxx
index 1628381..037ec6b 100644
--- a/sc/inc/mtvelements.hxx
+++ b/sc/inc/mtvelements.hxx
@@ -63,11 +63,11 @@ MDDS_MTV_DEFINE_ELEMENT_CALLBACKS_PTR(SvtBroadcaster,
sc::element_type_broadcast
namespace sc {
// Broadcaster storage container
-typedef mdds::mtv::custom_block_func1
BCBlkFunc;
+typedef mdds::mtv::custom_block_func1
BCBlkFunc;
typedef mdds::multi_type_vector
BroadcasterStoreType;
// Cell text attribute container.
-typedef mdds::mtv::custom_block_func1
CTAttrFunc;
+typedef mdds::mtv::custom_block_func1
CTAttrFunc;
typedef mdds::multi_type_vector
CellTextAttrStoreType;
/**
should make the 4.1 branch build with 0.9.0.
HTH,
Kohei
--
Kohei Yoshida, LibreOffice Calc hacker, SUSE.
___LibreOffice mailing
listLibreOffice@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
CppunitTest_basic_scanner failing
Hi,
going on building on XStream/illumos, gbuild runs a unit test and fails:
[build CUT] basic_scanner
DynamicLibraryManagerException: Failed to load dynamic library:
/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/workdir/unxsogi.pro/LinkTarget/CppunitTest/libtest_basic_scanner.so
Error: a unit test failed, please do one of:
export DEBUGCPPUNIT=TRUE# for exception catching
export GDBCPPUNITTRACE=gdb --args # for interactive debugging
export VALGRIND=memcheck# for memory checking
and retry using: make CppunitTest_basic_scanner
So I went into the basic folder, and ran the first suggested option:
sonicle@vbxstreamdev:/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/basic$
export DEBUGCPPUNIT=TRUE
sonicle@vbxstreamdev:/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/basic$
gmake CppunitTest_basic_scanner LD_ALTEXEC=/usr/gnu/bin/ld
[build CUT] basic_scanner
S=/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1
O=$S/solver/unxsogi.pro W=$S/workdir/unxsogi.pro mkdir -p
$W/CppunitTest/rm -fr $W/CppunitTest/basic_scanner.test.core mkdir
$W/CppunitTest/basic_scanner.test.core cd
$W/CppunitTest/basic_scanner.test.core
(LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}$O/lib:$S/instdir/unxsogi.pro/program:$O/lib/sqlite
DBGSV_ERROR_OUT=shell DISABLE_SAL_DBGBOX=t gdb -nx -ex
add-auto-load-safe-path $O/lib
--command=$S/solenv/bin/gdbtrycatchtrace-stdout -return-child-result --args
$O/bin/cppunit/cppunittester $W/LinkTarget/CppunitTest/libtest_basic_scanner.so
--headless
-env:BRAND_BASE_DIR=file://$O/unittest/install$W/CppunitTest/basic_scanner.test.log
21;|| (RET=$? cat $W/CppunitTest/basic_scanner.test.log printf '\nError:
a unit test failed, please do one of:\n\nexport DEBUGCPPUNIT=TRUE#
for exception catching\nexport GDBCPPUNITTRACE=gdb --args # for interactive
debugging\nexport VALGRIND=memcheck# for memory checking\n\nand
retry using: make %sTest_%s\n\n' Cppunit basic_scanner
$S/solenv/bin/gdb-core-bt.sh $O/bin/cppunit/cppunittester
$W/CppunitTest/basic_scanner.test.core $RET false))
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-pc-solaris2.11.
For bug reporting instructions, please see:
...
Reading symbols from
/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/bin/cppunit/cppunittester...(no
debugging symbols found)...done.
Undefined command: add-auto-load-safe-path. Try help.
Catchpoint 1 (throw)
Catchpoint 2 (catch)
Traceback (most recent call last):
File
/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libuno_sal.so.3-gdb.py,
line 12, in
import importlib
ImportError: No module named importlib
[Thread debugging using libthread_db enabled]
[New Thread 1 (LWP 1)]
[New LWP2]
[Switching to Thread 1 (LWP 1)]
Catchpoint 1 (exception thrown), __cxxabiv1::__cxa_throw (obj=0x80511f0,
tinfo=0xfef32bb4, dest=0xfeedfa20
) at
/sources/userlands/xstream-userland-gate/components/gcc44/gcc-4.4.7/libstdc++-v3/libsupc++/eh_throw.cc:66
66 = __get_refcounted_exception_header_from_obj (obj);
#0 __cxxabiv1::__cxa_throw (obj=0x80511f0, tinfo=0xfef32bb4, dest=0xfeedfa20
) at
/sources/userlands/xstream-userland-gate/components/gcc44/gcc-4.4.7/libstdc++-v3/libsupc++/eh_throw.cc:66
#1 0xfeedf9c6 in CppUnit::DynamicLibraryManager::loadLibrary(std::basic_string
, std::allocator
const () from /usr/lib/libcppunit-1.12.so.1
#2 0xfeedf715 in
CppUnit::DynamicLibraryManager::DynamicLibraryManager(std::basic_string
, std::allocator
const () from /usr/lib/libcppunit-1.12.so.1
#3 0xfeee56e7 in CppUnit::PlugInManager::load(std::basic_string
, std::allocator
const CppUnit::PlugInParameters const () from /usr/lib/libcppunit-1.12.so.1
#4 0x0804a5f6 in (anonymous namespace)::ProtectedFixtureFunctor::run() const ()
#5 0x0804afd7 in sal_main() ()
#6 0x0804aaaf in main ()
Catchpoint 2 (exception caught), __cxxabiv1::__cxa_begin_catch
(exc_obj_in=0x80511d0) at
/sources/userlands/xstream-userland-gate/components/gcc44/gcc-4.4.7/libstdc++-v3/libsupc++/eh_catch.cc:43
43 = reinterpret_cast
(exc_obj_in);
#0 __cxxabiv1::__cxa_begin_catch (exc_obj_in=0x80511d0) at
/sources/userlands/xstream-userland-gate/components/gcc44/gcc-4.4.7/libstdc++-v3/libsupc++/eh_catch.cc:43
#1 0x0804a646 in (anonymous namespace)::ProtectedFixtureFunctor::run() const ()
#2 0x0804afd7 in sal_main() ()
#3 0x0804aaaf in main ()
DynamicLibraryManagerException: Failed to load dynamic library:
LibreOffice Works on XStream/illumos! - questions about packaging
Hi, I'm excited to announce that I finished building and installing LO inside a prototype area, and it works great directly from there. The prototype area is somthing like prototype/usr/lib/libreoffice/. Now I have to publish it into my dev IPS repository, and decide how to make the layout. What is the usual layout? Should I just place everything in /usr/lib/libreoffice as in prototype, or also provide links in /usr/bin to run common executables? (soffice,swriter and so on). Suggestions would be great! Thanx for all your help, we're excited to have LO inside our upcoming Sonicle XStreamOS Desktop distro! Gabriele. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Error building sc on XStreamOS/illumos
Hi, building went on after setup_native, and I got an error while building sc: In file included from /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/sc/inc/column.hxx:28, from /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/sc/inc/table.hxx:28, from /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/sc/source/core/data/bcaslot.cxx:30: /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/sc/inc/mtvelements.hxx:66: error: wrong number of template arguments (2, should be 1) /usr/include/mdds/multi_type_vector_custom_func1.hpp:40: error: provided for 'template struct mdds::mtv::custom_block_func1' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/sc/inc/mtvelements.hxx:66: error: invalid type in declaration before ';' token /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/sc/inc/mtvelements.hxx:70: error: wrong number of template arguments (2, should be 1) /usr/include/mdds/multi_type_vector_custom_func1.hpp:40: error: provided for 'template struct mdds::mtv::custom_block_func1' what's wrong? Gabriele. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Error building sc on XStreamOS/illumos
Great! Worked, and I had also to patch this:
--- libreoffice-4.1.0.1/sc/source/core/tool/scmatrix.cxxThu Jul 18
16:19:54 2013
+++ libreoffice-4.1.0.1/sc/source/core/tool/scmatrix.cxxThu Jul 18
16:19:47 2013
@@ -89,7 +89,7 @@
}
}
-static void delete_block(mdds::mtv::base_element_block* p)
+static void delete_block(const mdds::mtv::base_element_block* p)
{
if (!p)
return;
--
Da: Kohei Yoshida
A: Gabriele Bulfon
Cc: libreoffice-dev
Data: 18 luglio 2013 14.11.02 CEST
Oggetto: Re: Error building sc on XStreamOS/illumos
On 07/18/2013 03:12 AM, Gabriele Bulfon wrote:
Hi,
building went on after setup_native, and I got an error while building sc:
In file included from
/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/sc/inc/column.hxx:28,
from
/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/sc/inc/table.hxx:28,
from
/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/sc/source/core/data/bcaslot.cxx:30:
/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/sc/inc/mtvelements.hxx:66:
error: wrong number of template arguments (2, should be 1)
/usr/include/mdds/multi_type_vector_custom_func1.hpp:40: error:
provided for 'template
struct mdds::mtv::custom_block_func1'
/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/sc/inc/mtvelements.hxx:66:
error: invalid type in declaration before ';' token
/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/sc/inc/mtvelements.hxx:70:
error: wrong number of template arguments (2, should be 1)
/usr/include/mdds/multi_type_vector_custom_func1.hpp:40: error:
provided for 'template
struct mdds::mtv::custom_block_func1'
what's wrong?
You are probably using mdds 0.9.0 to build the 4.1 branch. You need to
either downgrade it to 0.8.1 (which you can easily by specifying
--without-system-mdds), or patch mtvelements.hxx to get it to build with
mdds 0.9.0. Patching should be easy; all you have to do is to remove
the block type ID's from the template arguments i.e. making the
following change
diff --git a/sc/inc/mtvelements.hxx b/sc/inc/mtvelements.hxx
index 1628381..037ec6b 100644
--- a/sc/inc/mtvelements.hxx
+++ b/sc/inc/mtvelements.hxx
@@ -63,11 +63,11 @@ MDDS_MTV_DEFINE_ELEMENT_CALLBACKS_PTR(SvtBroadcaster,
sc::element_type_broadcast
namespace sc {
// Broadcaster storage container
-typedef mdds::mtv::custom_block_func1
BCBlkFunc;
+typedef mdds::mtv::custom_block_func1
BCBlkFunc;
typedef mdds::multi_type_vector
BroadcasterStoreType;
// Cell text attribute container.
-typedef mdds::mtv::custom_block_func1
CTAttrFunc;
+typedef mdds::mtv::custom_block_func1
CTAttrFunc;
typedef mdds::multi_type_vector
CellTextAttrStoreType;
/**
should make the 4.1 branch build with 0.9.0.
HTH,
Kohei
--
Kohei Yoshida, LibreOffice Calc hacker, SUSE.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
Now I noticed the config.log of xmlsec shows the configure switches like this: ./configure --with-pic --disable-shared --disable-crypto-dl --without-libxslt --without-gnutls --without-openssl This is why it's not picking up my system openssl not the other crypto libs. I bet it's trying to build it only with NSS libs, but they're not passed correctly (they resides in /usr/lib/mps in my environment) from base env. Is it absolutely necessary that it builds without those crypto libs? Gabriele. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
libxmlsec patch for building on illumos/solaris
Hi, I managed to patch libxmlsec mk files to work on XStreamOS/illumos. I had to disable nss/nspr and use installed openssl instead, as for android. Here is the patch that built correctly. Gabriele. sonicle-libxmlsec-illumos.patch Description: binary/octet-stream ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
For now, it's ok to have the build go through, so I can see if I can reach a working LO. Then I'll dig again the NSS problem, and see if I can support it. Now: build reached the install creation phase! But: something went wrong. USAGE: /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/setup_native/scripts/install_create.pl : the start shell script, located next to this perl script : the library file, that is included into the shell script : the target shellscript chmod: cannot access '/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/workdir/unxsogi.pro/CustomTarget/setup_native/scripts/install': No such file or directory make[2]: *** [/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/workdir/unxsogi.pro/CustomTarget/setup_native/scripts/install] Error 1 As if the install creation did not pass arguments to the perl script. Actually, I don't want it to create an installer for solaris via packages. What I want is to issue some kind of gmake install to let it place everything inside a prototype area, through classic configure switches. This will let me publish the package in my IPS repository, as for any SunOS 5.11 based system. Any idea how to achieve this? Gabriele. -- Da: Michael Stahl A: Gabriele Bulfon Cc: libreoffice-dev michael.me...@suse.com Rene Engelhard Data: 16 luglio 2013 10.43.01 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS On 16/07/13 08:09, Gabriele Bulfon wrote: Now I noticed the config.log of xmlsec shows the configure switches like this: ./configure --with-pic --disable-shared --disable-crypto-dl --without-libxslt --without-gnutls --without-openssl This is why it's not picking up my system openssl not the other crypto libs. I bet it's trying to build it only with NSS libs, but they're not passed correctly (they resides in /usr/lib/mps in my environment) from base env. Is it absolutely necessary that it builds without those crypto libs? i'm not entirely sure but i think that the ODF encryption support (which is the only use of libxmlsec) on Unixes is implemented by using keys added by Firefox/Thunderbird UI to their user profiles; there is no UI in LO for adding/removing keys. probably only NSS can read the Firefox/Thunderbird key database, so i'm afraid that if you build xmlsec with anything other than NSS it won't work in practice. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
setup_native patch for illumos/solaris
Here is a patch for the SOLARIS parts in CustomTarget_scripts.mk, probably an old way to run install_create.pl, not updated for Solaris. Gabriele. sonicle-setup_native-illumos.patch Description: binary/octet-stream ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
sysui CustomTarget_solaris.mk not working
During install create phase, the sysui CustomaTarget_solaris.mk rule to create the desktop integration tar.gz is never invoked: $(solaris_WORKDIR)/%-desktop-integration.tar.gz: .. So build fails when trying to cp this file later. I tried to debug the problem but I still cannot figure out why that rule is never invoked. Also, I cannot understand why the Module_sysui.mk always runs slackware even when not building for slackware: $(eval $(call gb_Module_add_targets,sysui,\ CustomTarget_share \ CustomTarget_slackware \ Package_share \ Package_desktop \ $(if $(filter rpm,$(PKGFORMAT)),CustomTarget_rpm) \ $(if $(filter deb,$(PKGFORMAT)),CustomTarget_deb) \ $(if $(filter SOLARIS,$(OS)),CustomTarget_solaris) \ )) other targets are considered, while slackware is always built. thanks for any help! Gabriele. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [solved] sysui CustomTarget_solaris.mk not working
I found the reason: the solaris taget mk has errors, and a misterious bug. 1. $(solaris_WORKDIR)/%/mailcap: $(solaris_SRCDIR)/prototype there's an error here, mailcap should be prototype, the mailcap target is already defined before correctly. 2. $(solaris_WORKDIR)/%-desktop-integration.tar.gz: $(solaris_WORKDIR)/copyright $(solaris_WORKDIR)/pkginfo $(solaris_WORKDIR)/depend $(solaris_WORKDIR)/mailcap $(solaris_WORKDIR)/postinstall $(solaris_WORKDIR)/postremove $(solaris_WORKDIR)/prototype $(call gb_CustomTarget_get_workdir,sysui/share)/%/openoffice.org.xml the code under this rule is never executed, probably because of the previous mispelling, but also because probably the openoffice.org.xml does not exists. I tried removing the dependencies one by one, but misteriously the dependencies were executed, but the tar.gz code was never executed after. By doing gmake --debug=v, I could see that gmake was taking into consideration the target of the tar.gz, but at the end it was only saying target done, without executing its code. The only way I could force execution of the code to build the tar.gz, was to take away all the dependencies, like this: $(solaris_WORKDIR)/%-desktop-integration.tar.gz: pkgmk -l 1073741824 -r $(solaris_WORKDIR) -f $(solaris_WORKDIR)/$*/prototype -o -d $(solaris_WORKDIR) ARCH=all VERSION=$(PKGVERSION.$*) $(GNUTAR) -cf - -C $(solaris_WORKDIR) $*$(LIBO_MAJOR) -desktop-int | gzip$@ Also, pkgmk fails, something is missing, so I just commented it because I don't need old style packages. If you need the patch files, I have them. Gabriele. Da: Gabriele Bulfon A: libreoffice-dev Data: 16 luglio 2013 13.30.26 CEST Oggetto: sysui CustomTarget_solaris.mk not working During install create phase, the sysui CustomaTarget_solaris.mk rule to create the desktop integration tar.gz is never invoked: $(solaris_WORKDIR)/%-desktop-integration.tar.gz: .. So build fails when trying to cp this file later. I tried to debug the problem but I still cannot figure out why that rule is never invoked. Also, I cannot understand why the Module_sysui.mk always runs slackware even when not building for slackware: $(eval $(call gb_Module_add_targets,sysui,\ CustomTarget_share \ CustomTarget_slackware \ Package_share \ Package_desktop \ $(if $(filter rpm,$(PKGFORMAT)),CustomTarget_rpm) \ $(if $(filter deb,$(PKGFORMAT)),CustomTarget_deb) \ $(if $(filter SOLARIS,$(OS)),CustomTarget_solaris) \ )) other targets are considered, while slackware is always built. thanks for any help! Gabriele. ___LibreOffice mailing listLibreOffice@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [solved] sysui CustomTarget_solaris.mk not working
Forgot: I also had to patch Module_sysui.mk Pushed Package_share and Package_desktop at the end of the list, and created an if clause for slackware: $(eval $(call gb_Module_add_targets,sysui,\ CustomTarget_share \ $(if $(filter SLACKWARE,$(OS)),CustomTarget_slackware) \ $(if $(filter rpm,$(PKGFORMAT)),CustomTarget_rpm) \ $(if $(filter deb,$(PKGFORMAT)),CustomTarget_deb) \ $(if $(filter SOLARIS,$(OS)),CustomTarget_solaris) \ Package_share \ Package_desktop \ )) This to: - let share and desktop be built after target solaris, or the tar.gz would be missing - don't build slackware stuff if not needed Gabriele. Da: Gabriele Bulfon A: libreoffice-dev Data: 16 luglio 2013 17.47.31 CEST Oggetto: Re: [solved] sysui CustomTarget_solaris.mk not working I found the reason: the solaris taget mk has errors, and a misterious bug. 1. $(solaris_WORKDIR)/%/mailcap: $(solaris_SRCDIR)/prototype there's an error here, mailcap should be prototype, the mailcap target is already defined before correctly. 2. $(solaris_WORKDIR)/%-desktop-integration.tar.gz: $(solaris_WORKDIR)/copyright $(solaris_WORKDIR)/pkginfo $(solaris_WORKDIR)/depend $(solaris_WORKDIR)/mailcap $(solaris_WORKDIR)/postinstall $(solaris_WORKDIR)/postremove $(solaris_WORKDIR)/prototype $(call gb_CustomTarget_get_workdir,sysui/share)/%/openoffice.org.xml the code under this rule is never executed, probably because of the previous mispelling, but also because probably the openoffice.org.xml does not exists. I tried removing the dependencies one by one, but misteriously the dependencies were executed, but the tar.gz code was never executed after. By doing gmake --debug=v, I could see that gmake was taking into consideration the target of the tar.gz, but at the end it was only saying target done, without executing its code. The only way I could force execution of the code to build the tar.gz, was to take away all the dependencies, like this: $(solaris_WORKDIR)/%-desktop-integration.tar.gz: pkgmk -l 1073741824 -r $(solaris_WORKDIR) -f $(solaris_WORKDIR)/$*/prototype -o -d $(solaris_WORKDIR) ARCH=all VERSION=$(PKGVERSION.$*) $(GNUTAR) -cf - -C $(solaris_WORKDIR) $*$(LIBO_MAJOR) -desktop-int | gzip$@ Also, pkgmk fails, something is missing, so I just commented it because I don't need old style packages. If you need the patch files, I have them. Gabriele. Da: Gabriele Bulfon A: libreoffice-dev Data: 16 luglio 2013 13.30.26 CEST Oggetto: sysui CustomTarget_solaris.mk not working During install create phase, the sysui CustomaTarget_solaris.mk rule to create the desktop integration tar.gz is never invoked: $(solaris_WORKDIR)/%-desktop-integration.tar.gz: .. So build fails when trying to cp this file later. I tried to debug the problem but I still cannot figure out why that rule is never invoked. Also, I cannot understand why the Module_sysui.mk always runs slackware even when not building for slackware: $(eval $(call gb_Module_add_targets,sysui,\ CustomTarget_share \ CustomTarget_slackware \ Package_share \ Package_desktop \ $(if $(filter rpm,$(PKGFORMAT)),CustomTarget_rpm) \ $(if $(filter deb,$(PKGFORMAT)),CustomTarget_deb) \ $(if $(filter SOLARIS,$(OS)),CustomTarget_solaris) \ )) other targets are considered, while slackware is always built. thanks for any help! Gabriele. ___LibreOffice mailing listLibreOffice@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice ___LibreOffice mailing listLibreOffice@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
Hi, I could set up the correct env to build correctly up to soffice.bin and going on over extensions. I ended up with a problem linking with Xm Motif libraries (a problem inside my distro that I'm solving). I was wandering why Motif libraries are needed by these extension. Is it absolutely necessary? Any way to skip Motif dependencies? Gabriele. Da: Gabriele Bulfon A: Michael Stahl Cc: michael.me...@suse.com libreoffice-dev Data: 9 luglio 2013 18.01.19 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS usually libs should contain not just search paths but also the libraries to be linked, e.g. in config_host.mk with a system nss i get: export NSS_LIBS=$(gb_SPACE)-lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl also i guess only Sun ld knows -R, the GNU ld equivalent is -Wl,-rpath, Well done! With this env the build went on the unopkg.bin! CONFIGURE_ENV += NSS_CFLAGS=-I/usr/include/mps CONFIGURE_ENV += NSS_LIBS=-Wl,-rpath,/usr/lib/mps -L/usr/lib/mps -lssl3 -lsmime3 -lnss3 - lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl I prefer to use my userland Makefile options instead of modifying the solaris.mk Now the build is going on.let's wait and see... ;) Gabriele. Ok, it stopped later with this: [build LNK] Executable/pluginapp.bin S=/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1 O=$S/solver/unxsogi.pro W=$S/workdir/unxsogi.pro mkdir -p $W/LinkTarget/Executable/ /usr/gcc/4.4/bin/g++ -Wl,-z,origin '-Wl,-rpath,$ORIGIN:$ORIGIN/../ure-link/lib' -Wl,-rpath-link,$O/lib -z nodefs $W/CxxObject/extensions/source/plugin/unx/npwrap.o $W/CxxObject/extensions/source/plugin/unx/npnapi.o -Wl,--start-group $O/lib/libplugcon.a -Wl,--end-group -Wl,--no-as-needed -lm -lnsl -lsocket -lXm -lXt -lXext -lX11 -ldl -lgthread-2.0 -lpthread -lglib-2.0 -R/usr/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgdk_pixbuf_xlib-2.0 -lgmodule-2.0 -lpthread -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 -R/usr/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lglib-2.0 -luno_sal -o $W/LinkTarget/Executable/pluginapp.bin /usr/gnu/bin/ld: cannot find -luno_sal collect2: ld returned 1 exit status I guess I'm missing a librarynot built? ___LibreOffice mailing listLibreOffice@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
Thanks! I'll check and try to disable this on my build. Also, it's not about a Solaris general problem, usually Solaris 10/11 have X11 and motif libs correctly configured. It's my own XStreamOS/illumos dev machine that has new X11 and old Motif libs not happy each other. For this, I will build and switch to open-motif shortly. Gabriele. -- Da: Michael Meeks A: Gabriele Bulfon Cc: Michael Stahl libreoffice-dev Data: 15 luglio 2013 10.15.18 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS On Mon, 2013-07-15 at 09:44 +0200, Gabriele Bulfon wrote: I was wandering why Motif libraries are needed by these extension. Is it absolutely necessary? I'm amazed to hear that we link to motif in the modern world; it seems to be only this extension: $W/CxxObject/extensions/source/plugin/unx/npwrap.o $W/CxxObject/extensions/source/plugin/unx/npnapi.o I'd disable this I guess in configure.ac we have: dnl Check for NPAPI interface to plug browser plugins into LibreOffice documents I imagine we should just disable that for Solaris [ for now ]. Quite why we think Mozilla requires motif still I'm not sure I'd be amazed if they still had a hard dep on that. HTH, Michael. -- michael.me...@suse.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
I momentarily disabled with this patch (treated SunOS as for iOS and Android). Gabriele. -- Da: Michael Meeks A: Gabriele Bulfon Cc: Michael Stahl libreoffice-dev Data: 15 luglio 2013 10.15.18 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS On Mon, 2013-07-15 at 09:44 +0200, Gabriele Bulfon wrote: I was wandering why Motif libraries are needed by these extension. Is it absolutely necessary? I'm amazed to hear that we link to motif in the modern world; it seems to be only this extension: $W/CxxObject/extensions/source/plugin/unx/npwrap.o $W/CxxObject/extensions/source/plugin/unx/npnapi.o I'd disable this I guess in configure.ac we have: dnl Check for NPAPI interface to plug browser plugins into LibreOffice documents I imagine we should just disable that for Solaris [ for now ]. Quite why we think Mozilla requires motif still I'm not sure I'd be amazed if they still had a hard dep on that. HTH, Michael. -- michael.me...@suse.com sonicle-configure.patch Description: binary/octet-stream ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
Ok, I could go over extension by disabling that motif dependent plugin. Now, later, it's trying to build xmlsec1, and looks like it can't find libs I actually have! checking for pkg-config... yes checking for libxslt libraries= 1.0.20... no [I have it, it's 1.1.26] checking for openssl libraries= 0.9.6... no[I have both 0.9.6 and 1.0.0j] checking for NSS... no checking for NSS... no checking for NSS... no checking for NSS... no checking for NSS... no checking for nspr libraries= 4.0... no [I have nspr 4] checking for nss libraries= 3.2... no [I have nss 3.13.5] checking for gnutls libraries= 0.8.1... no[I have 3.1.9] checking for mscrypto libraries... none checking for crypto library... configure: error: At least one crypto library should exist for xmlsec1 I can't find the config.log of this component, this may hold the info I need to solve it. Can you help? gabriele. Da: Gabriele Bulfon A: michael.me...@suse.com Cc: Michael Stahl libreoffice-dev Data: 15 luglio 2013 10.42.52 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS I momentarily disabled with this patch (treated SunOS as for iOS and Android). Gabriele. -- Da: Michael Meeks A: Gabriele Bulfon Cc: Michael Stahl libreoffice-dev Data: 15 luglio 2013 10.15.18 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS On Mon, 2013-07-15 at 09:44 +0200, Gabriele Bulfon wrote: I was wandering why Motif libraries are needed by these extension. Is it absolutely necessary? I'm amazed to hear that we link to motif in the modern world; it seems to be only this extension: $W/CxxObject/extensions/source/plugin/unx/npwrap.o $W/CxxObject/extensions/source/plugin/unx/npnapi.o I'd disable this I guess in configure.ac we have: dnl Check for NPAPI interface to plug browser plugins into LibreOffice documents I imagine we should just disable that for Solaris [ for now ]. Quite why we think Mozilla requires motif still I'm not sure I'd be amazed if they still had a hard dep on that. HTH, Michael. -- michael.me...@suse.com ___LibreOffice mailing listLibreOffice@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
Yes, I could find it, but it says nothing particular, just that it cannot find the libs. But I'm sure I have them. Any idea? -- Da: Michael Stahl A: Gabriele Bulfon Cc: michael.me...@suse.com libreoffice-dev Data: 15 luglio 2013 15.23.29 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS On 15/07/13 15:07, Gabriele Bulfon wrote: Ok, I could go over extension by disabling that motif dependent plugin. Now, later, it's trying to build xmlsec1, and looks like it can't find libs I actually have! checking for pkg-config... yes checking for libxslt libraries= 1.0.20... no [I have it, it's 1.1.26] checking for openssl libraries= 0.9.6... no [I have both 0.9.6 and 1.0.0j] checking for NSS... no checking for NSS... no checking for NSS... no checking for NSS no checking for NSS... no checking for nspr libraries= 4.0... no [I have nspr 4] checking for nss libraries= 3.2... no [I have nss 3.13.5] checking for gnutls libraries= 0.8.1... no [I have 3.1.9] checking for mscrypto libraries... none checking for crypto library... configure: error: At least one crypto library should exist for xmlsec1 I can't find the config.log of this component, this may hold the info I need to solve it. Can you help? it's in workdir/*/UnpackedTarball/xmlsec/config.log ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
I see no switch in global configure to force it to use system xmlsec. How does it decide to install its own? One possibility is that I make and install my own component of xmlsec. Will the build system see it and decide not to build its own? Gabriele. Da: Gabriele Bulfon A: Michael Stahl Cc: michael.me...@suse.com libreoffice-dev Data: 15 luglio 2013 15.36.11 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS Yes, I could find it, but it says nothing particular, just that it cannot find the libs. But I'm sure I have them. Any idea? -- Da: Michael Stahl A: Gabriele Bulfon Cc: michael.me...@suse.com libreoffice-dev Data: 15 luglio 2013 15.23.29 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS On 15/07/13 15:07, Gabriele Bulfon wrote: Ok, I could go over extension by disabling that motif dependent plugin. Now, later, it's trying to build xmlsec1, and looks like it can't find libs I actually have! checking for pkg-config... yes checking for libxslt libraries= 1.0.20... no [I have it, it's 1.1.26] checking for openssl libraries= 0.9.6... no [I have both 0.9.6 and 1.0.0j] checking for NSS... no checking for NSS... no checking for NSS... no checking for NSS no checking for NSS... no checking for nspr libraries= 4.0... no [I have nspr 4] checking for nss libraries= 3.2... no [I have nss 3.13.5] checking for gnutls libraries= 0.8.1... no [I have 3.1.9] checking for mscrypto libraries... none checking for crypto library... configure: error: At least one crypto library should exist for xmlsec1 I can't find the config.log of this component, this may hold the info I need to solve it. Can you help? it's in workdir/*/UnpackedTarball/xmlsec/config.log ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___LibreOffice mailing listLibreOffice@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
Ok. I see. Problem is, I could easily build, package and install my xmlsec1 component in few minutes, and it did see all the required libs (openssl, and so on). How can I debug why the LO internal configure cannot see the deps? Gabriele. -- Da: Rene Engelhard A: Gabriele Bulfon Cc: Michael Stahl michael.me...@suse.com libreoffice-dev Data: 15 luglio 2013 16.05.26 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS On Mon, Jul 15, 2013 at 03:48:15PM +0200, Gabriele Bulfon wrote: I see no switch in global configure to force it to use system xmlsec. Yes, there is none... How does it decide to install its own? By just doing it unconditionally and everywhere. One possibility is that I make and install my own component of xmlsec. Will the build system see it and decide not to build its own? Nope. It's so heavily patched that it *might* build but not work afaicr. system-xmlsec was once tried by abandonded for that reason. :/ (It's - besides rhino - the only library which is needed internally...) Regards, Rene ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
Or maybe I could build the patched xmlsec1 component out of the LO fetched tarball, as a system library (naming it as LO version), then force the LO build not to build that component? Da: Gabriele Bulfon A: Rene Engelhard Cc: michael.me...@suse.com Michael Stahl libreoffice-dev Data: 15 luglio 2013 16.08.16 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS Ok. I see. Problem is, I could easily build, package and install my xmlsec1 component in few minutes, and it did see all the required libs (openssl, and so on). How can I debug why the LO internal configure cannot see the deps? Gabriele. -- Da: Rene Engelhard A: Gabriele Bulfon Cc: Michael Stahl michael.me...@suse.com libreoffice-dev Data: 15 luglio 2013 16.05.26 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS On Mon, Jul 15, 2013 at 03:48:15PM +0200, Gabriele Bulfon wrote: I see no switch in global configure to force it to use system xmlsec. Yes, there is none... How does it decide to install its own? By just doing it unconditionally and everywhere. One possibility is that I make and install my own component of xmlsec. Will the build system see it and decide not to build its own? Nope. It's so heavily patched that it *might* build but not work afaicr. system-xmlsec was once tried by abandonded for that reason. :/ (It's - besides rhino - the only library which is needed internally...) Regards, Rene ___LibreOffice mailing listLibreOffice@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
A deeper check of the xmlsec1 config.log, shows there are many vars that are empty, not passed by main configure, such as NSS_LIBS and NSS_CFLAGS. These are set up during configure, and I used them to build against system nspr that is in a different location, but are empty in this internal xmlsec1 config.log. Probably I could pass also other libs like OPENSSL_CFLAGS and OPENSSL_LIBS, but I should understand how to pass them. Da: Gabriele Bulfon A: Rene Engelhard Cc: michael.me...@suse.com libreoffice-dev Michael Stahl Data: 15 luglio 2013 16.34.41 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS Or maybe I could build the patched xmlsec1 component out of the LO fetched tarball, as a system library (naming it as LO version), then force the LO build not to build that component? Da: Gabriele Bulfon A: Rene Engelhard Cc: michael.me...@suse.com Michael Stahl libreoffice-dev Data: 15 luglio 2013 16.08.16 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS Ok. I see. Problem is, I could easily build, package and install my xmlsec1 component in few minutes, and it did see all the required libs (openssl, and so on). How can I debug why the LO internal configure cannot see the deps? Gabriele. -- Da: Rene Engelhard A: Gabriele Bulfon Cc: Michael Stahl michael.me...@suse.com libreoffice-dev Data: 15 luglio 2013 16.05.26 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS On Mon, Jul 15, 2013 at 03:48:15PM +0200, Gabriele Bulfon wrote: I see no switch in global configure to force it to use system xmlsec. Yes, there is none... How does it decide to install its own? By just doing it unconditionally and everywhere. One possibility is that I make and install my own component of xmlsec. Will the build system see it and decide not to build its own? Nope. It's so heavily patched that it *might* build but not work afaicr. system-xmlsec was once tried by abandonded for that reason. :/ (It's - besides rhino - the only library which is needed internally...) Regards, Rene ___LibreOffice mailing listLibreOffice@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice ___LibreOffice mailing listLibreOffice@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
...I also found that the old README.Solaris mentions a --disable-xmlsec, but the configure script doesn't mention it. Any other way to avoid building xmlsec? Da: Gabriele Bulfon A: Rene Engelhard Cc: michael.me...@suse.com libreoffice-dev Michael Stahl Data: 15 luglio 2013 16.47.25 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS A deeper check of the xmlsec1 config.log, shows there are many vars that are empty, not passed by main configure, such as NSS_LIBS and NSS_CFLAGS. These are set up during configure, and I used them to build against system nspr that is in a different location, but are empty in this internal xmlsec1 config.log. Probably I could pass also other libs like OPENSSL_CFLAGS and OPENSSL_LIBS, but I should understand how to pass them. Da: Gabriele Bulfon A: Rene Engelhard Cc: michael.me...@suse.com libreoffice-dev Michael Stahl Data: 15 luglio 2013 16.34.41 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS Or maybe I could build the patched xmlsec1 component out of the LO fetched tarball, as a system library (naming it as LO version), then force the LO build not to build that component? Da: Gabriele Bulfon A: Rene Engelhard Cc: michael.me...@suse.com Michael Stahl libreoffice-dev Data: 15 luglio 2013 16.08.16 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS Ok. I see. Problem is, I could easily build, package and install my xmlsec1 component in few minutes, and it did see all the required libs (openssl, and so on). How can I debug why the LO internal configure cannot see the deps? Gabriele. -- Da: Rene Engelhard A: Gabriele Bulfon Cc: Michael Stahl michael.me...@suse.com libreoffice-dev Data: 15 luglio 2013 16.05.26 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS On Mon, Jul 15, 2013 at 03:48:15PM +0200, Gabriele Bulfon wrote: I see no switch in global configure to force it to use system xmlsec. Yes, there is none... How does it decide to install its own? By just doing it unconditionally and everywhere. One possibility is that I make and install my own component of xmlsec. Will the build system see it and decide not to build its own? Nope. It's so heavily patched that it *might* build but not work afaicr. system-xmlsec was once tried by abandonded for that reason. :/ (It's - besides rhino - the only library which is needed internally...) Regards, Rene ___LibreOffice mailing listLibreOffice@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice ___LibreOffice mailing listLibreOffice@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice ___LibreOffice mailing listLibreOffice@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
solaris brands processors in configure
Hi, I just noticed Solaris can't check how many processors to use during configure, the case switch just resolves to * doing /proc/cupinfo, not working on Solaris. This may be the Solaris switch: psrinfo -v | grep on-line | wc -l Gabriele. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
usually libs should contain not just search paths but also the libraries to be linked, e.g. in config_host.mk with a system nss i get: export NSS_LIBS=$(gb_SPACE)-lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl also i guess only Sun ld knows -R, the GNU ld equivalent is -Wl,-rpath, Well done! With this env the build went on the unopkg.bin! CONFIGURE_ENV += NSS_CFLAGS=-I/usr/include/mps CONFIGURE_ENV += NSS_LIBS=-Wl,-rpath,/usr/lib/mps -L/usr/lib/mps -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl I prefer to use my userland Makefile options instead of modifying the solaris.mk Now the build is going on.let's wait and see... ;) Gabriele. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
usually libs should contain not just search paths but also the libraries to be linked, e.g. in config_host.mk with a system nss i get: export NSS_LIBS=$(gb_SPACE)-lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl also i guess only Sun ld knows -R, the GNU ld equivalent is -Wl,-rpath, Well done! With this env the build went on the unopkg.bin! CONFIGURE_ENV += NSS_CFLAGS=-I/usr/include/mps CONFIGURE_ENV += NSS_LIBS=-Wl,-rpath,/usr/lib/mps -L/usr/lib/mps -lssl3 -lsmime3 -lnss3 - lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl I prefer to use my userland Makefile options instead of modifying the solaris.mk Now the build is going on.let's wait and see... ;) Gabriele. Ok, it stopped later with this: [build LNK] Executable/pluginapp.bin S=/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1 O=$S/solver/unxsogi.pro W=$S/workdir/unxsogi.pro mkdir -p $W/LinkTarget/Executable/ /usr/gcc/4.4/bin/g++ -Wl,-z,origin '-Wl,-rpath,$ORIGIN:$ORIGIN/../ure-link/lib' -Wl,-rpath-link,$O/lib -z nodefs $W/CxxObject/extensions/source/plugin/unx/npwrap.o $W/CxxObject/extensions/source/plugin/unx/npnapi.o -Wl,--start-group $O/lib/libplugcon.a -Wl,--end-group -Wl,--no-as-needed -lm -lnsl -lsocket -lXm -lXt -lXext -lX11 -ldl -lgthread-2.0 -lpthread -lglib-2.0 -R/usr/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgdk_pixbuf_xlib-2.0 -lgmodule-2.0 -lpthread -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 -R/usr/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lglib-2.0 -luno_sal -o $W/LinkTarget/Executable/pluginapp.bin /usr/gnu/bin/ld: cannot find -luno_sal collect2: ld returned 1 exit status I guess I'm missing a librarynot built? ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
hmm... so vcl is supposed to be linked against NSS/NSPR libraries but somehow that doesn't work for you... what is really weird is that it fails on linking the executable, it should really fail when linking vcl library already. can you check that the link command lines use -Wl,-z,defs ? apparently not, try to copy the relevant lines from gbuild/platform/linux.mk to solaris.mk. the other problem is most likely that the libraries from the nss module somehow have hidden visibility (i assume you are not using --with-system-nss?)... if things work PR_Now should be exported like this: nm --defined-only -D -g solver/*/lib/libnspr4.so | grep PR_Now 00039123 T PR_Now you'll have to dig into the external build system there to figure out why it doesn't work, the files are in workdir/*/UnpackedTarball/nss (or if your distro has NSS packages try using --with-system-nss). Several things appear strange to me, so here are some considerations: 1 - Yes, I use system libs for nspr/nss, built by my distro userland 2 - Doing ldd on libvcllo.so shows a lot of lib dependencies, but no mention about nspr nor nss libs 3 - Doing your nm on my system libnspr4.so correctly reveals the output you said 4 - The nspr/nss libs are not under /usr/lib nor /lib in my system, they're all under /usr/lib/mps I tried running gmake under desktop as you requested (had to add the LD_ALTEXEC to force sun ld to run gnu ld instead): sonicle@vbxstreamdev:/sources/userlands/xstream-userland-gate/components/libreoffice/build/i86/desktop$ gmake LD_ALTEXEC=/usr/gnu/bin/ld [build LNK] Executable/unopkg.bin S=/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1 O=$S/solver/unxsogi.pro W=$S/workdir/unxsogi.pro mkdir -p $W/LinkTarget/Executable/ /usr/gcc/4.4/bin/gcc -Wl,-z,origin '-Wl,-rpath,$ORIGIN:$ORIGIN/../ure-link/lib' -Wl,-rpath-link,$O/lib -Wl,-rpath-link,/lib:/usr/lib -Wl,-z,combreloc -L$O/lib -L/usr/gcc/4.4/lib -L/usr/local/bin -L/usr/dt/lib -L/usr/openwin/lib -Wl,-O1 $W/CObject/desktop/source/pkgchk/unopkg/unopkg_main.o -Wl,--start-group -Wl,--end-group -Wl,--no-as-needed -lm -lnsl -lsocket -lcomphelper -luno_sal -ltllo -lunopkgapp -o $W/LinkTarget/Executable/unopkg.bin /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `PR_Now' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSMessage_Create' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `CERT_DecodeCertFromPackage' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSSignedData_AddCertificate' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSSignerInfo_IncludeCerts' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSEncoder_Finish' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSMessage_Destroy' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSSignedData_AddSignerInfo' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSSignerInfo_AddSigningTime' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSEncoder_Start' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_NoDB_Init' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `HASH_Begin' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `HASH_End' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSSignedData_Create' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSMessage_GetContentInfo' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSSignedData_GetContentInfo'
Re: Building LO 4.0.4.2 on illumos based OS
hmm... so vcl is supposed to be linked against NSS/NSPR libraries but somehow that doesn't work for you... what is really weird is that it fails on linking the executable, it should really fail when linking vcl library already. can you check that the link command lines use -Wl,-z,defs ? apparently not, try to copy the relevant lines from gbuild/platform/linux.mk to solaris.mk. the other problem is most likely that the libraries from the nss module somehow have hidden visibility (i assume you are not using --with-system-nss?)... if things work PR_Now should be exported like this: nm --defined-only -D -g solver/*/lib/libnspr4.so | grep PR_Now 00039123 T PR_Now you'll have to dig into the external build system there to figure out why it doesn't work, the files are in workdir/*/UnpackedTarball/nss (or if your distro has NSS packages try using --with-system-nss). Analyzing better, I've seen my userland component Makefile for libreoffice, contains specific env: CONFIGURE_ENV += NSS_CFLAGS=-I/usr/include/mps CONFIGURE_ENV += NSS_LIBS=-L/usr/lib/mps -R/usr/lib/mps CONFIGURE_ENV += NPAPI_HEADERS_LIBS=-L/usr/lib CONFIGURE_ENV += NPAPI_HEADERS_CFLAGS=-I/usr/include/npapi These are passed on at configure time. But I can't see these linking options on the running link: S=/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1 O=$S/solver/unxsogi.pro W=$S/workdir/unxsogi.pro mkdir -p $W/LinkTarget/Executable/ /usr/gcc/4.4/bin/gcc -Wl,-z,origin '-Wl,-rpath,$ORIGIN:$ORIGIN/../ure-link/lib' -Wl,-rpath-link,$O/lib -Wl,-rpath-link,/lib:/usr/lib -Wl,-z,combreloc -L$O/lib -L/usr/gcc/4.4/lib -L/usr/local/bin -L/usr/dt/lib -L/usr/openwin/lib -Wl,-O1 $W/CObject/desktop/source/pkgchk/unopkg/unopkg_main.o -Wl,--start-group -Wl,--end-group -Wl,--no-as-needed -lm -lnsl -lsocket -lcomphelper -luno_sal -ltllo -lunopkgapp -o $W/LinkTarget/Executable/unopkg.bin ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
Hi Michael, would be a great idea the tinderbox setup. I will send you the link of the XStream Desktop iso as soon as we have it out. BTW, can you help me with this? I really don't know what problem is thismust be something about gnu ld, but I had more experience with Sun ld. Gabriele. On Thursday, 2013-07-04 at 09:32, Gabriele Bulfon wrote: Hi, after long building LO 4.1.0.1 on illumos based OS, I reached this error: [build LNK] Executable/unopkg.bin /usr/gnu/bin/ld: /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/workdir/unxsogi.pro/LinkTarget/Executable/unopkg.bin: hidden symbol `main' in/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/workdir/unxsogi.pro/CObject/desktop/source/pkgchk/unopkg/unopkg_main.o is referenced byDSO /usr/gnu/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status Any idea? Gabriele. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: OConnection.cxx patch
Ok, here I go with the license statement: All of my past future contributions to LibreOffice may be licensed under the MPLv2/LGPLv3+ dual license. You can name it under Gabriele Bulfon (gabriele.bul...@sonicle.com), affiliation Sonicle S.r.l. Thanks, Gabriele. -- Da: Lionel Elie Mamane A: Gabriele Bulfon Cc: libreoffice@lists.freedesktop.org Data: 5 luglio 2013 9.20.34 CEST Oggetto: Re: OConnection.cxx patch On Thu, Jul 04, 2013 at 08:44:52AM +0200, Gabriele Bulfon wrote: I had to patch this file to build without errors: --- libreoffice-4.1.0.1/connectivity/source/drivers/odbcbase/OConnection.cxx Thu Jul 4 08:33:42 2013 +++ libreoffice-4.1.0.1/connectivity/source/drivers/odbcbase/OConnection.cxx Thu Jul 4 08:34:55 2013 @@ -417,7 +417,7 @@ checkDisposed(OConnection_BASE::rBHelper.bDisposed); -sal_Int32 nValueLen; +SQLINTEGER nValueLen; This change makes sense. Thank you for your contribution. However, before I can use it, could you please confirm that you allow us to use it under the MPLv2/LGPLv3+ dual license? I don't find your name on the list of people that have already agreed to that https://wiki.documentfoundation.org/Development/Developers It is customary to do a general statement that covers all your past, present and future contributions; see https://wiki.documentfoundation.org/Development/Developers#Example_Statement and https://wiki.documentfoundation.org/Development/Developers#Where_do_I_send_the_Statement.3F Also, please send your patches as attachments, to avoid your mail user agent (email program) to change spacing, do word wrapping, etc, which makes the patch harder to read, and makes the patch program fail to use it automatically. -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
Hi Gabriele, On Fri, 2013-07-05 at 08:14 +0200, Gabriele Bulfon wrote: Hi Michael, would be a great idea the tinderbox setup. I will send you the link of the XStream Desktop iso as soon as we have it out. Wonderful. BTW, can you help me with this? I really don't know what problem is thismust be something about gnu ld, but I had more experience with Sun ld. ... [build LNK] Executable/unopkg.bin /usr/gnu/bin/ld: /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/workdir/unxsogi.pro/LinkTarget/Executable/unopkg.bin: hidden symbol`main' in/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/workdir/unxsogi.pro/CObject/desktop/source/pkgchk/unopkg/unopkg_main.o isreferenced byDSO /usr/gnu/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status Looks like a mis-interaction with some visibility markup - though clearly getting more output would be good: cd desktop make gives a more verbose make. Try something like the attached; if that works we should get it into master and -4-1 :-) HTH, Michael. -- michael.me...@suse.com Here is what I got after applying your patch (causing a lot of rebuilding of previous code). Later I will send you the output of the detail you aksed: [build LNK] Library/libunopkgapp.so [build C ] desktop/source/pkgchk/unopkg/unopkg_main.c [build LNK] Executable/unopkg.bin /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `PR_Now' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSMessage_Create' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `CERT_DecodeCertFromPackage' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSSignedData_AddCertificate' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSSignerInfo_IncludeCerts' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSEncoder_Finish' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSMessage_Destroy' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSSignedData_AddSignerInfo' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSSignerInfo_AddSigningTime' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSEncoder_Start' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_NoDB_Init' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `HASH_Begin' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `HASH_End' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSSignedData_Create' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSMessage_GetContentInfo' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSSignedData_GetContentInfo' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSSignerInfo_Create' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSContentInfo_SetContent_SignedData' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `HASH_Update' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `NSS_CMSSignedData_SetDigestValue' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libvcllo.so: undefined reference to `HASH_Create' /sources/userlands/xstream-userland-gate
[Libreoffice-commits] core.git: 2 commits - connectivity/source sw/source
connectivity/source/drivers/odbcbase/OConnection.cxx |2 +- sw/source/filter/html/swhtml.cxx |6 +++--- sw/source/filter/html/swhtml.hxx |2 +- 3 files changed, 5 insertions(+), 5 deletions(-) New commits: commit 12b7ba60b746031f2bbef59758270cc0281f4dab Author: Gabriele Bulfon gabriele.bul...@sonicle.com Date: Fri Jul 5 21:27:12 2013 +0200 use proper SQLINTEGER type (fixes build on Illumos) Change-Id: I85296600195dd5d74d2a112ce6cfef7f276535ab diff --git a/connectivity/source/drivers/odbcbase/OConnection.cxx b/connectivity/source/drivers/odbcbase/OConnection.cxx index dfe22be..9e04bba 100644 --- a/connectivity/source/drivers/odbcbase/OConnection.cxx +++ b/connectivity/source/drivers/odbcbase/OConnection.cxx @@ -417,7 +417,7 @@ OUString SAL_CALL OConnection::getCatalog( ) throw(SQLException, RuntimeExcepti checkDisposed(OConnection_BASE::rBHelper.bDisposed); -sal_Int32 nValueLen; +SQLINTEGER nValueLen; char pCat[1024]; OTools::ThrowException(this, N3SQLGetConnectAttr(m_aConnectionHandle,SQL_ATTR_CURRENT_CATALOG,(SDB_ODBC_CHAR*)pCat,(sizeof pCat)-1,nValueLen), commit b3f41543851e9985c6c7ba133c32753c9bc732c1 Author: Michael Stahl mst...@redhat.com Date: Fri Jul 5 15:04:50 2013 +0200 SwHTMLParser: avoid a spurious ~SwindexReg assert The pPam that is passed to SwHTMLParser would be reinitialized by SwReader::Read anyway. Can be reproduced with bugdoc from fdo#65935. Change-Id: I3b7dcc9c83d9d2eac05ee6ec38909dea7350d245 diff --git a/sw/source/filter/html/swhtml.cxx b/sw/source/filter/html/swhtml.cxx index cf572e9..76a2d17 100644 --- a/sw/source/filter/html/swhtml.cxx +++ b/sw/source/filter/html/swhtml.cxx @@ -237,7 +237,7 @@ sal_uLong HTMLReader::Read( SwDoc rDoc, const String rBaseURL, SwPaM rPam, co -SwHTMLParser::SwHTMLParser( SwDoc* pD, const SwPaM rCrsr, SvStream rIn, +SwHTMLParser::SwHTMLParser( SwDoc* pD, SwPaM rCrsr, SvStream rIn, const String rPath, const String rBaseURL, int bReadNewDoc, @@ -305,7 +305,8 @@ SwHTMLParser::SwHTMLParser( SwDoc* pD, const SwPaM rCrsr, SvStream rIn, eScriptLang = HTML_SL_UNKNOWN; bAnyStarBasic = sal_True; -pPam = new SwPaM( *rCrsr.GetPoint() ); +rCrsr.DeleteMark(); +pPam = rCrsr; // re-use existing cursor: avoids spurious ~SwIndexReg assert memset( aAttrTab, 0, sizeof( _HTMLAttrTable )); // Die Font-Groessen 1-7 aus der INI-Datei lesen @@ -453,7 +454,6 @@ SwHTMLParser::~SwHTMLParser() aSetAttrTab.clear(); } -delete pPam; delete pCSS1Parser; delete pNumRuleInfo; DeleteFormImpl(); diff --git a/sw/source/filter/html/swhtml.hxx b/sw/source/filter/html/swhtml.hxx index d3e0ab4..a8db7b8 100644 --- a/sw/source/filter/html/swhtml.hxx +++ b/sw/source/filter/html/swhtml.hxx @@ -894,7 +894,7 @@ protected: public: -SwHTMLParser( SwDoc* pD, const SwPaM rCrsr, SvStream rIn, +SwHTMLParser( SwDoc* pD, SwPaM rCrsr, SvStream rIn, const String rFileName, const String rBaseURL, int bReadNewDoc = sal_True, ___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Branch 'libreoffice-4-1' - connectivity/source
connectivity/source/drivers/odbcbase/OConnection.cxx |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) New commits: commit 2d398166a937b494da7e7b198d2a00d20393a106 Author: Gabriele Bulfon gabriele.bul...@sonicle.com Date: Fri Jul 5 21:27:12 2013 +0200 use proper SQLINTEGER type (fixes build on Illumos) Change-Id: I85296600195dd5d74d2a112ce6cfef7f276535ab (cherry picked from commit 12b7ba60b746031f2bbef59758270cc0281f4dab) Signed-off-by: Michael Stahl mst...@redhat.com diff --git a/connectivity/source/drivers/odbcbase/OConnection.cxx b/connectivity/source/drivers/odbcbase/OConnection.cxx index dfe22be..9e04bba 100644 --- a/connectivity/source/drivers/odbcbase/OConnection.cxx +++ b/connectivity/source/drivers/odbcbase/OConnection.cxx @@ -417,7 +417,7 @@ OUString SAL_CALL OConnection::getCatalog( ) throw(SQLException, RuntimeExcepti checkDisposed(OConnection_BASE::rBHelper.bDisposed); -sal_Int32 nValueLen; +SQLINTEGER nValueLen; char pCat[1024]; OTools::ThrowException(this, N3SQLGetConnectAttr(m_aConnectionHandle,SQL_ATTR_CURRENT_CATALOG,(SDB_ODBC_CHAR*)pCat,(sizeof pCat)-1,nValueLen), ___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
OConnection.cxx patch
Hi, I had to patch this file to build without errors: --- libreoffice-4.1.0.1/connectivity/source/drivers/odbcbase/OConnection.cxx Thu Jul 4 08:33:42 2013 +++ libreoffice-4.1.0.1/connectivity/source/drivers/odbcbase/OConnection.cxx Thu Jul 4 08:34:55 2013 @@ -417,7 +417,7 @@ checkDisposed(OConnection_BASE::rBHelper.bDisposed); -sal_Int32 nValueLen; +SQLINTEGER nValueLen; char pCat[1024]; OTools::ThrowException(this, N3SQLGetConnectAttr(m_aConnectionHandle,SQL_ATTR_CURRENT_CATALOG,(SDB_ODBC_CHAR*)pCat,(sizeof pCat)-1,nValueLen), Gabriele Bulfon - Sonicle S.r.l. Tel +39 028246016 Int. 30 - Fax +39 028243880 via Santa Maria Valle 3 - 20123 - Milano - Italy http://www.sonicle.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
final link failed: Bad value
Hi, after long building LO 4.1.0.1 on illumos based OS, I reached this error: [build LNK] Executable/unopkg.bin /usr/gnu/bin/ld: /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/workdir/unxsogi.pro/LinkTarget/Executable/unopkg.bin: hidden symbol `main' in /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/workdir/unxsogi.pro/CObject/desktop/source/pkgchk/unopkg/unopkg_main.o is referenced by DSO /usr/gnu/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status Any idea? Gabriele. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
ah sorry the relevant one is gb_Executable__get_rpath I also tried using Sun ld, but looks like options for ld are always gnu-ld ones, so compilation stop much earlier. ...any clue? sure, if you want to use Sun ld you need to change quite a few things in solaris.mk to use different options. -- Michael Stahl | Software Engineer Platform Engineering - Desktop Team Red Hat Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com Progressing in LO build, it reached the connectivity source point and I got this: [build CMP] connectivity/source/drivers/mysql/mysql [build CXX] connectivity/source/drivers/odbcbase/OPreparedStatement.cxx [build CXX] connectivity/source/drivers/odbcbase/OStatement.cxx [build CXX] connectivity/source/drivers/odbcbase/OResultSetMetaData.cxx [build CXX] connectivity/source/drivers/odbcbase/OResultSet.cxx [build CXX] connectivity/source/drivers/odbcbase/OTools.cxx [build CXX] connectivity/source/drivers/odbcbase/ODatabaseMetaDataResultSet.cxx [build CXX] connectivity/source/drivers/odbcbase/ODatabaseMetaData.cxx [build CXX] connectivity/source/drivers/odbcbase/ODriver.cxx [build CXX] connectivity/source/drivers/odbcbase/OConnection.cxx /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/connectivity/source/drivers/odbcbase/OConnection.cxx: In member function 'virtual rtl::OUString connectivity::odbc::OConnection::getCatalog()': /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/connectivity/source/drivers/odbcbase/OConnection.cxx:423: error: invalid conversion from 'sal_Int32*' to 'SQLINTEGER*' make[2]: *** [/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/workdir/unxsogi.pro/CxxObject/connectivity/source/drivers/odbcbase/OConnection.o] Error 1 Any idea?? Gabriele. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
On Sat, Jun 29, 2013 at 16:24:42 CEST, Norbert Thiebaud wrote take a look at Library_cpp_uno.mk and in particular how bridges_SELECTED_BRIDGE is set... from what I read the else ifeq($(CPU),I) line 56 pre-empt the section you want which is lower.. line 143 some re-order of the different if/else section seems in order (to works we need to test from the most particular to the most generic) Norbert Great! I moved the SOLARISI code from line 143 up just before line 56 and it worked ;) Thanx! Gabriele. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
take a look at Library_cpp_uno.mk and in particular how bridges_SELECTED_BRIDGE is set... from what I read the else ifeq($(CPU),I) line 56 pre-empt the section you want which is lower.. line 143 some re-order of the different if/else section seems in order (to works we need to test from the most particular to the most generic) Norbert Build goes through for some time, then I got this (I didn't have this on 4.0): [build C ] sal/osl/unx/tempfile.c [build C ] sal/osl/unx/thread.c [build C ] sal/osl/unx/time.c [build C ] sal/osl/unx/util.c [build C ] sal/osl/unx/signal.c [build C ] sal/osl/unx/backtrace.c [build ASM] sal/osl/unx/asm/interlck_x86 [build LNK] Library/libuno_sal.so ERROR: aux-target missing, library deleted, please try running make again make[2]: *** [/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/workdir/unxsogi.pro/LinkTarget/Library//libuno_sal.so.3] Error 1 Running make again as suggested, repeats the error. Any idea? Gabriele. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
Hi, because I need to work on a consolidated tar.gz source version, I'm not using master, so I cannot pull changes at the moment. Can you suggest me what modifications I need? Gabriele. -- Da: Michael Stahl A: Gabriele Bulfon Cc: libreoffice@lists.freedesktop.org Raffaele Fullone Jonathan Adams Data: 1 luglio 2013 13.34.58 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS On 01/07/13 11:03, Gabriele Bulfon wrote: [build LNK] Library/libuno_sal.so ERROR: aux-target missing, library deleted, please try running make again make[2]: *** [/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/workdir/unxsogi.pro/LinkTarget/Library//libuno_sal.so.3] Error 1 Running make again as suggested, repeats the error. Any idea? apparently the solaris.mk is out of sync with the unxgcc.mk from which it was copied; i've pushed 99a4baf89c470d1e73b4e87fe9adf37a09230a2c to fix the dynamic link command. this duplication needs to be reverted in the long run, solaris.mk should include unxgcc.mk. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
On Mon, Jul 1, 2013 at 6:39 AM, Gabriele Bulfon gabriele.bul...@sonicle.com wrote: Hi, because I need to work on a consolidated tar.gz source version, I'm not using master, so I cannot pull changes at the moment. Can you suggest me what modifications I need? http://cgit.freedesktop.org/libreoffice/core/commit/? id=99a4baf89c470d1e73b4e87fe9adf37a09230a2c Thanks Norbert :) it worked great ;) Gabriele. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
On Mon, Jul 1, 2013 at 6:39 AM, Gabriele Bulfon gabriele.bul...@sonicle.com wrote: Hi, because I need to work on a consolidated tar.gz source version, I'm not using master, so I cannot pull changes at the moment. Can you suggest me what modifications I need? http://cgit.freedesktop.org/libreoffice/core/commit/?id=99a4baf89c470d1e73b4e87fe9adf37a09230a2c Ok, now I'm stuck again with libreg.so not being resolved: [build LNK] Executable/cppumaker /usr/gnu/bin/ld: warning: libreg.so, needed by /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libunoidl.so, not found (try using -rpath or -rpath-link) I tried using the solaris.mk commented options: @@ -120,6 +120,7 @@ -L$(SYSBASE)/lib \ -L$(SYSBASE)/usr/lib \ -Wl,-z,combreloc \ + -Wl,-rpath-link,$(SYSBASE)/lib:$(SYSBASE)/usr/lib \ $(SOLARLIB) \ ifeq ($(HAVE_LD_HASH_STYLE),TRUE) but no luck, still cannot solve. I also tried using Sun ld, but looks like options for ld are always gnu-ld ones, so compilation stop much earlier. ...any clue? Gabriele. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
On 01/07/13 16:43, Michael Stahl wrote: On 01/07/13 14:58, Gabriele Bulfon wrote: [build LNK] Executable/cppumaker /usr/gnu/bin/ld: warning: libreg.so, needed by /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/solver/unxsogi.pro/lib/libunoidl.so, not found (try using -rpath or -rpath-link) I tried using the solaris.mk commented options: @@ -120,6 +120,7 @@ -L$(SYSBASE)/lib \ -L$(SYSBASE)/usr/lib \ -Wl,-z,combreloc \ + -Wl,-rpath-link,$(SYSBASE)/lib:$(SYSBASE)/usr/lib \ $(SOLARLIB) \ ifeq ($(HAVE_LD_HASH_STYLE),TRUE) but no luck, still cannot solve. did you try adding it to definition of gb_Library__get_rpath like it's done in unxgcc.mk ? (perhaps just copy that) ah sorry the relevant one is gb_Executable__get_rpath I also tried using Sun ld, but looks like options for ld are always gnu-ld ones, so compilation stop much earlier. ...any clue? sure, if you want to use Sun ld you need to change quite a few things in solaris.mk to use different options. Great suggestions! Path to the solution ;) it went through :) Following your suggestion I found solaris.mk had many more lines about rpath, the ones you pointed, and they were almost all changed from unxgcc.mk into something different. I guess the one who tried to do solaris.mk was using Sun ld instead of Gnu. It's going on building now. ;) Gabriele. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
On 28/06/13 12:01, Michel Stahl wrote:
On 28/06/13 07:39, Gabriele Bulfon wrote:
Hi, I moved to 4.1 build from scratch.
Build required me a couple of new system libs (libodfgen and libmwaw)
that I could package easily.
Then, it stops just after the succesful configure:
/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1//bridges/Module_bridges.mk:28:
*** no bridge selected for build: bailing out.. Stop.
the UNO binary
C++ bridge, which is specific to architecture and
compiler ABI.
i guess you need to tweak the if conditionals in
bridges/Module_bridges.mk to select the appropriate GCC3 bridge for your
platform; there is one in bridges/source/cpp_uno/gcc3_solaris_{intel,sparc}
Hi, I noticed the bridges structure is quite changed from 4.0 and 4.1.
In 4.0 build, it could correctly select the solaris intel bridge.
Looks like 4.1 cannot do it anymore, though I debugged env vars and they look
correctly set to CPU=I and OS=SOLARIS.
Actually I cannot see how that 4.1 mk file is now selecting the bridge,
while in 4.0 there were a lot of if, including solaris specifics.
Can you help me on how to force Module_bridges.mk to use gcc3_solaris_intel?
Another clue: I'm using gcc4.4.7maybe this is annoying it? And if yes, why
4.0 was not?
Thanks again,
Gabriele.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
Hi, I moved to 4.1 build from scratch. Build required me a couple of new system libs (libodfgen and libmwaw) that I could package easily. Then, it stops just after the succesful configure: make[1]: Entering directory `/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1' /usr/gnu/bin/make -j 1 -rsw -f /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1/Makefile.gbuild make[2]: Entering directory `/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1' /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1//bridges/Module_bridges.mk:28: *** no bridge selected for build: bailing out. Stop. make[2]: Leaving directory `/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1' make[1]: *** [build] Error 2 make[1]: Leaving directory `/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.1.0.1' gmake: *** [/sources/userlands/xstream-userland-gate/components/libreoffice/build/i86/.built] Error 2 What does it mean? What bridge? Thanks, Gabriele. -- Da: Michael Stahl A: Gabriele Bulfon Cc: libreoffice@lists.freedesktop.org Raffaele Fullone Jonathan Adams Pierre-Eric Pelloux-Prayer Data: 27 giugno 2013 14.04.21 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS On 27/06/13 10:52, Gabriele Bulfon wrote: Hi, I'm working on our Sonicle XStreamOS distro based on illumos kernel. I encountered some problems building LO 4.0..4.2. i'd suggest to try building libreoffice-4-1 branch or master instead, because it should be easier: in the libreoffice-4-0 branch the migration to the new GNU make based build system was still in progress, so you have to get both the new and the old build system to work for you, whereas in libreoffice-4-1 and master there is only one build system. [build LNK] Executable/cppumaker /usr/gnu/bin/ld: warning: libstore.so, needed by /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.0.4.2/solver/unxsogi.pro/lib/libreg.so, not found (try using -rpath or -rpath-link) I can't see why libreg.so can't resolve libstore.so, as they both live in solver/unxsogi.pro/lib : the GNU linker apparently does not automatically use RPATH stored in the .so for finding dependent libraries, and neither uses the -L passed to it for finding dependent libraries. it uses the -L parameters only to find libraries that are explicitly listed on the command line (-lfoo); apparently you have -lreg but not -lstore on the command line. the solution is to use -rpath-link, which is used to find dependent libraries that are not explicitly listed on the command line. git grep finds this, which is commented out for reasons unknown to me: solenv/gbuild/platform/solaris.mk:#JAD#'-Wl,-rpath-link,$(gb_Library_OUTDIRLOCATION)' (iirc Sun ld would search -L directories in this case too so doesn't need -rpath-link.) and ldd shows correct resolutions: ldd uses the RPATH $ORIGIN in the .so hence it has no problems. i am not sure if it would be better to use Sun ld or GNU ld on OpenSolaris; i guess GNU ld has the advantage that it's the same as on GNU/Linux so should make porting easier. by the way here's some links to threads from previous porting efforts http://permalink.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/22798 http://permalink.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/39846 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Building LO 4.0.4.2 on illumos based OS
Hi,
I'm working on our Sonicle XStreamOS distro based on illumos kernel.
I encountered some problems building LO 4.0.4.2.
First, I decided to use system libs as much as possible, so I'm building with
this configure options:
--enable-gtk3 --disable-python --with-system-libs --with-system-altlinuxhyph=no
--with-system-lpsolve=no --without-java --with-x
I had to disable python because of some problem during build, at the moment.
I will see if I can provide a system python 3.3 later.
After building and packaging all the required system libs, I decided to keep
altlinuxhyph and lpsolve as internal ones. All the other ones go fine from
system.
Then I found that LO needs gnu ld, used ld options don't work with sun ld, so I
could use the sun ld env
LD_ALTEXEC to force it to run gnu ld once invoked, and build went on almost
fine.
I stumbled on on error about madvise missing, but I could find a working
patch:
--- libreoffice-4.0.4.2/sal/osl/unx/file.cxxThu Jun 27 09:22:25 2013
+++ libreoffice-4.0.4.2/sal/osl/unx/file.cxxThu Jun 27 09:22:54 2013
@@ -1260,7 +1260,7 @@
OSL_TRACE(
posix_madvise(..., POSIX_MADV_WILLNEED) failed with %d, e);
}
-#elif defined SOLARIS
+#elif defined NOTSOLARIS
if (madvise(static_cast
(p), nLength, MADV_WILLNEED) != 0)
{
OSL_TRACE(madvise(..., MADV_WILLNEED) failed with %d, errno);
basically it disables the call to madvise on my env, then build went on very
long over the tail_build.
Here, I finally got this strange error:
[build CXX] store/source/object.cxx
[build CXX] store/source/lockbyte.cxx
[build CXX] store/source/storbase.cxx
[build CXX] store/source/storbios.cxx
[build CXX] store/source/storcach.cxx
[build CXX] store/source/stordata.cxx
[build CXX] store/source/stordir.cxx
[build CXX] store/source/storlckb.cxx
[build CXX] store/source/stortree.cxx
[build CXX] store/source/storpage.cxx
[build CXX] store/source/store.cxx
[build LNK] Library/libstore.so
[build CXX] registry/source/keyimpl.cxx
[build CXX] registry/source/reflread.cxx
[build CXX] registry/source/reflwrit.cxx
[build CXX] registry/source/regimpl.cxx
[build CXX] registry/source/registry.cxx
[build CXX] registry/source/regkey.cxx
[build LNK] Library/libreg.so
[build CXX] salhelper/source/condition.cxx
[build CXX] salhelper/source/dynload.cxx
[build CXX] salhelper/source/simplereferenceobject.cxx
[build CXX] salhelper/source/thread.cxx
[build CXX] salhelper/source/timer.cxx
[build LNK] Library/libuno_salhelpergcc3.so
[build CXX] codemaker/source/commoncpp/commoncpp.cxx
[build LNK] StaticLibrary/libcodemaker_cpp.a
[build CXX] codemaker/source/codemaker/dependencies.cxx
[build CXX] codemaker/source/codemaker/exceptiontree.cxx
[build CXX] codemaker/source/codemaker/global.cxx
[build CXX] codemaker/source/codemaker/options.cxx
[build CXX] codemaker/source/codemaker/typemanager.cxx
[build CXX] codemaker/source/codemaker/unotype.cxx
[build CXX] codemaker/source/codemaker/codemaker.cxx
[build LNK] StaticLibrary/libcodemaker.a
[build CXX] codemaker/source/cppumaker/cppumaker.cxx
[build CXX] codemaker/source/cppumaker/cppuoptions.cxx
[build CXX] codemaker/source/cppumaker/cpputype.cxx
[build CXX] codemaker/source/cppumaker/dumputils.cxx
[build CXX] codemaker/source/cppumaker/includes.cxx
[build LNK] Executable/cppumaker
/usr/gnu/bin/ld: warning: libstore.so, needed by
/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.0.4.2/solver/unxsogi.pro/lib/libreg.so,
not found (try using -rpath or -rpath-link)
/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.0.4.2/solver/unxsogi.pro/lib/libreg.so:
undefined reference to `store_openStream'
/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.0.4.2/solver/unxsogi.pro/lib/libreg.so:
undefined reference to `store_createMemoryFile'
/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.0.4.2/solver/unxsogi.pro/lib/libreg.so:
undefined reference to `store_closeFile'
/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.0.4.2/solver/unxsogi.pro/lib/libreg.so:
undefined reference to `store_findFirst'
/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.0.4.2/solver/unxsogi.pro/lib/libreg.so:
undefined reference to `store_findNext'
/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.0.4.2/solver/unxsogi.pro/lib/libreg.so:
undefined reference to `store_openFile'
/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.0.4.2/solver/unxsogi.pro/lib/libreg.so:
undefined reference to `store_openDirectory'
/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.0.4.2/solver/unxsogi.pro/lib/libreg.so:
undefined reference to `store_readStream'
/sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.0.4.2/solver/unxsogi.pro/lib/libreg.so:
undefined reference to `store_writeStream'
Re: Building LO 4.0.4.2 on illumos based OS
Yes, madvise is available in illumos, but probably some build flag is excluding
its definition
from the sys/mman.h, that is full of ifdef about __EXTENSIONS__,
__XOPEN_OR_POSIX, and so on.
I found someone from OpenIndiana solving it by excluding like I did.
Anyway, now I'm stuck with the last problem :(
Gabriele.
--
Da: Riccardo Magliocchetti
A: libreoffice@lists.freedesktop.org
Data: 27 giugno 2013 12.49.12 CEST
Oggetto: Re: Building LO 4.0.4.2 on illumos based OS
Hi Gabriele,
Il 27/06/2013 10:52, Gabriele Bulfon ha scritto:
Hi,
I'm working on our Sonicle XStreamOS distro based on illumos kernel.
[snip]
I stumbled on on error about madvise missing, but I could find a working
patch:
--- libreoffice-4.0.4.2/sal/osl/unx/file.cxxThu Jun 27 09:22:25 2013
+++ libreoffice-4.0.4.2/sal/osl/unx/file.cxxThu Jun 27 09:22:54 2013
@@ -1260,7 +1260,7 @@
OSL_TRACE(
posix_madvise(..., POSIX_MADV_WILLNEED) failed with %d, e);
}
-#elif defined SOLARIS
+#elif defined NOTSOLARIS
if (madvise(static_cast
(p), nLength, MADV_WILLNEED) != 0)
{
OSL_TRACE(madvise(..., MADV_WILLNEED) failed with %d, errno);
basically it disables the call to madvise on my env, then build went on very
long over the tail_build.
That's strange, you should have madvise on illumos per
http://illumos.org/man/3C/madvise . May this be an issue with the libc
in Sonicle XStreamOS?
cheers,
riccardo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building LO 4.0.4.2 on illumos based OS
Great answers! Thanx ;) I'm already moving to 4.1, and see if it still have the libstore issue, in that case I'll look for the commented line and re-enable it. BTW, I don't know why, but I was forced to use gnu ld (via the sun ld env LD_ALTEXEC), or LO ld options would not work. Maybe there is something I should say during configure to let it understand I'm in a Solaris-type OS? Gabriele. -- Da: Michael Stahl A: Gabriele Bulfon Cc: libreoffice@lists.freedesktop.org Raffaele Fullone Jonathan Adams Pierre-Eric Pelloux-Prayer Data: 27 giugno 2013 14.04.21 CEST Oggetto: Re: Building LO 4.0.4.2 on illumos based OS On 27/06/13 10:52, Gabriele Bulfon wrote: Hi, I'm working on our Sonicle XStreamOS distro based on illumos kernel. I encountered some problems building LO 4.0..4.2. i'd suggest to try building libreoffice-4-1 branch or master instead, because it should be easier: in the libreoffice-4-0 branch the migration to the new GNU make based build system was still in progress, so you have to get both the new and the old build system to work for you, whereas in libreoffice-4-1 and master there is only one build system. [build LNK] Executable/cppumaker /usr/gnu/bin/ld: warning: libstore.so, needed by /sources/userlands/xstream-userland-gate/components/libreoffice/libreoffice-4.0.4.2/solver/unxsogi.pro/lib/libreg.so, not found (try using -rpath or -rpath-link) I can't see why libreg.so can't resolve libstore.so, as they both live in solver/unxsogi.pro/lib : the GNU linker apparently does not automatically use RPATH stored in the .so for finding dependent libraries, and neither uses the -L passed to it for finding dependent libraries. it uses the -L parameters only to find libraries that are explicitly listed on the command line (-lfoo); apparently you have -lreg but not -lstore on the command line. the solution is to use -rpath-link, which is used to find dependent libraries that are not explicitly listed on the command line. git grep finds this, which is commented out for reasons unknown to me: solenv/gbuild/platform/solaris.mk:#JAD#'-Wl,-rpath-link,$(gb_Library_OUTDIRLOCATION)' (iirc Sun ld would search -L directories in this case too so doesn't need -rpath-link.) and ldd shows correct resolutions: ldd uses the RPATH $ORIGIN in the .so hence it has no problems. i am not sure if it would be better to use Sun ld or GNU ld on OpenSolaris; i guess GNU ld has the advantage that it's the same as on GNU/Linux so should make porting easier. by the way here's some links to threads from previous porting efforts http://permalink.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/22798 http://permalink.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/39846 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
