- 2019.04.23 21:04 "Re: [Tiff] TIFFWriteScanLine - buffers to RAM before flushing to disc?", by Kemp Watson
-
2019.04.23 21:24 "Re: [Tiff] TIFFWriteScanLine - buffers to RAM before flushing to disc?", by Bob Friesenhahn
- 2019.04.24 11:28 "Re: [Tiff] TIFFWriteScanLine - buffers to RAM before flushing to disc?", by Paul Hemmer
- 2019.06.20 15:31 "Re: [Tiff] TIFFFdOpen crash on Windows 64bit", by ZdPo Ster
- 2019.04.24 15:51 "Re: [Tiff] TIFFWriteScanLine - buffers to RAM before flushing to disc?", by Paul Hemmer
2019.06.20 15:31 "Re: [Tiff] TIFFFdOpen crash on Windows 64bit", by ZdPo Ster
Thanks for reply. Finally it seems I found solution ;-): Problem is present in version 4.0.10[1], but it is fixed in current code - I guess commit 59eb3517[2] fixed it. I was sure I was linking my test code to gitlab version, but it turn out I was wrong.
Unfortunately also gitlab code (TIFFGetVersion()) returns "LIBTIFF, Version 4.0.10". Maybe LIBTIFF, Version 4.0.11dev or something like that (git describe --abbrev=4) would help...
If I understand it correctly released 4.0.10 version used tif_unix.c in windows cmake build => it does no work for me. Current code use tif_win32.c and it works.
Best regards,
[1] https://download.osgeo.org/libtiff/tiff-4.0.10.zip [2] https://gitlab.com/libtiff/libtiff/commit/59eb35172f8dc9a46469ad0e4877f9c88ab796cd
On Thu, 20 Jun 2019 at 14:43, Bob Friesenhahn <bfriesen@simple.dallas.tx.us> wrote:
> On Thu, 20 Jun 2019, ZdPo Ster wrote:
>
> > Hello,
> >
> > When I try to use TIFFFdOpen on Windows 10 64bit - but it crash. In
> > attachment there is my testing code. I found this problem when I was > > testing poppler[1] utility pdftoppm (to convert pdf to tif).
> >
> > IMO this is relevant to Bug 1941 - Win64 problem with tif_win32.c's
> > TIFFOpen() use of HANDLE (w/patch)[3],
>
> I should point out that it is possible to use tif_unix.c under Windows > as well. It appears that your code assumes use of tif_win32.c. It
> may well be that tif_unix.c was used in the libtiff build. I see that > the Autoconf configure script offers the option --disable-win32-io to
> disable use of Windows I/O but it is possible that it might also be > disabled by a test (e.g. if it thought that the host_os is Cygwin).
>
> Regardless, usually one should check for errors at each step, which
> your code does not do.
>
> It is safer to use TIFFClientOpen(), but then I/O wrapper functions > need to be supplied, and this can take a few tries to implement
> perfectly.
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt