Um, maybe libjpeg vs libjpeg-turbo could be responsible here? I have old-style JPEG enabled when building libtiff. But I think this failing configuration is one where I'm using jpeg-turbo instead of libjpeg. They're supposed to be compatible, but maybe there is a subtle difference in behavior here?
> On Sep 23, 2025, at 2:09 PM, Olivier Paquet <[email protected]> wrote: > > Hi Larry, > > Le mar. 23 sept. 2025, à 16 h 47, Larry Gritz via Tiff <[email protected] > <mailto:[email protected]>> a écrit : >> I suppose this could end up finding a different zlib (or some other mutual >> dependency?) that's on the system than it would without this policy. But I'm >> at a loss to explain how that would lead to this particular failure and >> error message, and no other change or failures. >> >> Maybe somebody sees this and it rings a bell or has some insight I've missed? > > The error message you get is emitted after a check on the return value of > jpeg_read_header(). I suspect you're picking up a different jpeg library and > its behavior is different for this particular file. You should be able to > verify that by comparing the cmake output before and after the change. Also > compare with the jpeg library being used on your other machines where you > don't see the issue. > > Someone who knows more about JPEG might have a better insight as to the > underlying reason of the different behavior (ie. the file being bad, the > library being broken, libtiff misusing it, etc). For what it's worth, my own > build spits out: "Old-style JPEG compression support is not configured". > > Olivier > -- Larry Gritz [email protected]
_______________________________________________ Tiff mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/tiff
