OS2 World Community Forum
OS/2, eCS & ArcaOS - Technical => Programming => Topic started by: Dariusz Piatkowski on January 29, 2022, 04:29:49 am
-
I decided to take a stab at building an updated version of GSView (because the pswrite device is no longer present in our ghostscript 9.18 release and the latest GSView verison seems to have it hard-coded instead of picking the device name up from the gvpm.ini file and using that).
Anyways...couple of small tweaks to the makefile, but I'm getting stumped by a reference to two other makefiles: one for common objects and the other is a GSView version mak (auto-updates the GSView header that contains the version info).
I've attached the makefile here, and I'm seeing the following error:
...
[G:\code\source\os2\gsview-5.0]\usr\bin\make
makefile:85: ".\src\common.mak": No such file or directory
makefile:86: ".\src\gvcver.mak": No such file or directory
makefile:174: *** missing separator (did you mean TAB instead of 8 spaces?). St
op.
...
which is a result of the following lines in the main makefile:
...
#################################################################
# Common
include "$(SRC)common.mak"
include "$(SRC)gvcver.mak"
...
And yet, from a CLI where I am executing make from I can certainly do a "dir" and both of those files are certainly there:
[G:\code\source\os2\gsview-5.0]dir .\src\*mak
The volume label in drive G is OS2.
The Volume Serial Number is 45B6:75C3.
Directory of G:\code\source\os2\gsview-5.0\src
11-17-07 4:14p 2,409 0 a--- bzlibmsc.mak
5-28-11 12:21p 5,677 0 a--- common.mak
1-17-12 9:26p 23,686 0 a--- gvc.mak
1-28-22 10:21p 1,802 0 a--- gvcver.mak
So what am I tripping over here?
Is this a OS/2 vs Linux path separator issue?
For what it's worth I tried the "/" vs "\" with no difference.
Thanks!
-
Ahh...fixed a couple more issues in the main makefile (spaces instead of TABs), now it looks like i'm getting a bit further, but still hitting this:
[G:\code\source\os2\gsview-5.0]g:\code\tools\vslick\os2\gcc_build.cmd
g:\code\tools\vslick\os2\gcc_build.cmd
makefile:85: ".\src\common.mak": No such file or directory
makefile:86: ".\src\gvcver.mak": No such file or directory
make.exe: *** No rule to make target `".\src\gvcver.mak"'. Stop.
Exited
gvcver.mak is short:
# GSview version
GSVIEW_VERSION=50
GSVIEW_DOT_VERSION=5.0
GSVIEW_DATE=2022-01-28
$(OD)gsvver.h: $(ECHOGSV) $(SRC)gvcver.mak
$(ECHOGSV) -w $(OD)gsvver.h "/* gsvver.h - automatically generated by gvcver.mak */"
$(ECHOGSV) -a $(OD)gsvver.h -x 23 "define GSVIEW_VERSION " $(GSVIEW_VERSION)
$(ECHOGSV) -a $(OD)gsvver.h -x 23 "define GSVIEW_DOT_VERSION " -x 22 $(GSVIEW_DOT_VERSION) -x 22
$(ECHOGSV) -a $(OD)gsvver.h -x 23 "define GSVIEW_DATE " -x 22 $(GSVIEW_DATE) -x 22
$(ECHOGSV) -a $(OD)gsvver.h -x 23 "define GSVIEW_DOCPATH " -x 22 $(GSVIEW_DOCPATH) "/gsview-" $(GSVIEW_DOT_VERSION) "/" -x 22
$(ECHOGSV) -a $(OD)gsvver.h -x 23 "define GSVIEW_ETCPATH " -x 22 $(GSVIEW_ETCPATH) "/gsview/" -x 22
So you can tell that it simply auto-creates gsvver.h here, based on the variables that are defined in the gvcver.mak.
Looks to me like make.exe doesn't know what to do with that makefile though...
-
Try doing "SET MAKESHELL=sh.exe" and retry
-
Try doing "SET MAKESHELL=sh.exe" and retry
Thanks Dave, but that did not work.
No sense spending huge time on this...I get the idea behind this, but this software isn't going to go through numerous future changes. Heck, all I need is to change the printer device name here. I'm going to build that gsvver.h file manually and take that include out of the makefile.
-
Hmm...so much for that idea...LOL, b/c I now have the same issue with common.mak, and as best as I can tell there is only a single target in there, that being:
...
#################################################################
# Cleanup
commonclean:
-$(RM) $(CLEAN1)
-$(RM) $(CLEAN2)
-$(RM) $(CLEAN3)
...
Alright...time to get edumacated further on the inner depths of 'make'...LOL!
-
I have some vague memory of gsview using nmake rather than make.... perhaps try running nmake
-
Paul,
I have some vague memory of gsview using nmake rather than make.... perhaps try running nmake
Thank you (Thumbs-Up), because somehow I missed the following in the Readme.htm doc:
...
To compile GSview for OS/2 you need IBM NMAKE.EXE and EMX/GCC 0.9d. To create the GSview online help you need the IBM toolkit. Copy srcos2/os2.mak to Makefile and edit COMPBASE and EMXPATH as required. Type 'nmake'
...
Which now of course explains why there were multiple "!if" statements in the makefile and which GCC make.exe was choking on.
I had earlier assumed that the EMX requirements would be fulfilled by the current GCC RPM package releases, I say this because in the \usr\... tree there are multiple references to EMX objects. I do have exmrt.0.9d-5.oc00.i386 installed here, however I do not have the emxrt-devel.0.9d-5.oc00.i386 one.
Specifically, the EMX stuff I see is:
Directory of G:\usr\bin
8-26-21 9:13a 11,118 124 a--- emxaout.exe
8-26-21 9:13a 22,883 124 a--- emxbind.exe
8-26-21 9:13a 46,263 124 a--- emxexp.exe
8-26-21 9:13a 25,286 124 a--- emximp.exe
8-26-21 9:13a 6,289 124 a--- emxload.exe
8-26-21 9:13a 97,002 124 a--- emxomf.exe
8-26-21 9:13a 13,880 124 a--- emxomfar.exe
8-26-21 9:13a 42,417 124 a--- emxomfld.exe
8-26-21 9:13a 3,773 124 a--- emxomfstrip.exe
8-26-21 9:13a 4,260 124 a--- emxstack.exe
8-26-21 9:13a 9,209 124 a--- emxtsf.exe
11 file(s) 282,380 bytes used
...and as best as I can tell these all came from the libc-devel-0.1.9-1.oc00.pentium4 RPM package.
So in order to avoid future self-made problems :'( , what should I set COMPBASE and EMXPATH to?
Right now I have the makefile set to use:
...
COMPBASE=$(DRIVE)\usr
EMXPATH=$(DRIVE)\usr
...
Alright, so a little bit of un-do needed to get this moving...
-
I found the short readme I wrote, it shows I built Ver. 5 with gcc 4.4.7:
This is a quick build of gsview2 5.0. I needed a copy of gsview2 but the link for gsview2 4.9 off of the gsview webpage
was dead so I pulled the source and built it. This has had limited testing, just enough to see a few PDF and PS files opened.
Most of the testing has been with Paul Smedley's 9.04 version of Ghostscript. This version was built with KLIBC rather
thank EMX so requires libc065.dll. I built it with -static-libgcc so it should not require gcc447.dll but was built with
GCC 4.4.7. It was built with -Zhigh-mem to use high memory so it may not run on older kernels without high-mem support.
Attaching the diff I created... I probably would have put it in the zip I uploaded too.
-
I did the build so long ago that I did not think of putting this up when I created a github account.
https://github.com/abwillis/gsview5.0
-
Hi Andi,
I did the build so long ago that I did not think of putting this up when I created a github account.
https://github.com/abwillis/gsview5.0
Thank you sir!
I pulled the master ZIP file, going to start working with that instead of where I ended up.
Looking at the os2.mak from your distro, it does need IBM's nmake.exe though, right?
Otherwise it uses the GCC compiler I think.
EDIT
====
It built with nmake.exe and GCC, "straight outta the box"...yey!!!
I am running into a problem printing, debugging that right now, although the error msg I'm seeing doesn't point to anything obvious:
gsdllname=G:\usr\lib\gsdll2.dll
option file=y:\tmp\gv8iV0as
input file=y:\tmp\gvkeoHRl
Option file contents:
-I"G:\usr\share\ghostscript\9.18\resource\init;g:\usr\share\fonts\default\ghostscript"
-dNOPAUSE
-sDEVICE=ps2write
-dDEVICEXRESOLUTION=600
-dDEVICEYRESOLUTION=600
-dDEVICEWIDTH=5100
-dDEVICEHEIGHT=6600
-sOutputFile="\\spool\PSCRIPTB"
-dNOPLATFONTS
-sFONTPATH="g:\psfonts;g:\usr\share\fonts\default\ghostscript"
Trying to load G:\usr\lib\gsdll2.dll
Loaded Ghostscript DLL
GPL Ghostscript 9.18 (2015-10-05)
Copyright (C) 2015 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
GPL Ghostscript 9.18: **** Could not open the file \\spool\PSCRIPTB .
**** Unable to open the initial device, quitting.
gsapi_init_with_args returns -100
gsapi_exit returns 0
DosFreeModule returns 12
I think they key part there is the "Unable to open the initial device, quitting.", just don't quite know yet what that means...
Thanks!
-
I have used ps2write when writing to a file but I use os2prn print to a printer.
I did find this bug going back to gsview 4.6:
https://bugs.ghostscript.com/show_bug.cgi?id=687542
It states there was a patch for OS/2 for this issue, I haven't looked closer at this point... I came across it as I've been searching for a change that I dimly recall for the Ghostscript include path that I can't locate.
-
Hi Andi,
I have used ps2write when writing to a file but I use os2prn print to a printer.
I did find this bug going back to gsview 4.6:
https://bugs.ghostscript.com/show_bug.cgi?id=687542
It states there was a patch for OS/2 for this issue, I haven't looked closer at this point... I came across it as I've been searching for a change that I dimly recall for the Ghostscript include path that I can't locate.
Meanwhile, I have been using 'pswrite' with the gs9.04, but discovered that this device is no longer available in gs9.18, which is what started me on this "mission"...lol
'os2prn' is a GDI device, which means that gs will build a bitmap and send that off to the printer, reason why that's a much slower process than firing off a PS file to a PS-capable printer (which my Brother HL-5470DW is).
I've spent a few hours today plugging away at this...multiple combinations later along with a few additional debug statements haven't helped though.
I'm going to take the captured GSView content and control files and convert to a CLI input into gs, will try that next to see what happens there instead.
Thanks for sharing that BUG reference. Russell Lang's last update is 2004, but I don't know how to tell if the patch he mentions is actually in our version of 9.18. By the looks of it, I doubt it, because attempting to reference a device through that name produces the same error here.
-
So a brief update: I opened a new incident for BWW in their Ghostscript project, see https://github.com/bitwiseworks/ghostscript-os2/issues/2 (https://github.com/bitwiseworks/ghostscript-os2/issues/2)
The question I posed there is: based on the current OS2 codebase, what is the expected way of specifying a printer output device?
Specifically, I provided the details on how the "\\spool\printer_name" doesn't work, nor are any other various permutations of it.
In comparison to what I was able to do with 9.04 (where this worked) it would appear to me we have some kind of a functional regression here.
In the meantime I'm going to start a separate thread in our Applications forum to understand how folks are actually using GS for printing? Maybe very few people actually do? LOL
-
how folks are actually using GS for printing? Maybe very few people actually do? LOL
Group 1: people who use OS/2
Group 2: people who print
Group 3: people who use gs for printing
Group 4: people who try out a recent gs version
I'm just in the first group and had been in the others as well. Good luck with finding someone who matches. ;-)
-
Well, I'm in all four groups, plus:
Group 5: people who use gs for merging pdf's and adding text to pdf's
-
As well as me :)
-
Hi Dariusz,
Meanwhile, I have been using 'pswrite' with the gs9.04, but discovered that this device is no longer available in gs9.18, which is what started me on this "mission"...lol
From the readme of my last gs build:
"4) GSView requires manual changes to the Ghostscript Include statement (Options->Advanced Configuration) - I used 'c:\gs\gs9.15\resource\init;C:\GS\gs9.15\lib;C:\GS\gs9.15\Resource\font;C:\GS\fonts;c:\psfonts;' to make it work
5) the pswrite device that GSView uses to print has been removed from Ghostscript 9.x. To print using ghostview, modify x:\os2\gvpm.ini and replace all cases of pswrite with ps2write"
This worked for me at the time.
Cheers,
Paul
-
Hi Paul,
From the readme of my last gs build:
"4) GSView requires manual changes to the Ghostscript Include statement (Options->Advanced Configuration) - I used 'c:\gs\gs9.15\resource\init;C:\GS\gs9.15\lib;C:\GS\gs9.15\Resource\font;C:\GS\fonts;c:\psfonts;' to make it work
5) the pswrite device that GSView uses to print has been removed from Ghostscript 9.x. To print using ghostview, modify x:\os2\gvpm.ini and replace all cases of pswrite with ps2write"...
Oh, believe me, I went down that road long time ago. In fact you may not remember, but you had previously tried to helpe me with this (getting your port of GS9.15 printing) and we could not get it to work.
I have a SINGLE occurence of gvpm.ini file on my partition, any changes I make are always reflected in it. Yet, GSView still tosses an error.
That is what caused me to use GS9.04, until Lucide 1.5.0GA (which is about late 2019 I think) came out, so I switched to that nearly fulltime, but like I said earlier, sometimes I still have printing problems there.
Anyways, appreciate the response nonetheless!