Bug 688832 - wrong GS_LIB_DEFAULT location (32bit Windows)
Summary: wrong GS_LIB_DEFAULT location (32bit Windows)
Status: NOTIFIED WONTFIX
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Build Process (show other bugs)
Version: 8.54
Hardware: PC Windows XP
: P4 normal
Assignee: Russell Lang
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-08-08 16:50 UTC by charles
Modified: 2008-12-19 08:31 UTC (History)
0 users

See Also:
Customer:
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description charles 2006-08-08 16:50:46 UTC
I'm not a developer, so forgive me if my terms are off.  From doc/use.htm it
seems GS_LIB_DEFAULT is the last resort location for the GS_LIB search path
hardcoded into the .EXE and .DLL

It is clear that in all 3 of gswin32.exe, gswin32c.exe and gsdll32.dll this path
is the legacy path of: c:/gs/gs8.54/lib;c:/gs/gs8.54/Resource;c:/gs/fonts
However, the default install location has been changed from c:/gs/... to
C:/Program Files/gs/...

I think the last resort path for GS_LIB hardcoded into these files should be the
same as the default path used by the installer.

I discovered this because the installer for this version is also broken.   see
bug 688831

The combination of these two bugs mean the default install of this version on a
fresh install of WindowsXP is broken from the command line.
Comment 1 charles 2006-08-08 17:03:05 UTC
I meant to include the error I see:

C:\Program Files\gs\gs8.54\bin>gswin32c.exe
GPL Ghostscript 8.54: Can't find initialization file gs_init.ps.
Comment 2 Ralph Giles 2006-08-14 17:10:03 UTC
This may be a duplicate of bug 688831.

Russell Lang has done an updated build which should fix the problem. Assigning
to him for confirmation and closure once the issue is fixed in the repository.
Comment 3 Russell Lang 2006-08-14 18:16:49 UTC
It isn't possible to set GS_LIB_DEFAULT correctly during the build process.  For
English versions of Windows, ghostscript gets installed to "c:\Program
Files\gs".  The installer queries Windows for the local path, and it is
different for other languages.  In French I think it is "c:\Programme".
Comment 4 charles 2006-08-14 19:55:50 UTC
Ralph, not exactly a duplicate.  Though I did discover it because of the other
bug.  

Russell, I'm not familiar with other language localized versions of Windows.  Do
they change the environment variable names, too?  If not you could build it to
use the %ProgramFiles% environment variable to get the local path for
"C:\Program Files" at runtime and append the rest of the default install path to
that.

Comment 5 SaGS 2006-08-15 02:08:09 UTC
Note that %ProgramFiles% does not exist on Win9X, so cannot rely on it.

I haven't look into the code, so I am not sure what changes this implies, but 
here's another idea:

- At build-time, let GS_LIB_DEFAULT empty (unless it is explicitely set 
  in the make's command line);
- At run-time, during the initialization, check GS_LIB_DEFAULT. If empty,
  set it taking into consideration the executable's location. On Windows, 
  this means calling GetModuleFileName() then doing some string surgery.
Comment 6 Russell Lang 2006-12-08 14:02:13 UTC
Yes, the "Program Files" directory name changes depending on the language.
If the installer is correct, then there is no problem because it sets
GS_LIB in the registry with the location where ghostscript is installed.
I'm closing this bug as WONTFIX.
The original problem of the GPL installer setting the AFPL entry
(bug 688831) has been fixed.