Latest versions, for example tinderbox: tree: MASTER tinderbox: pull time 2012-01-04 07:42:19 tinderbox: git sha1s core:308b282a8e6a5e6b8bc60b16f7d293051d8ecb7f binfilter:3699b9935500443746fc1d520b274dd54bc458b3 dictionaries:7ef74e0d0fa57cc7eeb34226072b4183f2475308 help:87c767e7ff586490378235635fec44b1d8e9de4e 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.
Same problem with buildname: Win-x86@7-MinGW tree: MASTER pull time 2012-01-23 08:36:33 git sha1s core:7735b09b5e10e366ffb3a156790316ea0ccfa0a0 binfilter:258ba2fb484d5e1bb4a3aca3991b3b66ea915a10 dictionaries:9eed77596448296e58b0ab5c329d51ddaebb1ca6 help:f06126233b70fd4d7bbe13ff38d5b6026528b9c7 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.
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.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9019ccb42398b714666f045693e503780d9746ab soffice.exe must not link against sal3.dll (might fix fdo#44489)
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"?
(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.