Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
Summary: mingw32-libjpeg crash on windows, typedef
https://bugzilla.redhat.com/show_bug.cgi?id=497492
Summary: mingw32-libjpeg crash on windows, typedef Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: mingw32-libjpeg AssignedTo: rjones@redhat.com ReportedBy: mikkel@linet.dk QAContact: extras-qa@fedoraproject.org CC: lfarkas@lfarkas.org, berrange@redhat.com, rjones@redhat.com, fedora-mingw@lists.fedoraproject.org Classification: Fedora
Mikkel Kruse Johnsen mikkel@linet.dk changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag| |fedora-review?
Created an attachment (id=341131) --> (https://bugzilla.redhat.com/attachment.cgi?id=341131) 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:
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=497492
--- Comment #1 from Mikkel Kruse Johnsen mikkel@linet.dk 2009-04-24 05:35:45 EDT --- Created an attachment (id=341132) --> (https://bugzilla.redhat.com/attachment.cgi?id=341132) Patch to fix typedef
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=497492
Ilyes Gouta ilyes.gouta@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ilyes.gouta@gmail.com
--- Comment #2 from Ilyes Gouta ilyes.gouta@gmail.com 2009-04-24 06:17:12 EDT --- 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.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=497492
Erik van Pienbroek erik-fedora@vanpienbroek.nl changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag|fedora-review? |
--- Comment #3 from Erik van Pienbroek erik-fedora@vanpienbroek.nl 2009-04-24 06:43:31 EDT --- Removed the fedora-review flag as it should only be used for package reviews
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=497492
--- Comment #4 from Richard W.M. Jones rjones@redhat.com 2009-04-24 10:09:23 EDT --- I posted on the upstream libjpeg mailing list:
http://sourceforge.net/mailarchive/forum.php?forum_name=libjpeg-devel-6x
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=497492
--- Comment #5 from Kevin Kofler kevin@tigcc.ticalc.org 2009-04-26 01:14:47 EDT --- 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.
bugzilla@redhat.com wrote:
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=497492
--- Comment #5 from Kevin Kofler kevin@tigcc.ticalc.org 2009-04-26 01:14:47 EDT --- 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.
i don't understand the "wins" for me it's an error since: error: conflicting types for 'boolean' anyway the INT32 problem can be fixed easily, but my original question still do i simple remove the declaration of INT32 or do some more advance ifdef? and what other can do with the boolean problem?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=497492
Erik van Pienbroek erik-fedora@vanpienbroek.nl changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED CC| |erik-fedora@vanpienbroek.nl
--- Comment #7 from Erik van Pienbroek erik-fedora@vanpienbroek.nl 2009-08-22 11:21:55 EDT --- 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
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=497492
--- Comment #8 from Erik van Pienbroek erik-fedora@vanpienbroek.nl 2009-08-22 11:23:02 EDT --- Created an attachment (id=358307) --> (https://bugzilla.redhat.com/attachment.cgi?id=358307) Proposed patch to libjpeg-7 for solution 3
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=497492
--- Comment #9 from Erik van Pienbroek erik-fedora@vanpienbroek.nl 2009-08-22 11:32:43 EDT --- Created an attachment (id=358308) --> (https://bugzilla.redhat.com/attachment.cgi?id=358308) 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.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=497492
--- Comment #10 from Erik van Pienbroek erik-fedora@vanpienbroek.nl 2009-08-22 11:33:39 EDT --- Created an attachment (id=358309) --> (https://bugzilla.redhat.com/attachment.cgi?id=358309) Patch against libtiff to use 'jpeg_boolean' instead of 'boolean'
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=497492
--- Comment #11 from Erik van Pienbroek erik-fedora@vanpienbroek.nl 2009-08-22 11:34:38 EDT --- Created an attachment (id=358310) --> (https://bugzilla.redhat.com/attachment.cgi?id=358310) Patch against gtk2 to use 'jpeg_boolean' instead of 'boolean'
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=497492
Richard W.M. Jones rjones@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|11 |rawhide
--- Comment #12 from Richard W.M. Jones rjones@redhat.com 2009-08-22 12:06:39 EDT --- 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).
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=497492
--- Comment #13 from Erik van Pienbroek erik-fedora@vanpienbroek.nl 2009-08-22 13:05:00 EDT --- (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...
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=497492
--- Comment #14 from Erik van Pienbroek erik-fedora@vanpienbroek.nl 2009-08-23 08:34:59 EDT --- If there are no objections I'm going to apply these patches tomorrow evening (Monday August 24) to Rawhide
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=497492
Erik van Pienbroek erik-fedora@vanpienbroek.nl changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |RAWHIDE
--- Comment #15 from Erik van Pienbroek erik-fedora@vanpienbroek.nl 2009-08-30 16:36:42 EDT --- The patches which were proposed here have been applied to rawhide at Thursday August 27 in mingw32-libjpeg-7-1.fc12
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=497492
Adam Goode adam@spicenitz.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |adam@spicenitz.org
--- Comment #16 from Adam Goode adam@spicenitz.org 2010-06-03 15:27:42 EDT --- 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).
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=497492
--- Comment #17 from Adam Goode adam@spicenitz.org 2010-06-03 15:50:23 EDT --- Also, why is this necessary just for the mingw32 package? The native package has no such patch.
-
Farkas Levente -
Red Hat Bugzilla