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: http://opengrok.libreoffice.org/xref/core/filter/source/graphicfilter/ieps/ieps.cxx#369 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.
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.
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); #else OUString fileName("gs" EXESUFFIX); #endif
(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
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.6 or 5.2.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20161108
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. http://opengrok.libreoffice.org/xref/core/filter/source/graphicfilter/ieps/ieps.cxx#384 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.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
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] =-ref-= [1]https://opengrok.libreoffice.org/xref/core/filter/source/graphicfilter/ieps/ieps.cxx?a=true&h=369#390 [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
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. =-ref-= [1] https://opengrok.libreoffice.org/xref/core/filter/source/graphicfilter/ieps/ieps.cxx#393
@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?
(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? https://gerrit.libreoffice.org/80748
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1c85b047b6cfdbae010f0967e9c9f99f7a101d32 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: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
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. =-testing-= Version: 6.4.0.0.alpha1+ (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