Re^2: GD and jpeg incompatibility

Essentially the same thing happens:

1..12
Testing using jpeg support.
ok 1
gd-jpeg: JPEG library reports unrecoverable error: JPEG parameter stru
+ct mismatch: library thinks size is 464, caller expects 432
Use of uninitialized value $testNo in concatenation (.) or string at t
+/GD.t line 109.
Use of uninitialized value $testNo in concatenation (.) or string at t
+/GD.t line 130.
not ok
gd-jpeg: JPEG library reports unrecoverable error: JPEG parameter stru
+ct mismatch: library thinks size is 376, caller expects 360
not ok 3
gd-jpeg: JPEG library reports unrecoverable error: JPEG parameter stru
+ct mismatch: library thinks size is 376, caller expects 360
not ok 4
gd-jpeg: JPEG library reports unrecoverable error: JPEG parameter stru
+ct mismatch: library thinks size is 376, caller expects 360
not ok 5
gd-jpeg: JPEG library reports unrecoverable error: JPEG parameter stru
+ct mismatch: library thinks size is 376, caller expects 360
not ok 6
gd-jpeg: JPEG library reports unrecoverable error: JPEG parameter stru
+ct mismatch: library thinks size is 376, caller expects 360
not ok 7
ok 8 # Skip, FreeType changes too frequently to be testable
ok 9 # Skip, no XPM support
gd-jpeg: JPEG library reports unrecoverable error: JPEG parameter stru
+ct mismatch: library thinks size is 464, caller expects 432
Can't call method "jpeg" on an undefined value at t/GD.t line 324.
[download]

The XP box, where everything goes fine, has gd-2.0.33 whereas this troublesome Vista box has gd-2.0.35. Other than that, it's the same set up - GD-2.46 and jpeg-6b.

Later on today I'll upgrade the XP box to gd-2.0.35, and expect to see the same error as occurs on the Vista box.

All I've managed to ascertain so far is that the "JPEG library reports unrecoverable error" part of the message comes from the gd library (gd-jpeg.c), and the "JPEG parameter struct mismatch: library thinks size is abc , caller expects xyz" from the jpeg library (prototype found in jerror.h).

Cheers,
Rob

Comment on Re^2: GD and jpeg incompatibility Download Code

Replies are listed 'Best First'.
Re^3: GD and jpeg incompatibility by BrowserUk (Patriarch) on May 26, 2011 at 19:50 UTC
My best guess is that the copy of jpeglib.h bundled with gd is out of step with the jpeglib.h from libjpeg. Specifically the `struct jpeg_decompress_struct` are probably different. I tried to compare them, but the source files are so littered with entirely useless comments interleaved around every dratted line that it is impossible to really tell. You could try replacing the former with the latter and see what happens, but it seems more likely that you'll have to report the problem to the gd people and wait for them to fix it. (Or just go back to 2.33 until it is fixed.) Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply] [d/l]
Re^4: GD and jpeg incompatibility by syphilis (Archbishop) on May 27, 2011 at 07:10 UTC
My best guess is that the copy of jpeglib.h bundled with gd is out of step with the jpeglib.h from libjpeg. Yes, I think so. I suspect that gd-2.0.35 might want something later than jpeg-6b (which is about 13 years old). So I might first try upgrading jpeg rather than downgrading gd. I'll post again when I get it sorted ... might take a while. Thanks Buk. Cheers, Rob	[reply]
Re^5: GD and jpeg incompatibility by syphilis (Archbishop) on May 30, 2011 at 09:04 UTC
Building GD-2.46 against gd-2.0.35 and jpeg-8c gets rid of the errors I was concerned about. Of course, then I get slugged with this GD-2.46 test suite bug, but I'm not concerned about that. Now it's just a matter of trying to work out why my static x64 build of GD-2.46 has suddenly decided it has to be built against a dynamic zlib library, instead of the static one that was fine last week. UPDATE: I didn't exactly work out why it kept wanting to build against a dynamic zlib library. Eventually I realised that I'd added quite a few extra directories to the msys shell's path during the course of the day - when I reduced the path to simply what was needed to build gd-2.0.35, the problem went away. Cheers, Rob	[reply]