trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: March 2012

Re: [trinity-devel] digikam - error: invalid use of incomplete type 'png_struct {aka struct png_struct_def}'

From: "David C. Rankin" <drankinatty@...>
Date: Wed, 28 Mar 2012 10:59:07 -0500
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.

-- 
David C. Rankin, J.D.,P.E.