Created attachment 341131 [details] Patch for SPEC file, to include jpeg-6b-typedefs.patch Description of problem: Testing with webkitgtk and loading pages containing jpeg images courses a crash How reproducible: Always Steps to Reproduce: 1. Load ex http://arabic.cnn.com in webkitgtk Actual results: Crash Expected results: Should load Additional info:
Created attachment 341132 [details] Patch to fix typedef
Hi, Having boolean typedef'ed as an int is much more natural, at least for the C compiler. Can you post the faulty C code sequence which actually trigger the segfault? I'd like to see if we can fix the issue in an alternative way. Regards, Ilyes Gouta.
Removed the fedora-review flag as it should only be used for package reviews
I posted on the upstream libjpeg mailing list: http://sourceforge.net/mailarchive/forum.php?forum_name=libjpeg-devel-6x
Looks like the problem here is that rpcndr.h and libjpeg both define a "boolean" type, and whoever is included first "wins". So programs including rpcndr.h before libjpeg will try using the wrong boolean type.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Recently a new version of libjpeg was released (http://www.ijg.org/). Some code was added by upstream to circumvent the bug described here. However, this change was incomplete and contains a typo..so basically we're still stuck with the same problem. Now there are multiple solutions to 'fix' this bug once and for all: Solution 1: ----------- Prevent the conflict by having jmorecfg.h contain 'typedef unsigned char boolean;' + No conflict anymore when using #include <rpcndr.h> - The API of the libjpeg-7.dll will be different than what it is now - All dependent packages need to be rebuild (libtiff, libjasper and gtk2) Solution 2: ----------- Don't use 'typedef int boolean;' when the file rpcndr.h is already included + No rebuild required for dependent packages (libtiff, libjasper and gtk2) - This introduces side-effects when one source code file #include's rpcndr.h and another one doesn't Solution 3: ----------- Don't use a datatype named 'boolean', but something different like 'jpeg_boolean' + No conflicts anymore whether or not the file rpcndr.h is #include'd + Lower risk of side effects (the only risk which remains is the situation where a library or application #include's rpcndr.h and uses the 'boolean' datatype, but for those situations the compiler should give a warning anyway) + The API of the libjpeg-7.dll remains the same (the size of all the data structures remain the same) - May require patching of libraries/applications which use libjpeg My vote goes to the third solution. That solution is also one which 'could' be proposed upstream (be it for a future major version of libjpeg as it may require changes in libraries or applications using libjpeg). Patches are attached
Created attachment 358307 [details] Proposed patch to libjpeg-7 for solution 3
Created attachment 358308 [details] Patch to fix a typo which is in libjpeg-7 There also was a conflict between libjpeg and basestd.h regarding the datatype 'INT32'. In libjpeg-7 some code was added to fix this problem, but this fix contains a typo. Attentive readers might have noticed that basetsd.h contains a 'typedef int INT32' while libjpeg uses a 'typedef long INT32'. For Win32 this doesn't matter as sizeof(int) == sizeof(long) on those environments.
Created attachment 358309 [details] Patch against libtiff to use 'jpeg_boolean' instead of 'boolean'
Created attachment 358310 [details] Patch against gtk2 to use 'jpeg_boolean' instead of 'boolean'
Do we know what the situation is with upstream jpeg? Where did jpeg 7 come from? The mailing list mentioned in comment 4 still looks pretty dead. My point is that if upstream has somehow come alive enough to do a release, then we should ask them to fix the typo (or what the best fix is).
(In reply to comment #12) > Do we know what the situation is with upstream jpeg? Where did jpeg 7 > come from? The mailing list mentioned in comment 4 still looks pretty > dead. > > My point is that if upstream has somehow come alive enough to do > a release, then we should ask them to fix the typo (or what the best > fix is). To be honest, I absolutely haven't got a clue... The ChangeLog only mentions the IJG group. The sourceforge page only refers to version 6. The code which is in the sourceforge CVS is a different codebase than the libjpeg-7 release from the IJG website...
If there are no objections I'm going to apply these patches tomorrow evening (Monday August 24) to Rawhide
The patches which were proposed here have been applied to rawhide at Thursday August 27 in mingw32-libjpeg-7-1.fc12
This is a pretty big problem, this does change the API of libjpeg such that I cannot build my code both natively on Fedora and with mingw32. I am using my own src manager, so the function I define has to either return boolean (on all libjpeg except this one) or jpeg_boolean (on the Fedora patched mingw32-libjpeg).
Also, why is this necessary just for the mingw32 package? The native package has no such patch.