Bugs item #1509627, was opened at 2006-06-21 01:06 Message generated for change (Comment added) made by dooglus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=757416&aid=1509627&group_id=144022
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 3 Private: No Submitted By: FishB8 (fishb8) Assigned to: Nobody/Anonymous (nobody) Summary: Rendering broken when compiling with g++ 4.1.1/4.2 Initial Comment: I just recently had to rebuild my whole system after moving from gcc3.4 to gcc4.1. Anyway, in the process I also updated libpng to the latest: 1.2.10 During the rebuild of synfig some of the icons were not created correctly and I suspect this was due to the libpng update, although I can't be certain. All the png icons/images were created however, some of them are invisible and others are black. If somebody else can build against libpng 1.2.10 without problems then we can confirm the problem is elsewhere. Until then, that seems like the most likey suspect since several other programs have had problems with the newer libpng. (Apparently there were some small API changes) ---------------------------------------------------------------------- >Comment By: dooglus (dooglus) Date: 2007-09-27 15:57 Message: Logged In: YES user_id=1546005 Originator: NO It looks like the bug is fixed in g++ 4.2.1 Here's a small test case for it: http://dooglus.rincevent.net/synfig/gccbug.1190900356.tgz In 4.2.1 it correctly shows the new value (27). In 4.1.2 it shows the default value (49). However, should we really be addressing 2 consequive members as if they were an array? class Vector { value_type _x, _y; operator[](const int& i) { return (&_x)[i] ; } } can we be sure that _x will be just before _y in memory? ---------------------------------------------------------------------- Comment By: dooglus (dooglus) Date: 2007-09-27 12:45 Message: Logged In: YES user_id=1546005 Originator: NO I wouldn't say this was fixed. It is still possible to specify the optimization level when running ./configure, and doing so will still result in a non-functional program. Can't we find out what's going wrong exactly and fix it or work around it? ---------------------------------------------------------------------- Comment By: Robert B. Quattlebaum, Jr. (darco) Date: 2006-08-30 22:42 Message: Logged In: YES user_id=206661 >From what I can tell, this appears to actually be an issue when synfig is built with optimization. When I built synfig-core on FC5 (GCC41), I got the behavior you described above. However, configuring with the option "-- enable-optimization=1" (the default optimization level is 2), the problem seems to go away. The problem has NOTHING to do with the rendering, and everything to do with the loading of the composition! ie: The problem is that for some reason, the vector parsing function in loadcanvas.cpp is completely broken when compiled with -O2. I have changed the default optimization level on synfig-core on subversion to be 1 instead of 2 until this issue is resolved. ---------------------------------------------------------------------- Comment By: Paul Wise (pabs3) Date: 2006-07-11 20:49 Message: Logged In: YES user_id=35028 Still doesn't work with g++ 4.1.1 (SVN 20060708). g++ 4.2 (SVN trunk 20060709) also does not work. ---------------------------------------------------------------------- Comment By: FishB8 (fishb8) Date: 2006-06-23 17:47 Message: Logged In: YES user_id=1231015 I was previously using libpng 1.2.9. Some apps (for instance ImageMagick) would fail with the new png libs, so I figured it would be first suspect. There were no gcc warnings, but I wasn't sure if I would see any since gcc itself is not generating the images. Order of changes was: -Recompile core system (including libpng) with gcc4.1 -Recompile Synfig Not all the png images get screwed up, just about half of them. I will try building with 4.0 to see if that fixes it. Thanks for looking into it. ---------------------------------------------------------------------- Comment By: Paul Wise (pabs3) Date: 2006-06-23 04:43 Message: Logged In: YES user_id=35028 AHA! I know what the problem is. synfig rendering is completely broken when compiled with GCC 4.1.1. Please compile with 4.0 for now, until we figure out what the problem is. ---------------------------------------------------------------------- Comment By: Paul Wise (pabs3) Date: 2006-06-22 11:24 Message: Logged In: YES user_id=35028 In addition to glennp's questions - hi glenn, thanks for helping :D Was this the order of events? libpng update synfig recompile png errors noticed Did you get any GCC warnings when building synfig with the new libpng? Can you check the API changes and synfig's png module to see if the changes are relevant to synfig? glen: 1.2.8 works fine on my debian sid system. ---------------------------------------------------------------------- Comment By: Glenn Randers-Pehrson (glennrp) Date: 2006-06-21 15:21 Message: Logged In: YES user_id=7859 Can you provide a sample bad PNG? What libpng version were you using previously? Glenn ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=757416&aid=1509627&group_id=144022 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Synfig-devl mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/synfig-devl
