2015.09.15 10:41 "[Tiff] "bad file descriptor" if operating with lseek on filedescriptor given by TIFFFileno (Windows only)", by Andreas Romeyke

2015.09.15 16:10 "Re: [Tiff] "bad file descriptor" if operating with lseek on filedescriptor given by TIFFFileno (Windows only)", by Bob Friesenhahn

On 15/09/2015 10:33 AM, Bob Friesenhahn wrote:

I second Bob's suggestion. For completeness of the mailing list, I'd point out again that this is a known problem:

The problem might not be that one.

Sure, but the symptoms sure sound like it. One of the problems with tif_win32.c is that TIFFFileno() returns a Windows "HANDLE" type as opposed to an int fd that can be used for lseek(). So if he managed to cross compile in such a ma

I am not aware that any of us has tested cross-compilation to WIN32 or WIN64 from a Linux system and verified that everything works. I have only verified compilation and tests under MSYS shell with MinGW (as well as Cygwin) on a Windows 7 system.

If he managed to cross-compile using tif_win32.c, then using the result of TIFFFileno() with lseek() *must* be a problem because it can never work.

Someone previously changed configure so that it uses tif_win32.c by default under Windows. If TIFFFileno() returns a "HANDLE" type, then the using code would need to know about that and use appropriate measures. This is in addition to the existing problem that the "HANDLE" type does not always fit in the space it is stored in.

Bob
--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/