bugGNU Octave - Bugs: bug #46301, Ghostscript Search Path is...

 
 

bug #46301: Ghostscript Search Path is misconfigured in MXE build

Submitter:  None
Submitted:  Mon 26 Oct 2015 04:02:37 PM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Inaccurate Result
Status:  Fixed Assigned to:  lostbard
Originator Name:  James R. Phillips Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 4.0.0
Operating System:  * Microsoft Windows Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 06 Nov 2015 11:43:32 AM UTC, comment #8: 

I guess the real thing to do would be just set the env variable on starting octave

John Donoghue <lostbard>
Group Member
Fri 06 Nov 2015 11:24:42 AM UTC, comment #7: 

Its the same way on my fedora box - most of the search paths it has do not even exists, they are just places it will look for resources if the do exists.

John Donoghue <lostbard>
Group Member
Fri 06 Nov 2015 11:22:01 AM UTC, comment #6: 

%rom% is the compiled in resources within the ghostscript binary.

/usr/share is based on wherever mxe-octave is really installed so should work where ever it is installed.

ghostscript sets up those paths as search paths regardless of whether they actually exist or not, so the patch should have changed ghostscript to look at paths that may exists rather than ones that were never going to exist.

in addition, as mentioned in comment 2, you can also set the GS_DEFAULT_LIB environment variable and override the defaults if wanted.

John Donoghue <lostbard>
Group Member
Thu 05 Nov 2015 09:20:11 PM UTC, comment #5: 

Checking the fix:


> gs -h
...
Search path:
   %rom%Resource/Init/ : %rom%lib/ :
   /usr/share/ghostscript/9.16/Resource/Init :
   /usr/share/ghostscript/9.16/lib :
   /usr/share/ghostscript/9.16/Resource/Font :
   /usr/share/ghostscript/fonts : /usr/share/fonts/default/ghostscript :
   /usr/share/fonts/default/Type1 : /usr/share/fonts/default/TrueType :
   /usr/lib/DPS/outline/base


So it seems to me that this fix replaced a set of irrelevant
directories by another set of irrelevant directories...

The search path should include
<install_path>\Octave-4.0.0\share\ghostscript\9.16\lib
but <install_path> is known only in the installation time, not at the building time of ghostscript. Maybe it is %rom%lib/?

Can someone give an example in which octave output depends on
gs search path, and if the search path is wrong, the output will be wrong?


Avinoam Kalma <avinoam>
Group Member
Thu 05 Nov 2015 11:12:58 AM UTC, comment #4: 

Marking as fixed and closed

John Donoghue <lostbard>
Group Member
Tue 03 Nov 2015 01:03:16 AM UTC, comment #3: 
John Donoghue <lostbard>
Group Member
Thu 29 Oct 2015 09:24:04 PM UTC, comment #2: 

Looking at the makefile we use for ghostscript, there is a make variable GS_LIB_DEFAULT that contains the paths.

It should be possible to change it.

ghostscript will also use the environment variable GS_LIB_DEFAULT which will override the compiled in settings on run time.

John Donoghue <lostbard>
Group Member
Thu 29 Oct 2015 08:07:10 PM UTC, comment #1: 

Looking at them in my build, all of them except ghostscript/9.16/lib do not exist.


The %rom% ones are compiled into the executable.

John Donoghue <lostbard>
Group Member
Mon 26 Oct 2015 04:02:37 PM UTC, original submission:  

I am working with a MXE build of 64-bit octave 4.0.0 on windows. The Mercurial changeset id for tip of mxe-octave is:

4049:d882a15af20e

After installation using the nsis installer on 64-bit Windows 7, when running the ghostscript interpreter installed with Octave,

gs --help yields in part:

Search path:
   %rom%Resource/Init/ : %rom%lib/ :
   /home/e008456/tmp/mxe-octave/usr/x86_64-w64-mingw32/share/ghostscript/9.16/Resource/Init :
   /home/e008456/tmp/mxe-octave/usr/x86_64-w64-mingw32/share/ghostscript/9.16/lib :
   /home/e008456/tmp/mxe-octave/usr/x86_64-w64-mingw32/share/ghostscript/9.16/Resource/Font :
   /home/e008456/tmp/mxe-octave/usr/x86_64-w64-mingw32/share/ghostscript/fonts :
   /home/e008456/tmp/mxe-octave/usr/x86_64-w64-mingw32/share/fonts/default/ghostscript :
   /home/e008456/tmp/mxe-octave/usr/x86_64-w64-mingw32/share/fonts/default/Type1 :
   /home/e008456/tmp/mxe-octave/usr/x86_64-w64-mingw32/share/fonts/default/TrueType :
   /usr/lib/DPS/outline/base : /usr/openwin/lib/X11/fonts/Type1 :
   /usr/openwin/lib/X11/fonts/TrueType

It is clear that most of these paths are hard-wired to the Linux system I did the build on (those beginning with /home/e008456) rather than the system the build is installed on.

I have not verified that there is any loss of e.g. available fonts, but I strongly suspect that ghostscript is missing some resources that were built and installed, but are not on the search path.

Anonymous

 

(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

 

Carbon-Copy List
  • -email is unavailable- added by avinoam (Posted a comment)
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    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 group members can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-11-05 lostbard StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2015-11-03 lostbard StatusIn Progress Ready For Test
    2015-10-31 lostbard Item GroupNone Inaccurate Result
        StatusNone In Progress
        Assigned toNone lostbard

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code