Bug 44489 - MinGW: Will not launch
Summary: MinGW: Will not launch
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
(earliest affected)
Master old -3.6
Hardware: Other All
: medium major
Assignee: Stephan Bergmann
URL: http://dev-builds.libreoffice.org/dai...
Whiteboard: target:3.6.0
Depends on:
Blocks: mabMinGW
  Show dependency treegraph
Reported: 2012-01-05 03:06 UTC by Rainer Bielefeld Retired
Modified: 2012-04-27 06:25 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Bielefeld Retired 2012-01-05 03:06:21 UTC
Latest versions, for example
tinderbox: tree: MASTER
tinderbox: pull time 2012-01-04 07:42:19
tinderbox: git sha1s

will not launch for me. I double click soffice.exe or any other application, will not start without any message.
Olser versions in parallel folders work without problems.
Comment 1 Rainer Bielefeld Retired 2012-01-23 10:22:01 UTC
Same problem with
buildname: Win-x86@7-MinGW
tree: MASTER
pull time 2012-01-23 08:36:33
git sha1s

I see soffice.exe / soffice.bin for a short time in WIN Task Manager, then it disappears again. Start from command line also will not work.
Comment 2 Stephan Bergmann 2012-03-19 02:51:02 UTC
What does running soffice.exe from within depends.exe (<http://www.dependencywalker.com/>), incl. profiling of sub-processes, report?

With my recent local master MinGW cross build on Linux (which does not yet work for different reasons, anyway), I noticed an odd dependency of soffice.exe on sal3.dll (due to desktop/Executable_soffice.mk mentioning sal in gb_Executable_add_linked_libs,soffice, which appears to be there since desktop has been gbuild'ified).  That looks completely broken, as soffice.exe shall set up the necessary environment (PATH) for soffice.bin to be able to load the URE libs like sal3.dll.  soffice.exe itself should neither be able to load sal3.dll nor should it depend on it.  What makes me wonder is how such an soffice.exe from any Windows build (both native MSVC and cross-compiled MinGW) can ever work.
Comment 3 Not Assigned 2012-03-19 06:26:08 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "master":


soffice.exe must not link against sal3.dll (might fix fdo#44489)
Comment 4 Rainer Bielefeld Retired 2012-04-26 10:35:31 UTC
Modified status / assignee due to facts

@Stephan Bergmann:
May be we can close this one, please see "Bug 47548 - [MinGW] build will not launch, libpixman-1-0.dll missing"?
Comment 5 Stephan Bergmann 2012-04-27 06:25:38 UTC
(In reply to comment #4)
> May be we can close this one, please see "Bug 47548 - [MinGW] build will not
> launch, libpixman-1-0.dll missing"?

Yes, from the comments in bug 47548 it follows that this issue here is no longer relevant.