Bug 94117 - Windows 64-bit and executable name of 64-bit build of ghostscript -- gswin64c.exe
Summary: Windows 64-bit and executable name of 64-bit build of ghostscript -- gswin64c...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
(earliest affected) Master
Hardware: Other Windows (All)
: medium normal
Assignee: Mike Kaganski
Whiteboard: target:6.4.0
Depends on:
Reported: 2015-09-11 00:31 UTC by V Stuart Foote
Modified: 2019-10-21 03:31 UTC (History)
5 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 V Stuart Foote 2015-09-11 00:31:41 UTC
LibreOffice for 64-bit Windows may require some additional work for executables (external helpers) that have both 32-bit and 64-bit implementations.

The Ghostscript 64-bit installation goes to C:\Program Files\gs\gs9.16\ as does the 32-bit build. However, the 64-bit executable is named "gswin64c.exe", the 32-bit is named "gswin32c.exe"

So while users can (and must) adjust their PATH environment to include external helpers--i.e. convert, pstoedit, and the Ghostscript installs--there is a hardcoded executable name of gswin32c in the source at:


So, no way to run the 64-bit build of ghostscript that folks with 64-bit Windows would otherwise be installing. And, without gswin32c on PATH (have to test if symlink will work) the EPS gets mangled.

So while this affect only handling of EPS, wonder what other gems might be hidden within #ifdef WNT flagged stanzas.
Comment 1 V Stuart Foote 2015-09-11 04:57:49 UTC
So setting a Windows symlink with:

mklink gswin32c.exe "C:\Program Files\gs\gs9.16\bin\gswin64c.exe"

does provide a work around for this specific issue on Windows. 

So one can use 64-bit builds of Ghostscript, Imagemagick, and pstoedit as needed with 64-bit Windows build of LibreOffice--with PATH tweaks.
Comment 2 MM 2015-09-11 11:42:27 UTC
Would you prefer something like this ?

#ifdef WNT64 // or whatever win 64 bit is called in LO
  OUString fileName("gswin64c" EXESUFFIX);
#elseif WNT
  OUString fileName("gswin32c" EXESUFFIX);
  OUString fileName("gs" EXESUFFIX);
Comment 3 Robinson Tryon (qubit) 2015-11-03 05:54:24 UTC
(In reply to V Stuart Foote from comment #1)
> So setting a Windows symlink with:
> mklink gswin32c.exe "C:\Program Files\gs\gs9.16\bin\gswin64c.exe"
> does provide a work around for this specific issue on Windows. 

Hmm... a longer-term solution would be ideal.
Status -> NEW
Comment 4 QA Administrators 2016-11-08 11:57:46 UTC Comment hidden (obsolete)
Comment 5 V Stuart Foote 2016-11-08 14:34:17 UTC
Still an issue, 32 & 64-bit LO builds looking for the 32-bit command name, e.g. gswin32c for ghostscript, and without a symlink to the 64-bit command the LO function fails.


But, I've not come across any other specific instances of naming commands different 32-bit vs 64-bit impacting LO, and work around continues to work.
Comment 6 QA Administrators 2017-11-09 07:42:52 UTC Comment hidden (obsolete)
Comment 7 V Stuart Foote 2017-11-10 18:36:03 UTC
Issue remains, and seems we need to test for _WIN64 here and use the '"gswin64c" EXESUFFIX,' for RenderAsBMPThroughHelper [1].

Things were complicated with a MS security change in handling of SYMLINKs [2][3]

On 64-bit Windows we now have to make a hard link [4] creating gswin32c.exe link to the 64-bit gswin64c.exe to be able to use Ghostscript to render the EPS to canvas with RenderAsBMPThroughGS [5]


[2] https://social.technet.microsoft.com/Forums/en-US/0eefc57f-8c01-450a-a1cf-8e2894a951d9/symbolic-link-type-changed

[3] https://technet.microsoft.com/library/security/ms15-020

[4] That is:
1. navigate to bin directory of the 64-bit gs install, e.g. C:\Program Files\gs\g9.21\bin

2. hard link with "mklink /h gswin32c.exe gswin64c.exe"

before a simple symlink with mklink sufficed, now have to use the hardlink.

[5] https://opengrok.libreoffice.org/xref/core/filter/source/graphicfilter/ieps/ieps.cxx#370
Comment 8 QA Administrators 2018-11-12 03:41:28 UTC Comment hidden (obsolete)
Comment 9 V Stuart Foote 2018-11-12 23:14:39 UTC
Issue remains, 64-bit build of gs 9.25 installs its executable of gswin64c.exe, while 32-bit is built as gswin32c.exe

We call gswin32c.exe, for both 32-bit and 64-bit Windows builds, to handle EPS import in the ieps filter [1], but that is the only place.

Making a hardlink for the gswin32c.exe gainst the 64-bit build still works for this corner case.

[1] https://opengrok.libreoffice.org/xref/core/filter/source/graphicfilter/ieps/ieps.cxx#393
Comment 10 V Stuart Foote 2019-10-13 21:32:35 UTC
@Mike, I know we test for 64-bit when building but can we test when running so these one off 32bit/64bit differing command names can be selected?
Comment 11 Mike Kaganski 2019-10-14 05:28:49 UTC
(In reply to V Stuart Foote from comment #10)
This does not test for OS platform; rather, it tests both executable names, because on Win64, either one (or both) can be present, and it would not be best to limit ourselves to gswin64c.

Could you please test the patch below?

Comment 12 Commit Notification 2019-10-14 11:07:33 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":


tdf#94117: try gswin64c if gswin32c failed

It will be available in 6.4.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.
Comment 13 V Stuart Foote 2019-10-21 03:31:34 UTC
The gs executable gswin64c.exe is now being found, no longer need to do a static link rename to gswin32c.exe. The ieps() filter is correctly handing EPS images.


Version: (x64)
Build ID: 546e6c359e96a2e7f5aab7c158c7e843be6c8957
CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: GL; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded