Description: Try to run soffice.exe from Command Prompt (this is specific to Windows, obviously) using instdir\program\soffice.exe. The soffice.exe and soffice.bin processes run for a short while but exit then without doing anything. Using an absolute pathname C:\where\ever\instdir\program\soffice.exe works. Not sure how long this has been broken. But surely the intent is that using just instdir\program\soffice.exe should work? (Like it does when run from a Cygwin shell in mintty, and on Linux.) The problem seems to be that getIniFileName_Impl() in sal/rtl/bootstrap.cxx does not return a file: URL but a relative pathname, huh. And that is because osl_getExecutableFile() does not return an absolute filename, but what happens to be in argv[0]. Surely we should use some other way to find out the executable's pathname and not rely on what happens to be in argv[0] (Also, sal_detail_initialize() takes a plain char argv, not a wchar_t one, and thus is fairly broken already when LibreOffice is installed in a pathname that isn't expressible in the system codepage. We should use GetModulePathNameW(NULL,...). Steps to Reproduce: . Actual Results: . Expected Results: . Reproducible: Always User Profile Reset: No Additional Info: .
I mean GetModuleFileNameW().
(The same happens if you try to run instdir\program\soffice.com.)
The code in osl_createCommandArgs_Impl() looks like it would be doing the right thing, even uses CommandLineToArgvW( GetCommandLineW(), &nArgs ), and has the comment /* Replace argv[0] with its absolute path */ But that gets used only if osl_setCommandArgs() is called with a zero argc. And we apparently call osl_setCommandArgs() with whatever happens to be in the args and argv passed to main(). I think we shold always ignore any argc and argv passed to main() and just let that osl_createCommandArgs_Impl() do its job. Or is there some detail I am missing?
confirming with Win10 x64 and LO 6.1.5.2
Likely regression after https://git.libreoffice.org/core/+/515d2579d305a6127c6c194319a58eac62437e33 - where possibly I actually enabled the calls to SetDllDirectoryW and SetSearchPathMode, which task is to exclude some paths (including current directory) from search; possibly they weren't called in old code for some reason (located in a different library in newer Windows?).
https://gerrit.libreoffice.org/70844
This worked fine including 4.3.0.4. In 4.4.0.3 it started to crash. Between LO 5.0.0.5 and 5.4.0.3 it gave an error when trying to access the central configuration. In 6.0.0.3 it started to crash again. The latest crash was introduced by the following commit: https://cgit.freedesktop.org/libreoffice/core/commit/?id=00657aef09d854c74fb426a935a3e8b1fc390bb0 author Caolán McNamara <caolanm@redhat.com> 2017-06-11 20:56:30 +0100 committer Caolán McNamara <caolanm@redhat.com> 2017-07-21 08:20:50 +0100 migrate to boost::gettext
Oh, it crashes even? Is that in a non-developer build?
(In reply to Tor Lillqvist from comment #8) > Oh, it crashes even? Is that in a non-developer build? Both in local debug and official release builds.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/c650217cc543080928a26de4bfc07ebb0be5c6ca%5E%21 tdf#124776: don't use SearchPathW to get full path of executable It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.