Re: [Tiff] Strange results after MR 678

2025-10-18 Thread Olivier Paquet via Tiff 
Hi Larry,

Le mar. 23 sept. 2025, à 16 h 47, Larry Gritz via Tiff 
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
___
Tiff mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/tiff

Re: [Tiff] Strange results after MR 678

2025-09-24 Thread Larry Gritz via Tiff 
Update: I think I've reproduced the problem at earlier commits as well, so I 
don't think it's really the commit I cited.
I now believe that the machine that was exhibiting the problem had multiple 
installs of both libtiff and other libraries.
After ensuring that this is no longer the case, the symptoms appear to have 
evaporated, so... nothing to see here, folks. Sorry to bother you.


> On Sep 23, 2025, at 4:19 PM, Olivier Paquet  wrote:
> 
> Le mar. 23 sept. 2025, à 17 h 57, Larry Gritz  > a écrit :
>> 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?
>  
> I rebuilt with jpeg support and did not get the error you did. I'm using 
> libjpeg-turbo 3.1.1. But I now notice that you're going through the wrong 
> code path entirely. The message you get is not for old-style jpeg but rather 
> in the new jpeg reading code. I have no idea how you're getting there with 
> that file.
> 
> Olivier

--
Larry Gritz
[email protected]





___
Tiff mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/tiff

Re: [Tiff] Strange results after MR 678

2025-09-23 Thread Olivier Paquet via Tiff 
Le mar. 23 sept. 2025, à 17 h 57, Larry Gritz  a écrit :

> 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?
>

I rebuilt with jpeg support and did not get the error you did. I'm using
libjpeg-turbo 3.1.1. But I now notice that you're going through the wrong
code path entirely. The message you get is not for old-style jpeg but
rather in the new jpeg reading code. I have no idea how you're getting
there with that file.

Olivier
___
Tiff mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/tiff

Re: [Tiff] Strange results after MR 678

2025-09-23 Thread Bob Friesenhahn via Tiff 
Due to library dependencies, it is possible for more than one jpeg 
library to be in the process address space at the same time. If you are 
able to run 'ldd' on the binary, then it may reveal that.


If there is more than one library which provides the same symbol in the 
process, then perhaps one of them will be used without a duplicate 
symbol being reported.


Bob

On 9/23/25 16:56, Larry Gritz via Tiff wrote:

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 
 wrote:


Hi Larry,

Le mar. 23 sept. 2025, à 16 h 47, Larry Gritz via Tiff 
 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

___
Tiff mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/tiff

Re: [Tiff] Strange results after MR 678

2025-09-23 Thread Larry Gritz via Tiff 
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  wrote:
> 
> Hi Larry,
> 
> Le mar. 23 sept. 2025, à 16 h 47, Larry Gritz via Tiff  > 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