Bug 178110 - media-libs/freeimage CFLAGS -pipe issues
|
Bug#:
178110
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: games@gentoo.org
|
Reported By: egore@gmx.de
|
|
Component: Games
|
|
|
URL:
|
|
Summary: media-libs/freeimage CFLAGS -pipe issues
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2007-05-11 21:18 0000
|
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.
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 an attachment (id=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 an attachment (id=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 an attachment (id=139023) [details]
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 an attachment (id=139024) [details]
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. :)
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.
