Bugzilla Bug 181611

Ogre3D-1.4.1 depends on freeimage for PNG image loading. It seems that
freeimage needs the included libpng from the freeimage sources. I modified the
ebuild to *not* use the systems libpng and instead use the included libpng.

The best situation would be to find out why it doesn't work with systems
libpng. But until someone do this we should simply use this new ebuild.

Created an attachment (id=121702) [details]
freeimage-3.9.3-r2.ebuild

Created an attachment (id=121704) [details]
freeimage-3.9.3-build.patch

Created an attachment (id=121705) [details]
freeimage-3.9.3-sys-headers.patch

(In reply to comment #0)
> The best situation would be to find out why it doesn't work with systems
> libpng.

Maybe if you posted some real info about what doesn't work, someone could fix
it. Using bundled stuff is a very bad idea for security and other reasons.

Here is the problem I reported to the freeimage forum:

http://sourceforge.net/forum/forum.php?thread_id=1753657&forum_id=36111

And here is an old thread to this topic:

http://sourceforge.net/forum/message.php?msg_id=4109869

I've not the time to go deep into freeimage code. Perhaps someone else could
solve it. But the freeimage developers suggest to use their version, because
they changed some sources. Someone should diff their version and the real
libpng source. But until then I think we should provide the libpng included
version. Perhaps as masked package?

*** This bug has been marked as a duplicate of bug 178110 ***

Created an attachment (id=130365) [details]
libpng and FreeImage's libpng diff

I've made a diff between FreeImage's libpng and the vanilla libpng (version
1.2.16), and submitted the attachment here. The only difference seems to be the
'pngconf.h' file. FreeImage developers seem to have enabled some form of
feature in libpng that's been intentionally blocked by the libpng developers.
Developers of libpng "explain" that with this (in the same pngconf.h file):

/* The size of the png_text structure changed in libpng-1.0.6 when
 * iTXt support was added.  iTXt support was turned off by default through
 * libpng-1.2.x, to support old apps that malloc the png_text structure
 * instead of calling png_set_text() and letting libpng malloc it.  It
 * was turned on by default in libpng-1.3.0.
 */

Now, iTXt seems to enable reading/writing of PNG comments in languages other
than English, according to
http://sourceforge.net/forum/message.php?msg_id=4110303 (I'm guessing he meant
in encodings other thatn ISO-8859-1?).
As for the assembler/MMX "thingies", I have no idea, to be honest. Probably
someone with better knowledge should look into it (although I'm wondering if
that bit of code is needed for non win32 archs? - just a thought).
Now, if the assembler/MMX defines are NOT needed, one solution could be to add
a USE flag to libpng (itxt), and add appropriate checking to FreeImage ebuild
etc, although I'm doubtful the package maintainers would like it. Maybe someone
who had the problems in the Bug 178110 could try testing if removal of
assembler/MMX defines will result in equal amount of instability.
On the other side - is the change non-trivial enough to be considered a
security risk if FreeImage is built using its own libpng?

P.S.
If I'm writing utter nonsense here, please inform me of that, I'm just trying
to help (I've been somewhat affected by this bug while trying to build a game
that uses the library). :)

Oh, hell, I can't believe I managed to comment in wrong bug report. I apologize
for this one.