Add a New Comment (Rich Markup)
Comment Type & Canned Response: None None > Multiple Canned Responses Fixed in development Crash with no stack trace Already fixed in newer version Fixed in stable Bad description Bad description and crash Bad stack trace Obsolete version Duplicate and not fixed Duplicate and needs more info Duplicate and fixed Need info and old
( Jump to the original submission )
There is already a warning which has been added to "makeinst-script.sh" by John Donoghue. In MXE Octave 3.8.2-4, it says:
MessageBox MB_OK|MB_ICONEXCLAMATION "Octave should not be installed to a destination folder containing spaces. Please select another destination."
http://hg.octave.org/mxe-octave/diff/8c11c5a1a939/makeinst-script.sh
This hasn't been fixed, but it has been worked around. The NSIS installer now places everything in a directory tree without spaces.
Should we add a warning to the NSIS installer if a user attempts to install in a path with spaces?
Otherwise, I think we've done enough to solve this and can close this report.
I checked in the following changeset for mxe-octave to cross compile ghostscript on i686-mingw systems and also allow it to be built for native builds.
http://hg.octave.org/mxe-octave/rev/f2503a486cce
Building seems to work for me. I'm building and testing an nsis installer now.
It would certainly be easier if ghostscript can be cross compiled. But if not, then we could also have Octave's installer run the ghostscript installer or arrange for the some other way to include ghostscript in the installer we distribute.
There are some instructions about cross compiling on the ghostscript web pages, so perhaps it's possible. I'll see whether I can make that work. If I can do it by hand, I'm fairly sure we can embed that knowledge in some Make rules.
I think the first question is whether ghostscript can be cross-compiled using the MXE framework. Philip alluded to jwe saying this was difficult. Only if we can clear this first hurdle do we get to start thinking about how it might be installed in a directory without spaces.
The ghostscript command, which looks fine in the m-file, disappears into the C++ drawnow command and eventually into gl2ps. It might be that someone is stripping the double quote character. In this case we could try replacing spaces with escaped spaces
strrep (x, ' ', '\ ')
I find coding for Windows annoying so, unless compensated, I won't be working on this issue.
Keep in mind that Octave isn't ready for ghostscript >=9.09 yet: Bug #41141. Just a reminder because gs914w64.exe was linked.
How should we fix this problem for the builds we will be distributing?
I would prefer to cross compile ghostscript from sources just like all the other packages we are distributing, but if that's not possible, should we include a file like http://downloads.ghostscript.com/public/gs914w64.exe in the installer and have the Octave installer launch the ghostscript installer? Or should we do that step in advance so that the files are already unpacked and installed in the proper locations inside the Octave installer package?
<quote> I think I could even system("gs") with no problem </quote>
That is true as long as C:\Program Files\gs\gs9.07\bin is in Window's search PATH. After all, system(<COMMAND>) simply invokes Window's own program launcher that can very well cope with spaces in path names.
IIRC JWE pointed out that building ghostscript in MXE isn't quite straightforward. So we'll have to live with this for Windows systems until a fix comes along. (AFAIR there were also other programs that were troublesome in MXE - fig2dev or pstoedit?)
I ran into this exact problem when testing on Win XP for the first time this weekend. Ghostscript is required for certain output formats, is not included with the mxe build, and is not particularly clear how to install it or set it up so that Octave can find it. And as Rik stated, the default installation path is under C:/Program Files/gs.
I think I observed that Octave could call other commands on PATH even when a "Program Files" directory was in PATH, and I think I could even system("gs") with no problem.
This is only a problem for me on Windows XP, not Linux. I did a default install of ghostscript which, of course, puts installation in 'c:\\program files' which has a space in the name. When I try to print something it can't find the ghostcript program. The error message indicates that it didn't process the name correctly.
'c:\program' is not recognized as an internal or external command, operable program or batch file.
Octave appears to correctly wrap the print pipeline command in _fltk_print_.m with double quotes, but for some reason they aren't respected on Windows platforms. I used a keyboard statement in _fltk_print_.m to see the command that is generated before it is passed to drawnow() C++ code. The command looks correct.
pipeline = { [1,1] = "c:\program files\gs\gs9.09\bin\gswin32c.exe" -dQUIET -dNOPAUSE -dBATCH -dSAFER -sDEVICE=p dfwrite -dEmbedAllFonts=true -dOptimize=true -dEPSCrop -sPAPERSIZE=letter -dFIXEDMEDIA -sOutputFile= "junk.pdf" C:\DOCUME~1\Rik\LOCALS~1\Temp\oct-49.ps - & rm C:\DOCUME~1\Rik\LOCALS~1\Temp\oct-49.ps }
As a quick work around, I just installed to a path without spaces in the name.
(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)
Attach Files: Comment:
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Only project members can vote.
Please enter the title of George Orwell's famous dystopian book (it's a date):
Follow 3 latest changes.
Copyright © 2022 Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team. Source Code
Powered by Savane 3.9