digikam - error: invalid use of incomplete type 'png_struct {aka struct png_struct_def}'
Tim, Darrell,
Ran into an error building digikam. Is this due to libpng or digikam? How to fix?:
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../../.. -I/opt/trinity/include -I/opt/tqt3/include -I. -include tqt.h -I../../../../digikam/libs/dimg -I../../../../digikam/libs/dimg/filters -I../../../../digikam/libs/curves -I../../../../digikam/libs/levels -I../../../../digikam/libs/histogram -I../../../../digikam/libs/whitebalance -I../../../../digikam/libs/dmetadata -I../../../../digikam/digikam -I/opt/trinity/include -I/opt/trinity/include -DQT_THREAD_SUPPORT -D_REENTRANT -fno-tree-pre -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -O2 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -fpermissive -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -I/usr/include/tqt -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_CLEAN_NAMESPACE -MT pngloader.lo -MD -MP -MF .deps/pngloader.Tpo -c pngloader.cpp -fPIC -DPIC -o .libs/pngloader.o pngloader.cpp: In member function 'virtual bool Digikam::PNGLoader::load(const TQString&, Digikam::DImgLoaderObserver*)': pngloader.cpp:123:9: error: invalid use of incomplete type 'png_struct {aka struct png_struct_def}' /usr/include/png.h:855:16: error: forward declaration of 'png_struct {aka struct png_struct_def}' pngloader.cpp:410:99: warning: invalid conversion from 'char**' to 'png_bytepp {aka unsigned char**}' [-fpermissive] pngloader.cpp: In member function 'virtual bool Digikam::PNGLoader::save(const TQString&, Digikam::DImgLoaderObserver*)': pngloader.cpp:529:9: error: invalid use of incomplete type 'png_struct {aka struct png_struct_def}' /usr/include/png.h:855:16: error: forward declaration of 'png_struct {aka struct png_struct_def}' pngloader.cpp:602:132: warning: invalid conversion from 'char*' to 'png_const_bytep {aka const unsigned char*}' [-fpermissive] pngloader.cpp:662:39: warning: deprecated conversion from string constant to 'png_charp {aka char*}' [-Wwrite-strings] pngloader.cpp: In member function 'long int Digikam::PNGLoader::formatStringList(char*, size_t, const char*, __va_list_tag*)': pngloader.cpp:970:55: warning: function might be possible candidate for 'gnu_printf' format attribute [-Wmissing-format-attribute] pngloader.cpp: In member function 'virtual bool Digikam::PNGLoader::load(const TQString&, Digikam::DImgLoaderObserver*)': pngloader.cpp:90:41: warning: ignoring return value of 'size_t fread(void*, size_t, size_t, FILE*)', declared with attribute warn_unused_result [-Wunused-result] make[5]: *** [pngloader.lo] Error 1 make[5]: Leaving directory `/build/src/digikam/digikam/libs/dimg/loaders' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/build/src/digikam/digikam/libs/dimg' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/build/src/digikam/digikam/libs' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/build/src/digikam/digikam' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/build/src/digikam' make: *** [all] Error 2
On 03/27/2012 09:08 AM, David C. Rankin wrote:
Tim, Darrell,
Ran into an error building digikam. Is this due to libpng or digikam? How to fix?:
<snip>
pngloader.cpp: In member function 'virtual bool Digikam::PNGLoader::load(const TQString&, Digikam::DImgLoaderObserver*)': pngloader.cpp:123:9: error: invalid use of incomplete type 'png_struct {aka struct png_struct_def}' /usr/include/png.h:855:16: error: forward declaration of 'png_struct {aka struct png_struct_def}' pngloader.cpp:410:99: warning: invalid conversion from 'char**' to 'png_bytepp {aka unsigned char**}' [-fpermissive] pngloader.cpp: In member function 'virtual bool Digikam::PNGLoader::save(const TQString&, Digikam::DImgLoaderObserver*)': pngloader.cpp:529:9: error: invalid use of incomplete type 'png_struct {aka struct png_struct_def}' /usr/include/png.h:855:16: error: forward declaration of 'png_struct {aka struct png_struct_def}' pngloader.cpp:602:132: warning: invalid conversion from 'char*' to 'png_const_bytep {aka const unsigned char*}' [-fpermissive] pngloader.cpp:662:39: warning: deprecated conversion from string constant to 'png_charp {aka char*}' [-Wwrite-strings] pngloader.cpp: In member function 'long int Digikam::PNGLoader::formatStringList(char*, size_t, const char*, __va_list_tag*)': pngloader.cpp:970:55: warning: function might be possible candidate for 'gnu_printf' format attribute [-Wmissing-format-attribute] pngloader.cpp: In member function 'virtual bool Digikam::PNGLoader::load(const TQString&, Digikam::DImgLoaderObserver*)': pngloader.cpp:90:41: warning: ignoring return value of 'size_t fread(void*, size_t, size_t, FILE*)', declared with attribute warn_unused_result [-Wunused-result]
<snip>
Both digikam and gwenview are failing with the same error. I attempted gwenview and it has the same error: invalid use of incomplete type 'png_info {aka struct png_info_def}' problem:
/bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../.. -I./.. -I/opt/trinity/include -I/opt/tqt3/include -I. -include tqt.h -D_LARGEFILE64_SOURCE -DQT_THREAD_SUPPORT -D_REENTRANT -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -O2 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -I/usr/include/tqt -MT pngformattype.lo -MD -MP -MF .deps/pngformattype.Tpo -c -o pngformattype.lo pngformattype.cpp libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I./.. -I/opt/trinity/include -I/opt/tqt3/include -I. -include tqt.h -D_LARGEFILE64_SOURCE -DQT_THREAD_SUPPORT -D_REENTRANT -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -O2 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -I/usr/include/tqt -MT pngformattype.lo -MD -MP -MF .deps/pngformattype.Tpo -c pngformattype.cpp -fPIC -DPIC -o .libs/pngformattype.o pngformattype.cpp: In function 'void Gwenview::setup_qt(TQImage&, png_structp, png_infop)': pngformattype.cpp:214:33: error: invalid use of incomplete type 'png_info {aka struct png_info_def}' /usr/include/png.h:724:16: error: forward declaration of 'png_info {aka struct png_info_def}' pngformattype.cpp:249:25: error: invalid use of incomplete type 'png_info {aka struct png_info_def}' /usr/include/png.h:724:16: error: forward declaration of 'png_info {aka struct png_info_def}' pngformattype.cpp:261:17: error: invalid use of incomplete type 'png_info {aka struct png_info_def}' /usr/include/png.h:724:16: error: forward declaration of 'png_info {aka struct png_info_def}' pngformattype.cpp:269:54: error: invalid use of incomplete type 'png_info {aka struct png_info_def}' /usr/include/png.h:724:16: error: forward declaration of 'png_info {aka struct png_info_def}' pngformattype.cpp:275:26: error: invalid use of incomplete type 'png_info {aka struct png_info_def}' /usr/include/png.h:724:16: error: forward declaration of 'png_info {aka struct png_info_def}' pngformattype.cpp:277:15: error: invalid use of incomplete type 'png_info {aka struct png_info_def}' /usr/include/png.h:724:16: error: forward declaration of 'png_info {aka struct png_info_def}' pngformattype.cpp:278:15: error: invalid use of incomplete type 'png_info {aka struct png_info_def}' /usr/include/png.h:724:16: error: forward declaration of 'png_info {aka struct png_info_def}' pngformattype.cpp:279:15: error: invalid use of incomplete type 'png_info {aka struct png_info_def}' /usr/include/png.h:724:16: error: forward declaration of 'png_info {aka struct png_info_def}' pngformattype.cpp:281:15: error: invalid use of incomplete type 'png_info {aka struct png_info_def}' /usr/include/png.h:724:16: error: forward declaration of 'png_info {aka struct png_info_def}' pngformattype.cpp:290:22: error: invalid use of incomplete type 'png_info {aka struct png_info_def}' /usr/include/png.h:724:16: error: forward declaration of 'png_info {aka struct png_info_def}' pngformattype.cpp:292:11: error: invalid use of incomplete type 'png_info {aka struct png_info_def}' /usr/include/png.h:724:16: error: forward declaration of 'png_info {aka struct png_info_def}' pngformattype.cpp:293:11: error: invalid use of incomplete type 'png_info {aka struct png_info_def}' /usr/include/png.h:724:16: error: forward declaration of 'png_info {aka struct png_info_def}' pngformattype.cpp:294:11: error: invalid use of incomplete type 'png_info {aka struct png_info_def}' /usr/include/png.h:724:16: error: forward declaration of 'png_info {aka struct png_info_def}' pngformattype.cpp: In member function 'virtual int Gwenview::PNGFormat::decode(TQImage&, TQImageConsumer*, const uchar*, int)': pngformattype.cpp:392:6: error: invalid use of incomplete type 'png_struct {aka struct png_struct_def}' /usr/include/png.h:855:16: error: forward declaration of 'png_struct {aka struct png_struct_def}' pngformattype.cpp:420:9: error: invalid use of incomplete type 'png_struct {aka struct png_struct_def}' /usr/include/png.h:855:16: error: forward declaration of 'png_struct {aka struct png_struct_def}' pngformattype.cpp: In member function 'void Gwenview::PNGFormat::end(png_structp, png_infop)': pngformattype.cpp:487:27: error: invalid use of incomplete type 'png_struct {aka struct png_struct_def}' /usr/include/png.h:855:16: error: forward declaration of 'png_struct {aka struct png_struct_def}' make[3]: *** [pngformattype.lo] Error 1 make[3]: Leaving directory `/build/src/gwenview/src/gvcore' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/build/src/gwenview/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/build/src/gwenview' make: *** [all] Error 2
Ran into an error building digikam. Is
this due to libpng or digikam? How to fix?:
What version of libpng? I am building both without failure against libpng 1.4.9.
Darrell
On 03/27/2012 02:43 PM, Darrell Anderson wrote:
What version of libpng? I am building both without failure against libpng 1.4.9.
Darrell
libpng 1.5.9-1
So far all other apps have built against it, but digikam and gwenview both failed pointing directly to libpng. If it is libpng, do you want me to file a bug and elevate to BLOCKER. Everything is going to libpng 1.5 quickly so TDE must be compitible.
Do you recognize those build failure as being libpng itself or tde?
libpng 1.5.9-1
So far all other apps have built against it, but digikam and gwenview both failed pointing directly to libpng. If it is libpng, do you want me to file a bug and elevate to BLOCKER. Everything is going to libpng 1.5 quickly so TDE must be compitible.
Do you recognize those build failure as being libpng itself or tde?
A quick check of the web shows that others had problems building digikam and gwenview with libpng 1.5. I haven't looked for patches. If you find any, test them and if successful, attach them to a bug report.
Currently I don't yet have a system installed with libpng 1.5 and can't test any 1.5 patches. If you confirm the patches work, and I can build with the patches but against libpng 1.4.9 (that is, the patches do not backfire against older versions), then I'll push to GIT.
If the patches fail against older versions, then we need to update the wiki so packagers can add appropriate tests to their build scripts to use the libpng 1.5 patches only when 1.5 is installed. I'll still push to GIT once we have that all done.
Darrell
On 03/27/2012 05:17 PM, Darrell Anderson wrote:
A quick check of the web shows that others had problems building digikam and gwenview with libpng 1.5. I haven't looked for patches. If you find any, test them and if successful, attach them to a bug report.
Currently I don't yet have a system installed with libpng 1.5 and can't test any 1.5 patches. If you confirm the patches work, and I can build with the patches but against libpng 1.4.9 (that is, the patches do not backfire against older versions), then I'll push to GIT.
If the patches fail against older versions, then we need to update the wiki so packagers can add appropriate tests to their build scripts to use the libpng 1.5 patches only when 1.5 is installed. I'll still push to GIT once we have that all done.
Darrell
OK,
I'll look tonight. Do we want a wiki note added or do we want to open a bug report so we have somewhere to attach patches?
I'll look tonight. Do we want a wiki note added or do we want to open a bug report so we have somewhere to attach patches?
Let's see how we both are able to build after testing the patches.
Darrell
On 03/27/2012 09:30 PM, Darrell Anderson wrote:
I'll look tonight. Do we want a wiki note added or do we want to open a bug report so we have somewhere to attach patches?
Let's see how we both are able to build after testing the patches.
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Getting somewhere - still no patch. I know why it fails:
What steps will reproduce the problem? 1. In libpng-1.5, they removed direct access to png_struct and png_info, thus the build fails. https://code.google.com/p/galapix/issues/detail?id=5
I don't know what this means. I'm looking at the digikam code and the libpng code to see if I can figure out what broke using the lamppost theory...[1].
Footnotes:
[1] Lamppost Theory - If you lose your keys at night, where do you look? Answer - under the lamppost. Regardless of where you lost them, it's dark, the only place you have a chance of finding them is -- under the lamppost.
If you have a flashlight -- please share :)
On 03/28/2012 10:42 AM, David C. Rankin wrote:
On 03/27/2012 09:30 PM, Darrell Anderson wrote:
I'll look tonight. Do we want a wiki note added or do we want to open a bug report so we have somewhere to attach patches?
Let's see how we both are able to build after testing the patches.
Darrell
Found the incompatibility introduced by libpng15. Explained in the libpng/src/libpng-manual.txt file:
II. Structures
There are two main structures that are important to libpng, png_struct and png_info. Both are internal structures that are no longer exposed in the libpng interface (as of libpng 1.5.0).
The png_info structure is designed to provide information about the PNG file. At one time, the fields of png_info were intended to be directly accessible to the user. However, this tended to cause problems with applications using dynamically loaded libraries, and as a result a set of interface functions for png_info (the png_get_*() and png_set_*() functions) was developed, and direct access to the png_info fields was deprecated.. ^^^^^^^^^^^^
The png_struct structure is the object used by the library to decode a single image. As of 1.5.0 this structure is also not exposed.
Almost all libpng APIs require a pointer to a png_struct as the first argument. Many (in particular the png_set and png_get APIs) also require a pointer to png_info as the second argument. Some application visible macros defined in png.h designed for basic data access (reading and writing integers in the PNG format) don't take a png_info pointer, but it's almost always safe to assume that a (png_struct*) has to be passed to call an API function.
This will take a bug report to coordinate information regarding the change and fixes needed by all the various code. I'll get one started and list it as major. You and Tim can elevate it to BLOCKER if you determine that's what it needs to be. I'll start listing applications affected when I find them.
On 03/28/2012 10:59 AM, David C. Rankin wrote:
This will take a bug report to coordinate information regarding the change and fixes needed by all the various code. I'll get one started and list it as major. You and Tim can elevate it to BLOCKER if you determine that's what it needs to be. I'll start listing applications affected when I find them.
Done:
http://bugs.trinitydesktop.org/show_bug.cgi?id=949
On Wed, 28 Mar 2012 11:09:39 -0500 "David C. Rankin" drankinatty@suddenlinkmail.com wrote:
On 03/28/2012 10:59 AM, David C. Rankin wrote:
This will take a bug report to coordinate information regarding the change and fixes needed by all the various code. I'll get one started and list it as major. You and Tim can elevate it to BLOCKER if you determine that's what it needs to be. I'll start listing applications affected when I find them.
Done:
NetBSD may have patched this, but I can't find the actual patch file, just references to same ("Add media-gfx/gwenview-1.4.2 with libpng 1.5 buildfix (NetBSD patch); Fix media -gfx/digikam-0.9.6 to build with libpng 1.5 (NetBSD patch)") and some incomplete chunks from a now-deceased website.
This will take a bug report to coordinate information regarding the change and fixes needed by all the various code. I'll get one started and list it as major. You and Tim can elevate it to BLOCKER if you determine that's what it needs to be. I'll start listing applications affected when I find them.
Done:
NetBSD may have patched this, but I can't find the actual patch file, just references to same ("Add media-gfx/gwenview-1.4.2 with libpng 1.5 buildfix (NetBSD patch); Fix media -gfx/digikam-0.9.6 to build with libpng 1.5 (NetBSD patch)") and some incomplete chunks from a now-deceased website.
Yes, this is becoming strange. I spent the past half-hour unsuccessfully looking for patches.
How deep does this affect Trinity? All the way to building (T)Qt3 too?
Darrell
On 03/28/2012 01:05 PM, Darrell Anderson wrote:
How deep does this affect Trinity? All the way to building (T)Qt3 too?
Still trying to figure this out. I've built everything thus far on libpng15, so it only effects those apps that access png_struct and png_info directly. So far that has caused the following builds to fail:
digikam gwenview
The following list has built fine on libpng15:
tde-abakus 3513_tqt-2 tde-arts 3513_tqt-11 tde-basket 1.0.3-1 tde-dbus-1-tqt 3513_tqt-10 tde-dbus-tqt 3513_tqt-8 tde-dolphin 3513_tqt-3 tde-gtk-qt-engine 3513_tqt-3 tde-k3b 3.5.14_dev-2 tde-kgtk-qt3 3513_tqt-2 tde-kio-locate 3513_tqt-3 tde-kipi-plugins 3513_tqt-2 tde-kpowersave 3513_tqt-2 tde-ksplash-engine-moodin 3.5.14_dev-1 tde-libart-lgpl 3513_tqt-9 tde-libcaldav 0.6.2_tqt-11 tde-libcarddav 0.6.2_tqt-11 tde-libkdcraw 3513_tqt-3 tde-libkexiv2 3513_tqt-2 tde-libkipi 3513_tqt-2 tde-libksquirrel 3513_tqt-4 tde-python-tqt 3513_tqt-4 tde-rosegarden 3513_tqt-2 tde-sip 3513_tqt-3 tde-sip4-tqt 3513_tqt-3 tde-soundkonverter 3.5.14_dev-1 tde-tde-style-qtcurve 3513_tqt-2 tde-tdeaddons 3513_tqt-2 tde-tdeadmin 3513_tqt-2 tde-tdeartwork 3513_tqt-5 tde-tdebase 3513_tqt-10 tde-tdeedu 3513_tqt-2 tde-tdegames 3513_tqt-2 tde-tdegraphics 3513_tqt-5 tde-tdelibs 3513_tqt-8 tde-tdemultimedia 3513_tqt-5 tde-tdenetwork 3513_tqt-5 tde-tdepim 3513_tqt-5 tde-tdesdk 3513_tqt-2 tde-tdesvn 3513_tqt-2 tde-tdetoys 3513_tqt-2 tde-tdeutils 3513_tqt-3 tde-tdevelop 3513_tqt-5 tde-tdewebdev 3513_tqt-5 tde-tqca-tls 3513_tqt-11 tde-tqt3 3.8.8.d_git-11 tde-tqtinterface 3513_tqt-19 tde-twin-style-crystal 1.0.5-1 tde-wlassistant 3513_tqt-2 tde-yakuake 3.5.14_dev-1
So I think at this point it is a case for fixing the bad apples as they are identified rather than major open-heart surgery on the tde core...
I don't want to corrupt my builds by installing libpng14 in parallel with libpng15... but it is a tempting work-around to test.... but that would defeat the point of making TDE the robust, current and bullet-proof desktop we are all striving for....
On 03/28/2012 12:14 PM, E. Liddell wrote:
NetBSD may have patched this, but I can't find the actual patch file, just references to same ("Add media-gfx/gwenview-1.4.2 with libpng 1.5 buildfix (NetBSD patch); Fix media -gfx/digikam-0.9.6 to build with libpng 1.5 (NetBSD patch)") and some incomplete chunks from a now-deceased website.
Yep, I've found little bits and pieces around as well, but no off-the-shelf patch. It looks like we will just have to open libpng/src/png.c libpng/src/png.h and the digikam and gwenview files and patch the problems for TDE.
I'm no programmer, but I think the lack of direct access to png_struct and png_info mean we will have to add a class/struct instantation for png_struct and png_info in each of the files that currently call the structures directly and change the calls to use calls through the instance we just created instead.
That may be way off, but from reading and my limited understanding, that's the rabbit trail I'm trying to follow...
On Wed, 28 Mar 2012 13:07:31 -0500 "David C. Rankin" drankinatty@suddenlinkmail.com wrote:
On 03/28/2012 12:14 PM, E. Liddell wrote:
NetBSD may have patched this, but I can't find the actual patch file, just references to same ("Add media-gfx/gwenview-1.4.2 with libpng 1.5 buildfix (NetBSD patch); Fix media -gfx/digikam-0.9.6 to build with libpng 1.5 (NetBSD patch)") and some incomplete chunks from a now-deceased website.
Yep, I've found little bits and pieces around as well, but no off-the-shelf patch. It looks like we will just have to open libpng/src/png.c libpng/src/png.h and the digikam and gwenview files and patch the problems for TDE.
Hmmm. NiLuJe, the guy who was running the defunct site I quoted, is traceable (ninuje at gmail [no typo], has a posting history on the forums for Gentoo and for MobiRead)--dunno if it's worth contacting him (or the BSD people, for that matter) to see if there's a backup of the pre-existing patch somewhere. If someone does have it, it might save some time.
On 03/28/2012 03:00 PM, E. Liddell wrote:
On Wed, 28 Mar 2012 13:07:31 -0500 "David C. Rankin"drankinatty@suddenlinkmail.com wrote:
On 03/28/2012 12:14 PM, E. Liddell wrote:
NetBSD may have patched this, but I can't find the actual patch file, just references to same ("Add media-gfx/gwenview-1.4.2 with libpng 1.5 buildfix (NetBSD patch); Fix media -gfx/digikam-0.9.6 to build with libpng 1.5 (NetBSD patch)") and some incomplete chunks from a now-deceased website.
Yep, I've found little bits and pieces around as well, but no off-the-shelf patch. It looks like we will just have to open libpng/src/png.c libpng/src/png.h and the digikam and gwenview files and patch the problems for TDE.
Hmmm. NiLuJe, the guy who was running the defunct site I quoted, is traceable (ninuje at gmail [no typo], has a posting history on the forums for Gentoo and for MobiRead)--dunno if it's worth contacting him (or the BSD people, for that matter) to see if there's a backup of the pre-existing patch somewhere. If someone does have it, it might save some time.
I'm stumbling onto more pieces as well:
The patch from the kdedevs:
Bug: https://bugs.kde.org/show_bug.cgi?id=266319
link to patch: https://bugs.kde.org/attachment.cgi?id=57257 (attached to message as well)
This may handle the gwenview problem or provide an excellent Go-By to create our own.
We will need to see if this applies and if it is fixed in TDE as well (png_read_update_info calls png_read_start_image) pngloader.cpp.
https://bugs.kde.org/show_bug.cgi?id=296305
I'm stumbling onto more pieces as well:
The patch from the kdedevs:
Bug: https://bugs.kde.org/show_bug.cgi?id=266319
link to patch: https://bugs.kde.org/attachment.cgi?id=57257 (attached to message as well)
This may handle the gwenview problem or provide an excellent Go-By to create our own.
We will need to see if this applies and if it is fixed in TDE as well (png_read_update_info calls png_read_start_image) pngloader.cpp.
Good find!
Side note: Why every time the libpng people push a Dot Zero release everybody in the entire free/libre software world has to play Keystone Kops to fix their changes?
Darrell
On 03/28/2012 04:13 PM, Darrell Anderson wrote:
Good find!
Side note: Why every time the libpng people push a Dot Zero release everybody in the entire free/libre software world has to play Keystone Kops to fix their changes?
Darrell
The patch isn't a 1-for-1 fix for TDE, but I'll see if I can digest what they did and replicate it in tde gwenview :)
The patch isn't a 1-for-1 fix for TDE, but I'll see if I can digest what they did and replicate it in tde gwenview :)
I'm running a fresh full build right now. I massaged the gwenview patch for Trinity. I'm still building against libpng 1.4.9 but at least we'll know whether the patch adversely affects backwards compatibility.
Updated patch:
http://humanreadable.nfshost.com/trinity/patches/tqt-fixes/gwenview-libpng15...
Darrell
On 03/28/2012 04:49 PM, Darrell Anderson wrote:
The patch isn't a 1-for-1 fix for TDE, but I'll see if I can digest what they did and replicate it in tde gwenview :)
I'm running a fresh full build right now. I massaged the gwenview patch for Trinity. I'm still building against libpng 1.4.9 but at least we'll know whether the patch adversely affects backwards compatibility.
Updated patch:
http://humanreadable.nfshost.com/trinity/patches/tqt-fixes/gwenview-libpng15...
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Hmm,
Not quite yet... Patch applied and:
/bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../.. -I./.. -I/opt/trinity/include -I/opt/tqt3/include -I. -include tqt.h -D_LARGEFILE64_SOURCE -DQT_THREAD_SUPPORT -D_REENTRANT -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -O2 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -I/usr/include/tqt -MT pngformattype.lo -MD -MP -MF .deps/pngformattype.Tpo -c -o pngformattype.lo pngformattype.cpp libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I./.. -I/opt/trinity/include -I/opt/tqt3/include -I. -include tqt.h -D_LARGEFILE64_SOURCE -DQT_THREAD_SUPPORT -D_REENTRANT -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -O2 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -I/usr/include/tqt -MT pngformattype.lo -MD -MP -MF .deps/pngformattype.Tpo -c pngformattype.cpp -fPIC -DPIC -o .libs/pngformattype.o pngformattype.cpp: In function 'void Gwenview::setup_qt(TQImage&, png_structp, png_infop)': pngformattype.cpp:293:15: error: invalid use of incomplete type 'png_info {aka struct png_info_def}' /usr/include/png.h:724:16: error: forward declaration of 'png_info {aka struct png_info_def}' make[3]: *** [pngformattype.lo] Error 1 make[3]: Leaving directory `/build/src/gwenview/src/gvcore' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/build/src/gwenview/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/build/src/gwenview' make: *** [all] Error 2
Got to pick up my kiddos from swimming, back shortly...
On 03/28/2012 05:59 PM, David C. Rankin wrote:
pngformattype.cpp: In function 'void Gwenview::setup_qt(TQImage&, png_structp, png_infop)': pngformattype.cpp:293:15: error: invalid use of incomplete type 'png_info {aka struct png_info_def}' /usr/include/png.h:724:16: error: forward declaration of 'png_info {aka struct
Darrell,
It seems to be stumbling on this code:
#if PNG_LIBPNG_VER_MAJOR>1 || ( PNG_LIBPNG_VER_MAJOR==1 && PNG_LIBPNG_VER_MINOR>=4 ) info_ptr->trans_alpha[i] #else info_ptr->trans[i] #endif
Not being able to read any this stuff any better than I can, shouldn't the patch also got rid of the above code completely? The info_ptr->trans_alpha[i] has to be removed and replaced with palette[i].red (.green,.blue) stuff right?
Updated patch:
http://humanreadable.nfshost.com/trinity/patches/tqt-fixes/gwenview-libpng15...
Not quite yet... Patch applied and:
Okay, try again. Same link.
I added some extra preprocessor if statements for checking the libpng version. The patch worked fine here building against libpng 1.4.9.
Your turn to test against 1.5.x. Just remember that I am very much a C++ noob. :)
I built a second time without the patch, same libpng 1.4.9. The file difference between the two packages was /opt/trinity/lib/libgwenviewcore.so.1.0.0.
I haven't yet performed any usability testing. I suppose opening and manipulating a PNG file should suffice.
Darrell
On 03/28/2012 06:51 PM, Darrell Anderson wrote:
Okay, try again. Same link.
I added some extra preprocessor if statements for checking the libpng version. The patch worked fine here building against libpng 1.4.9.
Your turn to test against 1.5.x. Just remember that I am very much a C++ noob. :)
I built a second time without the patch, same libpng 1.4.9. The file difference between the two packages was /opt/trinity/lib/libgwenviewcore.so.1.0.0.
I haven't yet performed any usability testing. I suppose opening and manipulating a PNG file should suffice.
Darrell
Chock one up for the noob!
worked like a champ. I'll test for operational functionality tonight. Great job Darrell!
==> Finished making: tde-gwenview 3.5.14_dev-1 (Thu Mar 29 02:14:01 UTC 2012)
Targets (1): tde-gwenview-3.5.14_dev-1
Total Installed Size: 2.55 MiB
Proceed with installation? [Y/n] (1/1) checking package integrity (1/1) loading package files (1/1) checking for file conflicts (1/1) checking available disk space (1/1) installing tde-gwenview
:)
Chock one up for the noob!
worked like a champ. I'll test for operational functionality tonight. Great job Darrell!
Heh. Thanks. :)
I was able to open a PNG image in gwenview. I don't know what else to do as a usability test. Please let me know.
Darrell
On 03/28/2012 09:48 PM, Darrell Anderson wrote:
Chock one up for the noob!
worked like a champ. I'll test for operational functionality tonight. Great job Darrell!
Heh. Thanks. :)
I was able to open a PNG image in gwenview. I don't know what else to do as a usability test. Please let me know.
Darrell
Looks good on this end,
We do need to update the KDE->TDE in the gwenview about dialog.
http://www.3111skyline.com/dl/dt/trinity/ss/gwenview.jpg
I'll do some more testing, but looks like you hit the bullseye on the libpng patch!
Looks good on this end,
We do need to update the KDE->TDE in the gwenview about dialog.
All of the apps in Applications need branding updates.
Darrell
-
Darrell Anderson -
David C. Rankin -
E. Liddell