Re: windowscodecs: Workaround libtiff bug when it defines toff_t as 32-bit for 32-bit builds. Take 2.
There's a TIFF_VERSION define that seems to have been renamed to TIFF_VERSION_CLASSIC in 4.0.
It doesn't make sense to do the check at runtime, given we're only going to link to one of the versions.
Vincent Povirk madewokherd@gmail.com wrote:
There's a TIFF_VERSION define that seems to have been renamed to TIFF_VERSION_CLASSIC in 4.0.
It doesn't make sense to do the check at runtime, given we're only going to link to one of the versions.
TIFF_VERSION_CLASSIC reflects the TIFF format itself, it's defined to 42, TIFF_VERSION_BIG introduced in 4.x defined to 43.
Unfortunately TIFFLIB_VERSION define reflects the date, not the real version. So for instance libtiff 3.9.7 has it defined to 20120922, 4.0.0 - 20111221, 4.0.1 - 20120218. I don't see a way to differentiate between 3.x and 4.x at compile time.
Dmitry Timoshkov dmitry@baikal.ru wrote:
There's a TIFF_VERSION define that seems to have been renamed to TIFF_VERSION_CLASSIC in 4.0.
It doesn't make sense to do the check at runtime, given we're only going to link to one of the versions.
TIFF_VERSION_CLASSIC reflects the TIFF format itself, it's defined to 42, TIFF_VERSION_BIG introduced in 4.x defined to 43.
Unfortunately TIFFLIB_VERSION define reflects the date, not the real version. So for instance libtiff 3.9.7 has it defined to 20120922, 4.0.0 - 20111221, 4.0.1 - 20120218. I don't see a way to differentiate between 3.x and 4.x at compile time.
I see that this patch is now marked as 'pending'. Are my arguments not clear enough?
Dmitry Timoshkov dmitry@baikal.ru writes:
TIFF_VERSION_CLASSIC reflects the TIFF format itself, it's defined to 42, TIFF_VERSION_BIG introduced in 4.x defined to 43.
Unfortunately TIFFLIB_VERSION define reflects the date, not the real version. So for instance libtiff 3.9.7 has it defined to 20120922, 4.0.0 - 20111221, 4.0.1 - 20120218. I don't see a way to differentiate between 3.x and 4.x at compile time.
I see that this patch is now marked as 'pending'. Are my arguments not clear enough?
You shouldn't check the version, but the actual problem (i.e. the size of the offending type). Also please avoid unnecessary changes.
Alexandre Julliard julliard@winehq.org wrote:
TIFF_VERSION_CLASSIC reflects the TIFF format itself, it's defined to 42, TIFF_VERSION_BIG introduced in 4.x defined to 43.
Unfortunately TIFFLIB_VERSION define reflects the date, not the real version. So for instance libtiff 3.9.7 has it defined to 20120922, 4.0.0 - 20111221, 4.0.1 - 20120218. I don't see a way to differentiate between 3.x and 4.x at compile time.
I see that this patch is now marked as 'pending'. Are my arguments not clear enough?
You shouldn't check the version, but the actual problem (i.e. the size of the offending type). Also please avoid unnecessary changes.
What changes do you consider as unnecessary?
Dmitry Timoshkov dmitry@baikal.ru writes:
Alexandre Julliard julliard@winehq.org wrote:
TIFF_VERSION_CLASSIC reflects the TIFF format itself, it's defined to 42, TIFF_VERSION_BIG introduced in 4.x defined to 43.
Unfortunately TIFFLIB_VERSION define reflects the date, not the real version. So for instance libtiff 3.9.7 has it defined to 20120922, 4.0.0 - 20111221, 4.0.1 - 20120218. I don't see a way to differentiate between 3.x and 4.x at compile time.
I see that this patch is now marked as 'pending'. Are my arguments not clear enough?
You shouldn't check the version, but the actual problem (i.e. the size of the offending type). Also please avoid unnecessary changes.
What changes do you consider as unnecessary?
For instance, changing tsize_t when the problem is with toff_t.
Alexandre Julliard julliard@winehq.org wrote:
You shouldn't check the version, but the actual problem (i.e. the size of the offending type). Also please avoid unnecessary changes.
The offending type is toff_t, it's size is either 32 or 64-bit depending on whether it's libtiff 3.0 or 4.0, or whether it's broken 4.0 headers. So I don't see how checking for the size of toff_t makes it possible to differentiate between 3.x, 4.x and broken 4.x headers.
Dmitry Timoshkov dmitry@baikal.ru writes:
Alexandre Julliard julliard@winehq.org wrote:
You shouldn't check the version, but the actual problem (i.e. the size of the offending type). Also please avoid unnecessary changes.
The offending type is toff_t, it's size is either 32 or 64-bit depending on whether it's libtiff 3.0 or 4.0, or whether it's broken 4.0 headers. So I don't see how checking for the size of toff_t makes it possible to differentiate between 3.x, 4.x and broken 4.x headers.
You can test TIFF_UINT64_T or something along those lines.
-
Alexandre Julliard -
Dmitry Timoshkov -
Vincent Povirk