On MacOs Yosemite 10.10.12 + master sources updated some days ago, LO fails to launch with this error: warn:desktop.app:48508:1:desktop/source/app/langselect.cxx:125: ignoring Exception "component context fails to supply service 'com.sun.star.configuration.ReadOnlyAccess' of type 'com.sun.star.container.XHierarchicalNameAccess'" libc++abi.dylib: terminating with uncaught exception of type com::sun::star::uno::DeploymentException Abort trap: 6 here's my autogen.input: --enable-64-bit #--with-system-odbc --enable-werror #--enable-python=internal --enable-debug --enable-dbgutil --enable-crashdump --enable-dependency-tracking --enable-online-update #--enable-ext-mariadb-connector #--without-system-mariadb #--enable-bundle-mariadb #--with-lang=en-US it fr de es pt ru cs hu pl da sv el sk is nl --with-lang=ALL --without-junit --with-myspell-dicts
Created attachment 114242 [details] bt
(In reply to Julien Nabet from comment #0) > On MacOs Yosemite 10.10.12 + master sources updated some days ago, LO fails > to launch with this error: > ... I see current master builds from today available here: http://dev-builds.libreoffice.org/daily/master/MacOSX-10.10@61/ Does this problem persist? Is it something to discuss on the dev list? Status -> NEEDINFO
I haven't spoken about it on dev mailing list since few people use MacOs + debug. (same reason about IRC) About the daily build, is it a debug build? Indeed, I use debug build and I don't see config file on this daily. About building with recent sources, I gave it a try about a week ago. I give a new try from scratch tomorrow. Finally, I mainly work on Linux with master sources + debug mode but since I've got a Mac, I'm trying to contribute on some MacOs only bugs when I've got time. In brief, it's not urgent for me :-) I'll put it back to UNCONFIRMED (or perhaps RESOLVED/WFM!) once I'll got results from new build.
With master sources updated today, I still got have the same problem. Alex: do you still build LO master sources? (I don't remember if you used debug mode or not) If yes, any thought about what may fail in my case?
Hi Julien, I build MacOS debug incremental builds daily from master, and roughly one or two full clean builds per week too. No problems here with starting LO, either via Finder or command line. Alex
I use git sources, run "make" then I type "instdir/LibreOfficeDev.app/Contents/program" and finally "./soffice" as I always do on Linux. Wonder what's the problem :-( Anyway, thank you for your feedback.
Works fine here, although a simpler way to start LO is to give the command: open instdir/LibreOfficeDev.app (or double-click on that LibreOfficeDev.app in Finder) Maybe you have some cruft accumulated in instdir/Contents/user; try make clean?
I built master on Mac OS X 10.10.2 yesterday without problems. But I use the --enable-python=internal option. I remember in the past I had also a DeploymentException. That was when I built it without Python, but I don't know if there was a causal connection. Anyway the DeploymentException disappeared when I built with Python. I also added PYTHON=python3.3 to the autogen.sh command
I changed autogen.input to have: --enable-python=internal + I tried make clean before building and tried too "open instdir/LibreOfficeDev.app" Same result. I haven't yet tested PYTHON=python3.3 but is it useful since I use now --enable-python=internal ?
looks like you have no instdir/LibreOfficeDev.app/Contents/Frameworks/libconfigmgrlo.dylib or it cannot be loaded (in which case running "SAL_LOG=+INFO.sal.osl instdir/LibreOfficeDev.app/Contents/MacOS/soffice" might give a clue on stderr)
Stephan: here are the information you talked about: $ ls -l instdir/LibreOfficeDev.app/Contents/Frameworks/libconfigmgrlo.dylib -rwxr-xr-x 1 julien staff 2669292 2 avr 12:38 instdir/LibreOfficeDev.app/Contents/Frameworks/libconfigmgrlo.dylib $ SAL_LOG=+INFO.sal.osl instdir/LibreOfficeDev.app/Contents/MacOS/soffice info:sal.osl.condition:59030:1:sal/osl/unx/conditn.cxx:74: osl_createCondition(): 0x7fc96257d3a0 info:sal.osl:59030:1:sal/osl/unx/module.cxx:314: osl_getModuleURLFromAddress: /Users/julien/lo/libreoffice/instdir/LibreOfficeDev.app/Contents/Frameworks/libuno_cppu.dylib.3 info:sal.osl:59030:1:sal/osl/unx/module.cxx:314: osl_getModuleURLFromAddress: /Users/julien/lo/libreoffice/instdir/LibreOfficeDev.app/Contents/Frameworks/libuno_cppuhelpergcc3.dylib.3 info:sal.osl.condition:59030:1:sal/osl/unx/conditn.cxx:74: osl_createCondition(): 0x7fc96273b610 info:sal.osl.condition:59030:1:sal/osl/unx/conditn.cxx:74: osl_createCondition(): 0x7fc96273b4b0 info:sal.osl.pipe:59030:1:sal/osl/unx/pipe.cxx:243: new pipe on fd 15 '/tmp/OSL_PIPE_501_SingleOfficeIPC_880fd1d5bf168a495522ffb52bc994' info:sal.osl:59030:1:sal/osl/unx/module.cxx:314: osl_getModuleURLFromAddress: /Users/julien/lo/libreoffice/instdir/LibreOfficeDev.app/Contents/Frameworks/libuno_cppu.dylib.3
forgot to say that to be sure there's no remaining cruft, I removed my local repo and gave a new try from scratch --enable-64-bit #--with-system-odbc --enable-werror --enable-python=internal --enable-debug --enable-dbgutil --enable-crashdump --enable-dependency-tracking --enable-online-update #--enable-ext-mariadb-connector #--without-system-mariadb #--enable-bundle-mariadb --with-lang=en-US it fr de es pt ru cs hu pl da sv el sk is nl #--with-lang=ALL --without-junit --with-myspell-dicts
After having updated again my LO sources, it works now! I wonder if it could be thanks to: http://cgit.freedesktop.org/libreoffice/core/commit/?id=514f9fc675eb3d116adb4b0a33c19c3d6e99e98b CppunitTest_sw_ooxmlexport5: fix Fedora 22 alpha build 09:41 <@dtardon> vmiklos, maybe it's a regression in libxml2. "Fix XPath '//' optimization with predicates (Nick Wellnhofer)" in NEWS looks suspicious So tweak the XPath not to use // for now. Indeed, on my other machine, pc Debian x86-64 with master sources updated this morning, it failed to launch with the same message on console. After having updated my local repo (with this quoted commit included), it was ok. Perhaps it's a wrong lead since I don't know why a failing test would cause this. Moreover, even after the last local repo update, check tests failed on my Mac with this: Assertion failed: (nMapNum == 0 || std::abs(n) < std::numeric_limits<long>::max() / nMapNum / nDPI), function ImplLogicToPixel, file /Users/julien/lo/libreoffice/vcl/source/outdev/map.cxx, line 379. Error: a unit test failed, please do one of: export CPPUNITTRACE="lldb --" # for interactive debugging on OS X export VALGRIND=memcheck # for memory checking and retry using: make CppunitTest_sw_globalfilter so I don't know what to think. Anyway, let's put this one WFM, thank you all for your feedback! :-)
(In reply to Julien Nabet from comment #13) > Perhaps it's a wrong lead since I don't know why a failing test would cause > this. So in the past a plain "make" did not return with a zero exit code for you? That would have been a very vital information to track down the root of your problem. If a plain "make" (vs. e.g. "make check") returns with a non-zero exit code (even due to a failing unit test) the generated instdir/ tree is, in general, in an indeterminate state and cannot be used reliably.