Saw that with Server installation of Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID: 6b0de40-0bc4ff4-ca7e6f5-9125509-ce71330)]" (111111) During Installation I saw a message Runtime Error. Programm: C:\LOM11111\program\unopkg.bin This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. After <ok> I was able to terminate the installation, and it seems to run more or less without bigger problems Related or not? Since Version 2011-11-09 a DOS Window keeps open as long as the Master LibO is running. I can't remember to have seen that before. Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110928 Firefox/7.0.1 SeaMonkey/2.4.1
Looks similar to "Bug 34045 - LibreOffice 3.3 runtime error during installation and startup failure with fatal error", "Bug 31764 - Unopkg add failed with pyUno code" - Reported with Bug Submission Assistant -
Confirmed with LibO-dev 3.5.0 Build ID: 3f170f2-533e3c6-ca7e6f5-9125509-ce71330 [master~2011-11-13_04.17.45...] on WinXP 32b See also attached screenshot 'fdo#42826.png' Related: 'Bug 42914 - Terminal (command) window is opened when launching any executable'
Created attachment 53529 [details] Screenshot 'fdo#42826.png'
Confirmed with Master 2011-11-13 23-17-53 from http://dev-builds.libreoffice.org/daily/Voreppe_Win32_Tinderbox/master/ I found a bug in Calc but i don't know if i should report this bug or wait for an other version without install problem ?
Crash during install is a blocker.
I' can't tell might be that it's only a nonsense message, but of course, it's inacceptable for the release
unopkg is called when registering extensions. It would be interesting to find what extension causes this.
(In reply to comment #4) > I found a bug in Calc but i don't know if i should report this bug or wait for > an other version without install problem ? @GerardF: please, file the bug. This bug causes that one or few extensions are not installed. It should not affect the function of the application => the bug will be most likely valid even when we fix this.
Adding some Windows experts.
Created attachment 53832 [details] Screenshot with more details Hmm, I have disabled all extensions during installation and got the crash as well. I have clicked a link to get more details, see the attached screenshot. I am not sure if it has any use.
I wonder if it might be related to the new Andras's installer. It might call unopkg in a not-yet-installed system or so. Alternatively it might be related to Stefan's clean up of the 3-layer structure.
what might give insight is to run the whole installation process from within the Depends tool (with attaching to spawned sub-processes enabled)
Stack trace at crash: [bla bla related to the error dialog] ... kernel32.dll!_RaiseException@16() + 0x52 bytes msvcr90.dll!_CxxThrowException(void * pExceptionObject=0x0012fa64, const _s__ThrowInfo * pThrowInfo=0x4966beb8) Line 161 C++ > cppuhelper3MSC.dll!cppu::loadSharedLibComponentFactory(const rtl::OUString & rLibName={...}, const rtl::OUString & rPath={...}, const rtl::OUString & rImplName={...}, const com::sun::star::uno::Reference<com::sun::star::lang::XMultiServiceFactory> & xMgr={...}, const com::sun::star::uno::Reference<com::sun::star::registry::XRegistryKey> & xKey={...}, const rtl::OUString & rPrefix={...}) Line 487 + 0x9b bytes C++ 0255d8ce() cppuhelper3MSC.dll!cppu::ORegistryFactoryHelper::createModuleFactory() Line 886 + 0x43 bytes C++ ... The interesting part is in cppuhelper3MSC.dll!cppu::loadSharedLibComponentFactory() Line 487 + 0x9b bytes, where the debugger shows that it is trying to load "file:///C:/Program/LibO-dev%203.5/program/../program/binaryurp.uno.dll" , i.e. binaryurp.uno.dll from the "program" folder even if it is in the URE\bin folder. A fallout from the Basis layer removal perhaps? Anyway, if I move the binaryurp.uno.dll from URE\bin to program, unopkg runs without problems. (Or copy, but just having it in program should work fine.) How to fix this then in the build, I don't know. Just have the installer put binaryurp.uno.dll in program instead of URE\bin? That probably would work fine. Or ask whoever it was who did the Basis layer removal if he has any idea how to properly fix this?
Ah, comment #11 already guessed at this;)
The problem apparently is that Repository.mk maps binaryurp to UNOLIBS_URE, but solenv/gbuild/WNT_INTEL_{GCC,MSC}.mk both map UNOLIBS_URE to OOO in gb_Library_LAYER, so that the binaryurp.component file will contain a uri attribute that points to the program directory instead of URE\bin on Windows.
So should UNOLIBS_URE be mapped to URELIB then instead? How comes LO itself apparently works fine even with the wrong mapping?
"So should UNOLIBS_URE be mapped to URELIB then instead?" Looks like it. solenv/gbuild/platform/unxgcc.mk maps all of PLAINLIBS_URE, RTVERLBS, UNOLIBS_URE, and UNOVERLIBS to URELIB, for example. "How comes LO itself apparently works fine even with the wrong mapping?" soffice.bin itself does not normally need the URP bridge (except for live deployment of extensions, which are installed into an additional uno process).
> soffice.bin itself does not normally need the URP bridge But what about all the other dlls (UNO components?) affected by this, how are they then found? Or aren't they, but nobody has tried to use a master build in such a way that they would have been needed?
So would this work? diff --git a/solenv/gbuild/platform/WNT_INTEL_MSC.mk b/solenv/gbuild/platform/WNT_INTEL_MSC.mk index 7a56245..22b8392 100644 --- a/solenv/gbuild/platform/WNT_INTEL_MSC.mk +++ b/solenv/gbuild/platform/WNT_INTEL_MSC.mk @@ -432,13 +432,13 @@ gb_Library_PLAINLIBS_NONE += \ gb_Library_LAYER := \ $(foreach lib,$(gb_Library_OOOLIBS),$(lib):OOO) \ $(foreach lib,$(gb_Library_PLAINLIBS_NONE),$(lib):OOO) \ - $(foreach lib,$(gb_Library_PLAINLIBS_URE),$(lib):OOO) \ + $(foreach lib,$(gb_Library_PLAINLIBS_URE),$(lib):URELIB) \ $(foreach lib,$(gb_Library_PLAINLIBS_OOO),$(lib):OOO) \ $(foreach lib,$(gb_Library_RTLIBS),$(lib):OOO) \ - $(foreach lib,$(gb_Library_RTVERLIBS),$(lib):OOO) \ - $(foreach lib,$(gb_Library_UNOLIBS_URE),$(lib):OOO) \ + $(foreach lib,$(gb_Library_RTVERLIBS),$(lib):URELIB) \ + $(foreach lib,$(gb_Library_UNOLIBS_URE),$(lib):URELIB) \ $(foreach lib,$(gb_Library_UNOLIBS_OOO),$(lib):OOO) \ - $(foreach lib,$(gb_Library_UNOVERLIBS),$(lib):OOO) \ + $(foreach lib,$(gb_Library_UNOVERLIBS),$(lib):URELIB) \ gb_Library_FILENAMES :=\ $(foreach lib,$(gb_Library_TARGETS),$(lib):$(gb_Library_SYSPRE)$(lib)$(gb_Library_PLAINEXT)) \ I see that unxgcc.mk contains a gb_Library_LAYER mapping for gb_Library_PLAINLIBS_NONE, but WNT_INTEL_MSC.mk doesn't. Should it? Also, if this gb_Library_LAYER thing is supposed to be the same everywhere, why can't it be factored out into just one of the .mk files?
Re comment 18, most (if not all) of the URE modules that contain .component files (like cppuhelper, javaunohelper, stoc) are still dmake-based, using the working solenv/inc/settings.mk COMPONENTPREFIX_* mechanism.
Maybe Björn or Michael Stahl can give input on comment 19.
ah, ok, yes the fact that so much still uses dmake probably is the key here. OK, so I will make the change from comment #19 and see what happens.
i, for one, have no idea why the layer thing maps everything to OOO on windows currently, comment #19 looks entirely plausible to me. please check if the MinGW stuff has the same problem?
*** Bug 43461 has been marked as a duplicate of this bug. ***
Should be fixed now with: commit a35140f245d774745b806ef12346aa77f0256395 Author: Tor Lillqvist <tlillqvist@suse.com> Date: Fri Dec 2 11:41:33 2011 +0200 Fix library layer mapping for the URELIB ones, fdo#42826