Signed-off-by: Michael Meeks <michael.meeks@suse.com>
Signed-off-by: Petr Mladek <pmladek@suse.cz>

Improves the commit d066f7e4 that
fixed crash when printing the bugdoc from i#103958

...in case osl_getProcessWorkingDir fails (e.g., if it has been unlinked).

Keep track of position of previous sorting column and use it to decide whether to duplicate invisible new sort column

so let's make the sal_intXY ugliness even a bit more ugly

This avoids comparison of raw values (ScDPItemData) during the 2nd sort.
Comparison of raw values can be expensive especially when the item sets mostly
consist of string values.

The old code relied on the order of initializing global static variables across
compilation units, which failed for MinGW cross compilation.  Cleaned up.

...as soffice.exe creates the proper environment (PATH) for soffice.bin to be
able to load URE libs like sal3.dll, so soffice.exe itself should neither be
able to load nor depend on sal3.dll (and does not depend on anything exported by
it, anyway).

It is unclear to me how this ever worked (which it presumably did?) with any
Windows build, either native MSVC or cross-compiled MinGW.  (Maybe MSVC builds
do not record a dependency from soffice.exe to sal3.dll, noting that the former
does not import anything from the latter?)

Or should it be --without-helppack-integration that affects it? Or
both? Why do we need both these switches?  And what does that
irritating "integration" thing mean again? Does
--without-helppack-integration mean "yes, do build helppacks, but
don't integrate them"?

libxslt in Fedora mingw packages depends on it.