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. Surely we should use some other way to find out the executable's pathname and not rely on what happens to be in argv (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:
User Profile Reset: No
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 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 22.214.171.124
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?).
This worked fine including 126.96.36.199.
In 188.8.131.52 it started to crash.
Between LO 184.108.40.206 and 220.127.116.11 it gave an error when trying to access the central configuration.
In 18.104.22.168 it started to crash again.
The latest crash was introduced by the following commit:
author Caolán McNamara <firstname.lastname@example.org> 2017-06-11 20:56:30 +0100
committer Caolán McNamara <email@example.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":
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:
Affected users are encouraged to test the fix and report feedback.