hp2xx is failing to run on Windows 7. I believe it is this line in hp2xx.c
that fails:
if ((pg->td = tmpfile()) == NULL)
The temp file IS actually created (this is NOT the problem with creating the
file in the root dir), but I believe W7 is returning a less than perfect
return causing the failure. Anyway, we are trying to make a temporary fix and
recompile. We are finding it very difficult to recompile with the GUI
environment or makefiles. Can anyone provide guidance on a fix or more precise
recompile instructions on a windows compile of hp2xx?
Thanks
Tom de Castro
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Compiling hp2xx in mingw required some changes if I remember right. I had to
make a makefile for it. My version had png support but not tiff. It's old
though like two years. I'll probably write a replacement tmpdir(). Really a
big issue is we should have temporary files first in temp tmp tmpdir if
possible. I'll look into it this weekend.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On my version of W7 the tmpdir() function does obey the temp variable for
location for creating the temp files. In fact, it does successfully create the
files, but still apparently returns an error to the program.
Anyway, I downloaded mingw C compiler and make utility. If you have a makefile
that is close, I would apprectiate the help.
Thanks
Tom
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I started writing a tmpfile() replacement. I didn't have a chance yet to look
into why hp2xx might be failing on Windows 7 x64. What you can do is try
changing the source to use hp2xx.$$$ as your tempfile. Refer to hp2xx.c:659
HPGL_to_TMP().
For now I've uploaded the modified source I use and included the libpng/zlib
binaries for png support.
You should be able to compile from rxvt or the command prompt, however hp2xx
has output problems in rxvt.
My make was successful, I used tdm build of gcc to test the make.
gcc.exe(tdm-1)4.5.1Copyright(C)2010FreeSoftwareFoundation,Inc.
Thisisfreesoftware; see the source for copying conditions. There is NOwarranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I only had one warning for deprecated jmpbuf, you can ignore that
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for uploading the test version; I don't need this package but I was
curious anyway. I built this test version with the official mingw32 gcc 4.5.2
but first I installed libpng 1.4.5 and zlib 1.2.5 (which I wanted to do
anyway). I then compiled with the included png support modules but linked with
my self-built zlib and libpng binaries. I received the same warning about
`jmpbuf' when compiling png.c. It passed the tests essentially. I am using
Windows XP SP3.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have downloaded your files and I am attempting a compile with tif support. I
have to_tif.c but it is referencing "tiffio.h", which I can't seem to find
anywhere. Any suggestions?
Thanks
tom
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have the Gnuwin tiff package installed (version 3.8.2) but you may want to
build the latest version (3.9.4) yourself. The development header files are
included in the Windows installer version of the Gnuwin package. Then you
could edit the Makefile to build against the Gnuwin tiff binaries.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am also having troubles getting hp2xx to run on win7 64 bit (hp2xx --
opening temporary file: Invalid argument). Unfortunately I am not very
familiar with c++ and compiling, so I'm asking whether you were so kind as to
provide the working hp2xx.exe or giving a brief description what you changed
and how you compiled it to make it run under win7.
thanks,
claus
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
got a bit of time today to look into this and I successfully compiled it using
the source and description provided by raysatiro (BIG THANKS). did the png
support, works; also got the jmpbuf warning but ignored this. in hp2xx.c,
changed
line 693 from
if((pg->td=tmpfile())==NULL)
to
if((pg->td=fopen("hp2xx.$$$","w+b"))==NULL)
. so.. works now for me too.
thanks for this thread guys.
claus
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Using a fixed file name for a temp file can raise security concerns but maybe
you should submit this to the package author anyway. His name is Martin Kröker mk@daveg.com or martin@ruby.chemie.uni-freiburg.de . I am not clear about
your build platform details or your Windows 7 (?) version.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I found some more info on the tmpfile() issue: (see "Win7 and C:\ "), and
especially , where a "tmpfile() replacment for Windows" was implemented, which
might solve this issue. Martin Kröker seems to be quite busy, but might
continue his work on hp2xx later this year.
The problem as I understand it is that MS interprets the ANSI C99 standard to
say that tmpfile should create the file in the root directory `C:\'. I am
afraid the burden is on the programmer to be aware of this issue, including
for Windows XP limited users, not just Vista and Windows 7. You may want to
download a copy of glibc version 2.14 and look at <libio stdio.h=""> . You
probably compiled using mingw <stdio.h> . If the author publishes an updated
version you could start a new thread as this one is getting stale.</stdio.h></libio>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem as I understand it is that MS interprets the ANSI C99 standard
to say that tmpfile should create the file in the root directory `C:\'.
No, that isn't strictly correct.
Microsoft's tmpfile() implementation has always been -- to say the least
-- "odd". It will usually prefix a single backslash to the generated unique
file name. However, this does not imply that the file should be created in
the root (C:) directory; according to the MS documentation on MSDN, it
indicates that the file may be safely created in the current working
directory, but the onus is placed on the programmer, to adjust the returned
path name accordingly.
I am afraid the burden is on the programmer to be aware of this issue,
including for Windows XP limited users, not just Vista and Windows 7.
That burden applies for all MS-Windows versions, from the dawn of MS-
Windows time, not just to XP and later. There are many -- myself among them --
who have been bitten by this quirky behaviour, and consider it to be broken.
However, it is "as documented", so technically it isn't a bug; we just have to
live with and work around it.
You may want to download a copy of glibc version 2.14 and look at
<libio stdio.h="">. You probably compiled using mingw <stdio.h></stdio.h></libio>
Well, that's standard behaviour for MinGW -- it uses Microsoft's runtime
services by design. A study of the glibc implementation (as used by
Linux?) may be instructive, but it's hardly relevant in the MinGW context.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I do not believe the problem is because windows is trying to create the
tempfile in the root directory c:. My tests have shown that the temp file is
created in the current working directory. The file is created even when the
program fails. I think the OS is just returning a less then perfect return
code and triggering the error. I suspect we may need to switch to tmpfile_s()
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can you post your hp2xx binary? I think your modification for fixed temp file
name is fine. Since you made a change to hp2xx.c, is your fix generic for all
file types? If not can you tell me how you managed MinGW to compile? For some
reason "mingw32-make all" gives me an error. Here is the output:
all -Wextra -Wno-unused-parameter hp2xx.c, ...) failed.
make (e=2): The system cannot find the file specified.
mingw32-make: *** Error 2
I was not sure how to point mingw32-make.exe to the sources directory and
execute "all" command, so I just dumped it with the dlls to this directory and
executed it. But again, I got an error. I tried putting cp.exe into the
directory as well, but I got the same thing.
Did you get any response from Martin Kröker?
Any help would be appreciated.
Thanks,
CodeMajster
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the end I used MS Visual Studio 2010 and managed to convert Visual C 6.00
project files included in makes directory. I had to re-add all header files to
the project. I got lots of errors but this time they have been descriptive
enough. Since, I only needed conversion to emf, I removed all "to_" files that
caused errors and compiled without any problems. These files (to_pdf, to_png,
to_tif, to_x11) seem to reference unix or other dependencies and I did not
want to spend time on resolving/fixing them.
Claus,
Your solution to replace tmpfile() function with a specific file works great.
I'm running hidden hp2xx program from .NET app. The location of the temp file
can be easily controlled by setting working directory of the process (works
with working directory field of the windows shortcuts too).
Thanks again,
CodeMajster
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I confirmed that my compiled executable can translate from .hgl to .png, .jpg and .tif without any obvious issues.
I used the following external libraries:
libgw32c-0.4
jpeg-6b-4
zlib-1.2.3
tiff-3.8.2-1
libpng-1.2.37
I simply searched for "gnuwin32 libjpeg", "gnuwin32 libtiff" etc. to get those libraries and headers, and merged them into my MinGW folder to get past the build errors. Inelegant, but it appears to have worked.
I used hp2xx-3.4.4-2 as the baseline before adding the "cairo" modifications for overriding tmpfile().
My MinGW installation was mingw-get-inst-20120426 and I allowed it to grab the latest libs on installation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
hp2xx is failing to run on Windows 7. I believe it is this line in hp2xx.c
that fails:
if ((pg->td = tmpfile()) == NULL)
The temp file IS actually created (this is NOT the problem with creating the
file in the root dir), but I believe W7 is returning a less than perfect
return causing the failure. Anyway, we are trying to make a temporary fix and
recompile. We are finding it very difficult to recompile with the GUI
environment or makefiles. Can anyone provide guidance on a fix or more precise
recompile instructions on a windows compile of hp2xx?
Thanks
Tom de Castro
Compiling hp2xx in mingw required some changes if I remember right. I had to
make a makefile for it. My version had png support but not tiff. It's old
though like two years. I'll probably write a replacement tmpdir(). Really a
big issue is we should have temporary files first in temp tmp tmpdir if
possible. I'll look into it this weekend.
Jay,
On my version of W7 the tmpdir() function does obey the temp variable for
location for creating the temp files. In fact, it does successfully create the
files, but still apparently returns an error to the program.
Anyway, I downloaded mingw C compiler and make utility. If you have a makefile
that is close, I would apprectiate the help.
Thanks
Tom
I started writing a tmpfile() replacement. I didn't have a chance yet to look
into why hp2xx might be failing on Windows 7 x64. What you can do is try
changing the source to use hp2xx.$$$ as your tempfile. Refer to hp2xx.c:659
HPGL_to_TMP().
For now I've uploaded the modified source I use and included the libpng/zlib
binaries for png support.
You should be able to compile from rxvt or the command prompt, however hp2xx
has output problems in rxvt.
Read the README-FIRST.txt and png14/README.txt
[http://sourceforge.net/projects/getgnuwin32/files/getgnuwin32/test%20builds/]
(http://sourceforge.net/projects/getgnuwin32/files/getgnuwin32/test%20builds/)
My make was successful, I used tdm build of gcc to test the make.
I only had one warning for deprecated jmpbuf, you can ignore that
You should be able to compile from rxvt or the command prompt, however hp2xx
has output problems in rxvt.
Read the README-FIRST.txt and png14/README.txt
[http://sourceforge.net/projects/getgnuwin32/files/getgnuwin32/test%20builds/]
(http://sourceforge.net/projects/getgnuwin32/files/getgnuwin32/test%20builds/)
Thanks for uploading the test version; I don't need this package but I was
curious anyway. I built this test version with the official mingw32 gcc 4.5.2
but first I installed libpng 1.4.5 and zlib 1.2.5 (which I wanted to do
anyway). I then compiled with the included png support modules but linked with
my self-built zlib and libpng binaries. I received the same warning about
`jmpbuf' when compiling png.c. It passed the tests essentially. I am using
Windows XP SP3.
jay,
I have downloaded your files and I am attempting a compile with tif support. I
have to_tif.c but it is referencing "tiffio.h", which I can't seem to find
anywhere. Any suggestions?
Thanks
tom
I have the Gnuwin tiff package installed (version 3.8.2) but you may want to
build the latest version (3.9.4) yourself. The development header files are
included in the Windows installer version of the Gnuwin package. Then you
could edit the Makefile to build against the Gnuwin tiff binaries.
thanks Allan. I just found tiff-3.7.2-src.zip. This matches the version of the
tiff dll we are using on XP
(libtiff3.dll ver .7.2.1953).
Anyway, I was able to compile and link a new hp2xx.exe that works for us on
W7.
Thanks all
Tom
hello shinysurfer, hello all,
I am also having troubles getting hp2xx to run on win7 64 bit (hp2xx --
opening temporary file: Invalid argument). Unfortunately I am not very
familiar with c++ and compiling, so I'm asking whether you were so kind as to
provide the working hp2xx.exe or giving a brief description what you changed
and how you compiled it to make it run under win7.
thanks,
claus
hey all,
got a bit of time today to look into this and I successfully compiled it using
the source and description provided by raysatiro (BIG THANKS). did the png
support, works; also got the jmpbuf warning but ignored this. in hp2xx.c,
changed
line 693 from
to
. so.. works now for me too.
thanks for this thread guys.
claus
Using a fixed file name for a temp file can raise security concerns but maybe
you should submit this to the package author anyway. His name is Martin Kröker
mk@daveg.com or martin@ruby.chemie.uni-freiburg.de . I am not clear about
your build platform details or your Windows 7 (?) version.
Thanks for your response. I just dropped Martin Kröker a few lines about this
issue.
As I said, it works for me at least, but it would be a pity if this great tool
would just stop working because of this.
Of course I am still interested in finding a better way to solve this issue,
maybe I'll take a look at tmpfile() when I got some time.
I used make and mingw on win7 x64 by the way.
hello all,
I found some more info on the tmpfile() issue: (see "Win7 and C:\ "), and
especially , where a "tmpfile() replacment for Windows" was implemented, which
might solve this issue. Martin Kröker seems to be quite busy, but might
continue his work on hp2xx later this year.
greetings, claus
http://msdn.microsoft.com/en-
us/library/x8x7sakw%28v=vs.80%29.aspx
http://lists.cairographics.org/archives/cairo/2007-December/012561.html
http://cgit.freedesktop.org/cairo/commit/?id=4fa46e3caaffb54f4419887418d8d0ea
39816092
The problem as I understand it is that MS interprets the ANSI C99 standard to
say that tmpfile should create the file in the root directory `C:\'. I am
afraid the burden is on the programmer to be aware of this issue, including
for Windows XP limited users, not just Vista and Windows 7. You may want to
download a copy of glibc version 2.14 and look at <libio stdio.h=""> . You
probably compiled using mingw <stdio.h> . If the author publishes an updated
version you could start a new thread as this one is getting stale.</stdio.h></libio>
No, that isn't strictly correct.
Microsoft's tmpfile() implementation has always been -- to say the least
-- "odd". It will usually prefix a single backslash to the generated unique
file name. However, this does not imply that the file should be created in
the root (C:) directory; according to the MS documentation on MSDN, it
indicates that the file may be safely created in the current working
directory, but the onus is placed on the programmer, to adjust the returned
path name accordingly.
That burden applies for all MS-Windows versions, from the dawn of MS-
Windows time, not just to XP and later. There are many -- myself among them --
who have been bitten by this quirky behaviour, and consider it to be broken.
However, it is "as documented", so technically it isn't a bug; we just have to
live with and work around it.
Well, that's standard behaviour for MinGW -- it uses Microsoft's runtime
services by design. A study of the glibc implementation (as used by
Linux?) may be instructive, but it's hardly relevant in the MinGW context.
I do not believe the problem is because windows is trying to create the
tempfile in the root directory c:. My tests have shown that the temp file is
created in the current working directory. The file is created even when the
program fails. I think the OS is just returning a less then perfect return
code and triggering the error. I suspect we may need to switch to tmpfile_s()
Hi all,
Claus,
Can you post your hp2xx binary? I think your modification for fixed temp file
name is fine. Since you made a change to hp2xx.c, is your fix generic for all
file types? If not can you tell me how you managed MinGW to compile? For some
reason "mingw32-make all" gives me an error. Here is the output:
D:\Temp\hp2xx-3.4.4\sources>mingw32-make all
gcc -ggdb3 -DPNG -I../png14/include -c -O3 -Wall -Wextra -Wno-unused-parameter
hp2xx.c
process_begin: CreateProcess(NULL, gcc -ggdb3 -DPNG -I../png14/include -c -O3
-W
all -Wextra -Wno-unused-parameter hp2xx.c, ...) failed.
make (e=2): The system cannot find the file specified.
mingw32-make: *** Error 2
I was not sure how to point mingw32-make.exe to the sources directory and
execute "all" command, so I just dumped it with the dlls to this directory and
executed it. But again, I got an error. I tried putting cp.exe into the
directory as well, but I got the same thing.
Did you get any response from Martin Kröker?
Any help would be appreciated.
Thanks,
CodeMajster
Hello all,
In the end I used MS Visual Studio 2010 and managed to convert Visual C 6.00
project files included in makes directory. I had to re-add all header files to
the project. I got lots of errors but this time they have been descriptive
enough. Since, I only needed conversion to emf, I removed all "to_" files that
caused errors and compiled without any problems. These files (to_pdf, to_png,
to_tif, to_x11) seem to reference unix or other dependencies and I did not
want to spend time on resolving/fixing them.
Claus,
Your solution to replace tmpfile() function with a specific file works great.
I'm running hidden hp2xx program from .NET app. The location of the temp file
can be easily controlled by setting working directory of the process (works
with working directory field of the windows shortcuts too).
Thanks again,
CodeMajster
FWIW I was able to compile hp2xx w/MinGW on my Windows 7 machine using the same workaround as was proposed in
http://cgit.freedesktop.org/cairo/commit/?id=4fa46e3caaffb54f4419887418d8d0ea39816092
to get past the tmpfile() issue.
I confirmed that my compiled executable can translate from .hgl to .png, .jpg and .tif without any obvious issues.
I used the following external libraries:
I simply searched for "gnuwin32 libjpeg", "gnuwin32 libtiff" etc. to get those libraries and headers, and merged them into my MinGW folder to get past the build errors. Inelegant, but it appears to have worked.
I used hp2xx-3.4.4-2 as the baseline before adding the "cairo" modifications for overriding tmpfile().
My MinGW installation was mingw-get-inst-20120426 and I allowed it to grab the latest libs on installation.