I saw several segfaults with freeimage and ogre in opengate [1]. I tracked down the issue to be in the CFLAGS. My CFLAGS normally are -O3 -march=athlon-xp -pipe If I drop -pipe from the CFLAGS an rebuild freeimage it works fine. [1] http://sourceforge.net/projects/opengate Reproducible: Always
Ok, I'm no longer sure it is "-pipe" ... It seems to work with "-O3 -march=athlon-xp" and also with "-O3 -pipe" but not with "-O3 -march=athlon-xp -pipe". I'm not really sure what to do. Maybe we should not apply custom CFLAGS? Or add them as an option like mplayer?
I tried this use flags and it wasn't a solution for me. I've the same problems running Ogre3D apps. I found this thread from freeimage. http://sourceforge.net/forum/message.php?msg_id=4112322 Quote: "The only possible problem I could see is that you link FreeImage with the OS 'native' libpng instead of the FreeImage one ... " Perhaps we shouldn't use Gentoo libpng as long there's no better solution.
See here a possible solution: http://bugs.gentoo.org/show_bug.cgi?id=181611
Why did you file a new bug for that?
Don't ask me. I would also fit into this bug report. But now we've two bugs. Sorry! I asked some questions in the freeimage forum and no developers answered to me. I don't think they they'll change their library dependency handling.
*** Bug 181611 has been marked as a duplicate of this bug. ***
Created attachment 130366 [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 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). :) P.S.S. I managed to originally post in wrong bug report (the duplicate one), sorry. And if I made a mistake by posting here again, please shoot me...
Created attachment 139022 [details] ebuild for freeimage 3.10.0 I had the same problems with OGRE 1.4 crashing when it tries to load a png image. It seems version 3.10.0 of freeimage has fixed the problem, but still requires it's own version of libpng. The ebuild applies to patches. Will post them next.
Created attachment 139023 [details, diff] modified version of freeimage-3.9.3-build.patch This patch is a modified version of the freeimage-3.9.3-build.patch. I removed the parts that makes freeimage use the system's libraries instead of the custom versions.
Created attachment 139024 [details, diff] Fixes two compile bugs. First bug is a missing MIN(a,b) define. I didn't know of a safe header to include for this simple macro so I just added it to the source file that needs it. Second bug has to do with a 64bit pointer(I am on amd64) being casted to a DWORD (32bit) value. The build stopped with an loss of precision error. I replaced DWORD with size_t. This may not be the best replacement, since some systems may not have size_t defined. But it should be fine on Linux.
I have made some tests, I found we can not simply change freeimage's libjpeg and libpng to use system's library, the system lib lack of some feature which is enabled by freeimage, the seg fault problem is tiff's LZW. if you use gdb, you can find the seg fault problem. MIN(a,b) problem is easy to fix, libtiff can also use system's lib, but system tiff don't have these headers: tiffiop.h tif_config.h tif_dir.h, the openexr and openjpeg in freeimage-3.10 can also use system lib, but i'm not so sure about libmng. LZW problem exists in system lib(3.8.2) and freeimage's 3.9.0. So, If we only enable libjpeg/libpng/libmng in freeimage, then the testapi will have only one problem, LZW of tiff. I'm not so sure about libmng, I think it should depend on the libpng. I hope my bad english make myself clear. :)
New ebuild for freeimage-3.10.0 submitted here: http://bugs.gentoo.org/show_bug.cgi?id=213969 (Fixes problem with visibility of internal versions of libraries.)
Hello everybody, i just would like to know why this bug hasn't been closed and the new ebuild integrated into the portage tree ? FreeImage 3.11.0 has been released, but the most recent version i could find in the portage tree is 'freeimage-3.9.3-r1' which is masked, waiting for this bug to be closed and it's seems that Christian did a new ebuild for resolving the issue with libpng.
This should be fixed with bug 213969.
